Julia as first language

New to Julia
1

Is Julia a language, that can be described to be suitable as a first programming language?

I think it has the potential to be that. Tim Holy thinks so as well.

As somebody, who is highly interested into programming for quite some time now, did I read, watch, listen, and study coding for years.

I always wanted to ‘do it right’ and understand the implications around coding itself, previous to actually settling down on something.

Early on, I understood that functional programming is underutilized.

The reason number one that most established programmers had for refusing it, was that they are already used to imperative and object-oriented programming.

So I looked for a functional language that is suitable for beginners.

I think I found it in Julia. :tada:

Particularly the type of system, multiple dispatch, and the overall practical, and scientific approach to programming endorsed by the people using it, appeals to me. :slightly_smiling_face:

Programming languages like Python, Ruby, and Rust are well known for their very welcoming nature, and they have built up a reputation of introducing people into programming, and I think their high degree of success goes largely down to this factor.

Programming newbies have one huge advantage for communities, they are much easier to be convinced, and they don’t have to pay the costs of switching.

Sadly, and I say this with the experience of trying to join several communities of functional languages, is this benefit largely not seen, and often deliberately ignored.

The value, that lies within newbie friendliness, is often brushed away, with an attitude that suggests that the investments that have to be made into developing a culture that is open and receptive to newcomers, is seen as ‘too high’ and unprofitable.

People, who are already programming in their current language for 10 years, are used to the tools, the compiler, the ecosystem and the community.

Switching has a real cost attached to it, and newbies just join the ranks of those communities, who welcome them.

So now, here comes my question:

Is there a real, serious and honest interest in the community, to turn Julia into a newbie friendly language, like Python?

I think this is a low-hanging fruit.

And the changes to be made, in order to be truly open to newcomers, are small, and meaningful.
The language is, as of now, suitable to newbies coming from chemistry, physics and mathematics.

I think that limits the amount of people potentially joining our community, since this scientific setup still provides certain benefits, that people outside the university do not have.

Like a professor, that explains to them everything in person :wink:

I think the reality can show, that new programmers can be indeed one of the most profitable investments into the ecosystem:

For the reason, that switching to another ecosystem has costs attached.
And Julia gives little reason, to do so anyway :wink:

4 Likes
2

Is Rust so noob friendly? I would hate for that to be my first language, but maybe that’s only me.

Julia seems pretty noob friendly to me. It reads well and is straightforward to use, and the language makes it easy to do advanced things with it pretty quickly.

And the changes to be made, in order to be truly open to newcomers, are small, and meaningful.

What changes do you have in mind?

3 Likes
3

I think this is the wrong question. Or rather, it’s not the whole question. Given limited developer time and attention, I think the question should be more like “where does making Julia newbie friendly rank on the list of priorities?”

The answer will be different for everyone of course - I think most people would think it’s a good idea. It’s an oft-observed fact that the Julia community has a disproportionately high number of academics, and many of us have made introductory courses, others have written books, etc to try to speak to newcomers.

But AFAIK there’s no concerted effort on this front, and I don’t really expect the to be.

8 Likes
4

It is the language itself, that prevents it from being suitable to be a first language.
The culture, the people and the community as such, is very noob friendly.

Mostly, yes. One part that really seems underdeveloped, is support for literate programming.
So that we can use not instead of ! and so on.

Literate programming is a great start to programming, since most of us are already literate.
We already know how to use and, or, not and so on.

We don’t need to learn those, and code reads more natural to those, who are not used to random symbols, such as || and mathematical symbols.

I posted on other things in the past.

And others have made great suggestions as well:

Another aspect would be to care a bit about the VS Code Jupyter extension compatibility, as this serves as a great platform for tutorials.

And overall, I think it is more about the mindset, and the intention of the community.
I am sure, all these things can improve, but I am not so sure, that the community actually desires Julia to be a language for new programmers.

With that mindset, the rest would come naturally, I assume.

1 Like
5

It was my proper first language, and I can code just fine in other languages too now so I think it’s pretty suitable.

10 Likes
6

Where there is a will, there is a way. :slightly_smiling_face:

7

What is the purpose of teaching students a programming language. Is it to teach them a specific language? No, it’s to teach them how programming works, how computers work, how to understand the “model of computation”, and how to understand the process of abstraction.

Given that, the first language to learn doesn’t necessarily need to be, and I would argue shouldn’t, be a language that you use day to day. It should be something that is useful for learning transferrable skills. This is the reason the classic MIT course used Scheme, and I think it lost its way by going to Python.

Python is quite terrible for actually teaching programming. The reason is not that it has many abstractions, it’s that the abstractions are opaque. Object oriented programming is implemented via dictionaries, dictionaries are hash tables, so hash table algorithms are the core behind a lot of Python. But, how do you show that? It’s not easy to actually inspect what Python is doing, and so students learn the “how” of programming (kind of, but not really, just rules of thumb), but not the why, or truly a model of the program structure. The argument that put Python here is that it’s simple and they have a high probability of using it after graduation, but again neither of those things are actually inducive to a well-rounded and transferrable learning experience, so it has no place in the argument. They may use Python today, but they should instead learn in a way that lets them understand all languages, not one, given that it can be taught more easily.

So what languages to learn? I would argue that there are only two ways to do it. There’s one approach where you start with abstractions and you progressively dive in to understand how they work, and there is another approach where you start with no abstractions and progressively build them on.

The C approach: bottom up

For the latter, C is an absolutely excellent way to teach programming. You start with a pretty barebones “this is how the computer works” model. It’s a model, C’s programming model is fairly “close” in some sense to a computer but it’s not perfectly accurate, but it’s a rather good and simple model. You can learn every built-in in the language in one semester. It’s all about how you use a very small core. Scheme was chosen before for this same purpose, but I’d argue C is a bit better because it really makes memory management and pointers available to you. You have to struggle to understand how to make a matrix because all you have a linear slab of memory, and you come up with the idea of either row or column major ordering. You have to understand allocating and freeing, and why dynamic data can be hard.

After doing this, you do a next course in anything, Python/Julia/R/MATLAB, and you understand that broadcast is building loops, that the array abstractions are allocating and freeing for you, what the underlying cost is, that the language has chosen a convention for column or row major. You understand these abstractions as simplifications of things you previously had to do by hand, and you appreciate their existence but also understand the cons of the abstraction.

The Julia approach: top down

The other approach I would argue is only doable with Julia. What you want to do is teach at a very high level at the start, like is currently done with Python, showing features like types, multiple dispatch, for loops, properly using standard library features like dictionaries and sorting algorithms. You build applications and you go so far so fast! But then after the first half of the semester, you start to drill down into the algorithms. How does multiple dispatch work? Why does it optimize? How are dictionaries implemented? How is sorting implemented? Why is it implemented like that? How does broadcast work? What are allocations? What’s the heap and stack?

Julia is a great language for this because it exposes everything. The whole standard library is in Julia, so you can dive in and show how to go from naive to state-of-the-art, how SIMD and summation works, how it’s compiling, and why dynamic dispatch is slow. You can then transfer this knowledge anywhere: you have an understanding of how and why NumPy is built the way it is, you have an understanding of C is just Julia without the high-level niceties requiring a bit of manual labor, and you understand how to build anything from scratch but also why you should use higher level library features.

Which one is better?

I would say that the top down Julia approach ends up being better because programmers learn to be better from this approach. What I mean by that is that, sometimes a student who goes the abstraction building route from C can learn some bad habits and “do everything themselves”. Since they never see a “good” standard library of higher level tools, they can have habits to build every search algorithm from scratch, thinking the merge sort they learned in school or the 3-loop matmul is a good idea simply because they’ve never dove into how real libraries work. Thus while I like the C approach, I have seen too many potentially good programmers burned by learning bad habits.

So in the end, I think Julia is a great language for teaching, not because it’s great language to use, but rather for a fully different set of criteria that actually matches student’s ability to learn in a generalizable way.

53 Likes
8

See the discussion here:

There are definitely teaching materials (even whole books) oriented towards teaching Julia as a first programming language.

4 Likes
9

I would say Rust is an awful choice for this. I like Rust as a language, but it only takes a bit of thinking to realize it’s not a good idea. The reason is because it’s not actually achieving any teaching goals. Again, teaching goals can be (and are) very disconnected from whether a language is good to use. It obviously doesn’t serve the top-down approach like Julia because you have to start fighting the borrow checker and are forced to know what types are from day one, which defeats the purpose of having a starting point with higher level abstractions. And it doesn’t fulfill the bottom-up approach like C because you have a huge language with a much larger vocabulary but no understanding of why the vocabulary is there. You teach Rust for “safety”, but if someone doesn’t what a pointer is and how it can be unsafe then you haven’t done anything.

I think Rust could be nicely tagged onto a second semester course where the first semester is in C. You first make the student struggle with lab assignment and forget to free memory, or accidentally alias pointers, and mess things up. Then when you get to the data structures and algorithms portion, you go “okay wasn’t that insane? Here’s some tooling that can help ensure you don’t make those errors, it’s called Rust”. That’s a perfectly fine way to go about it, and that would alleviate some of the “bad standard library learning” practices seen from a course that invests too heavily in the C “built it yourself from scratch to learn it” approach since Rust does have a good standard library that can be dove into.

I’d still argue to do the top down approach, give the students a few wins so they get comfortable but then open up the details, but C → Rust is a completely viable approach if students have enough independent motivation. But even in this setup, Rust isn’t first but after C, so not a first language.

I’ll end by saying, one of the best ways to teach is to teach someone how to break things apart. You want to go off the rails and rip things apart, open them up, and show the adverse behavior. It’s what all engineering courses do, and I think most software engineering is learning by doing the same. A language with guardrails is good for actually building robust software but gets in the way when trying to do this kind of investigation, for a good practical reason, but again teaching and usage do not have to be the same.

11 Likes
10

I really should not have mentioned the welcoming nature of the Rust community, as this is now misinterpreted as me saying Rust is a good first language :laughing:

2 Likes
11

The question is, if there is a shared interest, to bring Julia up to the level of Python as education language. :slightly_smiling_face:

I ask myself if this community is dedicated to develop and use the language with the sole purpose of scientific computing, or if there is real interest beyond.

I question this, so that I can understand the ultimate intentions behind this project:
And if introducing people into programming is one of these. :slightly_smiling_face:

Since much speaks for it, and some still seems to speak against it.

So I feel the community has not really decided, how they like to treat that factor.
Is there a real interest to optimize the language, so it can be used as a teaching language?

I whole hearty agree with your analysis of Julia being suitable for the top-down approach.
But I am not sure, this is also seen as a goal of the language.

Or more an accident, that can happen.

12

It’s more of an accident. The reason for the standard library being all in Julia is that it then enable more generic programming and multiple dispatch to take place on standard algorithms, which is a practical thing for usage. The fact that it also makes it accessible to teach what’s actually happening under the hood is clearly secondary.

And I don’t think any optimizations should be omitted from the standard library simply because it makes it harder to teach, though code review would generally guide the complicated algorithm to at least be legible since otherwise it’s hard to maintain, that maintainability requirement also helps ensure the library is quite teachable from. Though it does not necessarily lead to that since the first goal is to have a good standard library.

There’s quite a few educators on this forum, so I think it’s a yes. Pluto for example is a whole notebook system that puts the teaching aspects first above all else, for better or worse. I tend to keep around “simple” more reference implementation libraries of most things and use them as a teaching tool, for example DifferentialEquations.jl has SimpleDiffEq.jl, NonlinearSolve.jl has SimpleNonlinearSolve.jl, etc. which serve multiple purposes (i.e. are faster on small problems, statically compile-able, and GPU friendly) but also are used for teaching how solvers work (and the limitations of the naive approaches). I would like to see a bit more of this in some other domains like stats for example.

6 Likes
13

I am happy that you like Julia, but note that it is not a functional language in the sense the term is generally used (think: Haskell, etc). Julia has mutation, and it is perfectly idiomatic to use it. Julia is multi-paradigm: you can use a functional style to the extent you want to.

This remains to be demonstrated, ideally by enumerating those changes.

Note that “newbie-friendly” is not a well-defined term. There are programming languages which are perfect for pedagogy (eg Scheme) because they use a small number of building blocks and you can use them to teach a lot of concepts, or dynamic languages like Python which allow you to get stuff done with a small investment.

Julia is quite complex, but rewarding. Whether it is suited for a particular person who just starts programming depends on the person, his/her prior experience, affinity for programming, and the resources available (eg is there a colleague/mentor who can help when there are stumbling blocks?).

Generally, Julia’s performance model requires an understanding of parametric types, which is not something I would consider a newbie topic, even though a lot of people manage it just fine. But since this is a core part of the language, I don’t see how it could be made much easier.

10 Likes
14

This is the first time, someone considers the static typing part of Julia as core.
The homepage suggests, just as the documentation and pretty much anything else that I gathered online, that typing is optional, and not core to the language.

The default behavior in Julia when types are omitted is to allow values to be of any type. Thus, one can write many useful Julia functions without ever explicitly using types.

Many Julia programmers may never feel the need to write code that explicitly uses types.

This seems like a newbie can avoid them?

15

Nothing Tamas said has anything to do with static typing. Julia is a dynamically typed language. He said parametric types are vital to understanding the performance model.

2 Likes
16

I think you misunderstand: I am talking about parametric types, and how they interact with the compiler. This is indeed a core feature of Julia, mentioned on the very first page of the manual:

good performance, achieved using type inference and just-in-time (JIT) compilation (and optional ahead-of-time compilation), implemented using LLVM

Julia’s type system is fundamental for writing performant Julia, and it is pretty advanced for most people new to programming.

6 Likes
17

I first learned of Julia in 2014 while reading @LeePhillips excellent article comparing newer programming languages to FORTRAN. (I hope I tagged the right Lee Phillips… :grimacing: ) At the time I had been using IDL for several years and was only beginning to learn Python. I still considered myself a “noob” since my programming style was basically borrow someone else’s code and modify it. So, IIRC, I installed v0.4 and was immediately blown away by how much better I liked it than Python (I’ve honestly never really liked Python and only use it begrudgingly). I didn’t even care about the speed at the time, the general syntax and multiple dispatch just made so much more sense to me than the OOP style preferred by Python users. To this day, I loathe to write a Python class object and can count on one hand the number of classes I’ve written in 9 years.

At the time, I found Julia far and away easier to learn, even without the massive number of Python resources out there. I get the feeling these days that some newcomers find Julia hard to learn because they immediately focus on getting C-like performance rather than learning the best Julia programming practices first. So they get lost in the number and variety of optimization options.

And there are great resources for learning Julia out there, and I’ve perused many of them myself. So, I don’t think there are any language changes to be made, but rather making sure that beginner’s learn good Julia practices and not focus solely on speed.

I whole heartedly agree with this. I’ve never taken a real computer science class, so I started learning C to make up for it and found it very nice. Then I got to pointers, got confused, didn’t have time to devote to it, and figured “Julia is the only language I need for now”, so I stopped. But someday, when I decide to learn a new langague, it will definitely be C.

6 Likes
18

I think it’s a bit of a misnomer, to sell Julia as dynamic language, as that suggests that we can write code that is free of type annotations, but you are essentially saying now, that type annotations are not optional, as the quoted parts of the documentation do suggest, but they are unavoidable, and otherwise will the performance be abysmal?

The people coming to Julia, do so since the language promises the ergonomics of Python, and gaining the performance of C. This has already now correlated with my practical experience, as Julia had been significantly slower than Python.

And knowing now, that an understanding of parametric types is essentially fundamental, appears to be honestly like the current messaging of the homepage, documentation, and overall presentation is frankly misleading, to put it politely.

I would strongly suggest, to rethink that part of the public communication.

19

It is certainly possible to write highly-performant code without any type annotations. I’ve recently been testing some code, and adding types did nothing since the compiler was able to figure everything out on its own. I’m not saying this is possible in every case however. Taking a slow code and making it fast does require knowledge of types even if no annotations are necessary, for example, knowing how to avoid type conversions with @code_warntype.

But the question of “how to I make my code fast?” is very different from “Is Julia easy to learn?”. I would say that Julia is incredibly easy to learn. It is also easy to make your Julia code faster, but it can be hard to make it as fast as C.

4 Likes
20

But how is this related to teaching Julia as a first language?

1 Like