I’m the right Lee Phillips. At least, in my opinion.
20 Likes
That is not at all the case and has nothing to do with what Tamas said.
7 Likes
I don’t understand the relevance of parametric types for newbies, then.
If this is only relevant to get all the performance possible, and it’s totally doable to write completely dynamic code, why would it be mentioned in this thread?
And I understand, that something that is ‘core to the language’ is indeed important to learn for newbies.
I am not sure you understand what I am saying.
Type annotations are of course optional most of the time, but to get the most out of Julia an understanding of the type system is essential. And, frankly, it’s pretty complex for newbies. Without understanding how Julia compilation works, a user is guaranteed to run into suboptimal performance. It may not be abysmal, just suboptimal (incidentally, please try to keep hyperbole out of this discussion, as it serves no purpose).
It is hard to say anything about this without specifics, but if you think so, please make a PR to the docs.
4 Likes
There’s an implicit assumption here that Python is currently more newbie-friendly than Julia, but I don’t think that’s true at all.
Python earned its reputation as a beginner-friendly language at a time when it was being compared to languages like C, Java, and Perl. Compared to those, the syntax is simple and easy to read, and there are no extra steps from writing code to running it. But given the current state of Julia, I think it’s very hard to make an argument that Python is the best pedagogical language.
I spent about two years training students to do data science work in Python. Some things I noticed along the way:
- OOP is still awful (Ok this one’s personal preference, but man is it bad)
- Creating packages is a mess, requiring lots of devops-like work. In Julia this is simple, and could probably be taught to beginners in an afternoon.
- Most library code needs to be treated as magical, since digging in would require training in C. In Julia, you can go much deeper into the code before feeling stuck or overwhelmed.
- Very often we’d get students to write their own implementations of algorithms, in order to better understand them. In Python, these can only ever be toy implementations, because the performance hit is so great. This gives students the impression that they can only ever be consumers of “real world code”, and never producers. Obviously not the case in Julia.
If there’s a good argument that Python has any pedagogical advantages over Julia, I’d be interested to hear it.
31 Likes
I understood that it is core to the language and as such so important, that it can’t be missed.
That can only mean, that its performance impact is so big, that it is essentially required to know about parametric types, otherwise would the language become unusable.
Why else would a newbie otherwise deal with it?
I never found Python’s speed to be an issue, and very much so that one of Julia.
And still, I think performance is rarely on the mind, of somebody learning to program.
As you have noted yourself, is the definition of a newbie probably not very easy.
People in the university, who have great access to colleagues, professors and so on, are probably not what I have in mind.
ahh I hate this part haha. I like homework problems where when you’re done, your implementation is as good and as fast as the library implementation. If you could not have written the library, you worked on a toy. Otherwise it’s hard to know what you don’t know: people believe they understand how matrix multiplication because they implement it and then hear “Python is slow, don’t worry about it”. No, teach the student right there about cache misses and go the next step.
What happens from this is the whole “use a LinkedList” model of the world. Students learn a too simplified model of how computation works, are told that they don’t need to worry about how libraries are written because “that’s just details”, and then walk away with simply an incorrect view of how a program works. I think you should be able to at the end of a data structures class/module, show this video:
and in the final exam ask “LinkedList insertion to the beginning is O(1), while Array insertion at the beginning is O(n). Why are arrays faster in practice in most cases?”. If a student just learns big-O but does not understand why this paradox exists, then they have not learned a good model of programming.
The high level Python style of teaching leaves students completely dumbfounded when you ask them questions like this, to the point where I have talked with people who simply believed it’s not true. Big-O is all there is to an algorithm, right? Understanding that there are different levels to the abstraction in not just programming but the model of computation is essential for practical programmers, and for setting them up for the next stage of learning theory of computation.
13 Likes
I think for this discussion we need to differentiate between what kind of beginners we’re talking about…
I’ve met people from two rough categories:
-
Beginners in love with Programming
Those beginners don’t fight with the language, instead it’s one big puzzle that’s fun to solve and dive into. They’re very motivated intrinsically and will find all needed information, even if its hard to get…They don’t mind spending hours cracking some weird corner cases and problems they’re running into, because the problem solving is a reward in its self. -
The impatient Beginner
Maybe they just need programming to achieve some other goal, are forced to learn programming or never intended to dive deep into programing, since it doesn’t appeal to them in itself as much.
Maybe they don’t like logic/math but still want to do something cool with a computer. This lowers the frustration barrier a lot and makes it much harder to learn a programing language.
Of course these categories don’t map 1:1 to real humans, but I guess I’m much closer to category 1) and therefore Julia was absolutely amazing, even though the docs aren’t often that great, and the community often doesn’t welcome “stupid” questions as much. Also, since I already had pretty strong opinions about why Julia was a good language for me, I didn’t mind bugs as much and just saw them as challenges on the way to a great tool.
The ability to just learn the language by reading code others wrote via @edit and just hacking around with package code interactively is a dream for someone who likes a nice puzzle and is a fan of the language… @code_typed/llvm/native was also really amazing and taught me so much about how programming languages work and how to write performant code - without ever reading a tutorial. And yes, I kind of hate long documentations and tutorials, since I just love to dive right in and try things out.
Group 2) has much bigger problems with missing docs, tutorials, bugs and a community full of nosy nerds.
Every bug they run into, any missing library and any puzzle that’s thrown at them just makes them question why they’re not spending their time on something more fruitful, ultimately dropping learning the language.
Here, languages like Javascript and Python really shine, with a huge community and an insane amount of easy to follow tutorials and help at every corner. It also helps, that the language has no compile time latency, is dynamic and actually hides how the computer works underneath, since it was never the intention to dive that deep.
I think that’s the reason why Julia can be at the same time very newbie friendly but also a nightmare for newcomers.
I’ve certainly met people from both camps and I think both makes sense!
With Julias much easier to use package manager and all the things that brought me to Julia like nice math syntax and no OOP, I do think Julia is ultimately the better beginner friendly language.
What’s missing is growth, so that there will be a bigger amount of people not as nosy and and more focused on teaching newcomers. Also, bugs, compile wait times and missing libraries will become less frequent, further helping newbies to get started 
And of course, reminding ourselves to be friendly and not greeting newcomers with arrogance will help a lot too 
41 Likes
I would argue that the best first programming language is simply whichever one is most likely to keep the learner engaged. My first language was JavaScript, which I learned along with HTML and CSS. I started learning it in high school on my own time. The ability to build things I could interact with in a web browser is what kept me engaged, wanting to learn more, understand more, etc. Simply put, it was just fun to tinker around with, and that’s what I did for many years before ever doing anything serious with it or exploring other programming languages.
I think if I wanted to set up a complete beginner with Julia, I would teach them how to start up a Pluto notebook and get them trying things out in that interactive environment. I regularly load Pluto notebooks just to try an idea that popped into my head, or if I want to explain something to a colleague I find it really convenient and fun to load a notebook with interactive sliders, buttons, etc. For most people, I think it’s really just about staying engaged.
Now, if you are someone who has made up your mind that you are going to learn to program and you know that you have the discipline to keep yourself engaged and see it through no matter what, I would say just pick whatever language will be most useful for the kind of things you want to do.
4 Likes
I think this depends entirely on what the new programmer is trying to do.
In undergrad I took one class in Fortran, but it didn’t really click. Python was the first language Iearned really well, right out of grad school. I didn’t have a teacher - I just read the docs and figured it out.
My first job out of grad school was at a national lab, and I started using Python on projects. For pretty much anything I’d put together, I was asked “How much data can it handle?” and then “Can we get it to do more, faster?”
I think this is pretty typical for any kind of technical computing. But even for more general use, good CS pedagogy would lead from first steps in a language into data structures and algorithms. Building data structures in Python usually means working in terms of Python’s dictionaries. But this muddies the waters, since now you have one data structure built on another, and the underlying thing needs to be treated as god-given. You can’t pick it apart, since that would require C.
I guess to me, a good pedagogical language is one that lets you start simple and then gradually dig, leading to as deep an understanding as possible with minimal boilerplate. That’s why I think Julia is much better than Python for the task. Maybe the discussion could be more productive if you gave more detail on the qualities you look for in a pedagogical language.
4 Likes
A first language has to be fun to write in (we’re not talking about people with huge inclination to be a CS, of course). That depends on tooling and libraries, and packages. Julia is pretty fun to work with already.
And I think it is good if the language allows the user to learn basic program concepts like for loops, conditionals, etc, in realistic use scenarios, and Julia is also good for that (and there’s where interpreted languages fail, because one would be learning code patterns that have to be avoided).
I do not completely agree with Tamas that we need to introduce the type system in a deep level from the beginning. One can use simple types, even structs with typed parameters (but not parametric) to illustrate many concepts, and introduce the type system gradually.
3 Likes
I’ve never really been motivated to learn C well for real projects because real world C code is often full of code for handling all the possible systems / architectures etc. the code might encounter. And this level kind of bores me because it doesn’t have anything to do with the application logic. It’s also a moving target as hardware and OSes change all the time. Julia which is low level but naturally cross-platform without jumping through lots of hoops sits at a nice position for me, I can always choose the level of abstraction I want.
2 Likes
I think that if we are honest with ourselves, Julia is not a good match for these people in its current state. And it may be difficult to adapt it so that it is a good match.
“Newbie-friendly” is an ill-defined term, and not really useful. I would rather think about learning curves, the cost of learning a language, and the benefits.
Julia does require a large initial investment from someone who was not exposed to programming. Yes, a motivated newbie can do this, but there is no point in denying that a lot of work will be required, with frustrating debugging sessions, head-scratching, etc. OTOH, once learned, Julia is a very powerful language, allowing one to write fast reusable code.
Contrast this with BASIC: super-easy to learn (which was the intention), but once learned, not particularly powerful. A minimal investment with near-zero return. Which is why practically no production code is written in BASIC.
Each language can be profiled like this, and the person learning programming has to make an informed choice. For some people, Python/Lua/Javascript/… is a better choice than Julia.
I completely agree with this — the claim is just that in order to be proficient in Julia, a lot of concepts will need to be understood at some point. It does not have to be the very beginning, but the investment is inevitable.
4 Likes
Yeah I forgot to mention, that everyone from Group 2) I’ve met quit Julia ^^
I dont think we can improve on that front though by forcing it, as long as there isn’t suddenly someone pouring millions into it (and even then it would take quite some time)…
It will simply need a lot of time to mature to a point to be “user friendly for people not as invested” 
6 Likes
Isn’t that true for Python as well? What’s bad in Julia relative to Python is mostly defining a practical workflow. But when it comes to the language itself I don’t see many differences.
2 Likes
I mentioned literate programming, compiler messages, opinionated default packages, the VS Code compatibility with Jupyter and the overall mindset of the community.
It got a bit buried in all the answers, who did not really answer to the topic, and did so towards their interpretation of what I had written.
I think it would be totally sufficient, to put willingness into it.
The changes that I think are necessary, are less technical limitations, but a more empathetic point of view, that encompasses the wording, presentation and consideration towards newbies.
It’s really about the small little details, and that comes naturally, once you adopt a mindset that has beginners in mind in the first place.
It’s really more about the intention behind designing a programming language community, and less so - in Julia’s case - about radical changes to the language itself.
I am just not sure, if there is an intrinsic motivation, to do this.
It seems like, science is the only field of interest.
It’s more about a commitment to intrinsically care about that aspect of the language.
What I find compelling about Rust (from a systems and infrastructure development perspective) is that the pool of the “Rust-curious” is so diverse. You have as many people who normally develop in Go, JavaScript, or Python, or even Haskell or Ocaml, as Java or C++, C, or C# learning Rust. So it tends to integrate quite different “programming cultures” successfully and infuse thats into community software engineering practice. So this filters down to helping support those people who are learning to program for the first time, or simply people who are learning different types of programming paradigms than what they are traditionally used to.
Now, my alter ego, who likes more numerical code, can’t find too many flaws with something like Julia. However, a lot of modern programming practice is developing services that sit inside larger ecosystems (or perhaps these days, networks of ecosystems), so hopefully Julia will continue to head towards that direction, rather than relying on strictly a fat runtime that is great for development but perhaps limits the potential production uses (at the moment, at least). I think that will increase the number of use cases.
1 Like
Again, please make these suggestions more concrete with PRs.
That’s something everyone should answer for themselves. Do you have an intrinsic motivation to do this? Nothing prevents you from addressing these issues then.
5 Likes