I've taught hundreds of people programming. For one year, at my first real job, I was tasked with teaching the programmers within a big company Pascal. All of them were already professional programmers using Fortran, COBOL, or assembly language. The company had a commitment to modernize their software development practices and one facet of this was to introduce a more modern language--Pascal at that time (circa 1976).
I enjoyed that year and, for the most part, my "students" were easy to teach, and Pascal held up well. They were all programmers already, so I didn't have to go slow through the basics and introducing ideas like recursion (absent in Fortran, COBOL, and assembly language of the period) kept the classes new and interesting to the students.
Unfortunately, standard Pascal isn't really a good choice for a first programming language today, even though modern Pascals have removed many of early Pascal's limitations (packages, batteries included libraries, etc.)
So, how can we decide if a language is a viable first language? Employing the wisdom of crowds, here are the top 30 languages in the 2023 IEEE Spectrum rankings:
I contend that we should limit our choice of first-languages to some language in the top 30. This rules out many languages that I consider important, but we should stick with a language that is likely to benefit the student more than others as a first-language. That means not teaching Lisp or Racket or Ada or Ocaml or Prolog or even D for that matter as a first language.
To narrow our top 30 down to a handful of alternatives, I'm going to use my own subjective difficulty rating and remove C++ and Rust and Scala from the list because they will be too hard for beginners.
Furthermore, let's remove languages that aren't general purpose; this knocks out SQL, HTML, R, Shell, PHP, SAS, Matlab, Assembly, Visual Basic, and Verilog.
Some languages require more complex build or execution environments; I would remove Java, Dart, Kotlin, and Groovy from our list for this reason.
Finally, there are some languages that are not as easy to use outside of specific hardware or operating systems; I consider these languages C#, Swift and Objective-C to be ruled out.
For good measure, I'm removing Perl from the list (a bit too irregular) and Fortran (not widely used outside of some important areas).
Our condensed list now look like this:
Possible first languages: Python, JavaScript, Go, TypeScript, Ruby, and Julia.
To narrow it down even a bit further we can observe that one should learn JavaScript before learning Typescript. (Is this opinion shared by HN?)
Ruby and Python seem like close cousins with Ruby being a bit prettier and Python being much much more popular.
Julia is a bit specialized and a bit harder than the others so now we are left with just three: Python, JavaScript, and Go.
I think first programming languages need to fit with what the person's motivation is. If they want to do statistics, data analysis and the like then surely Python, R and the like will be a good starting point instead of Bash Shell. Also, the teacher having a very good command of said language as well as all the tools for the environment they'll be using (*nix container, Windows, Mac, etc.) makes a big difference. Things like setting up VS Code to debug something is a daunting task for a beginner with no idea on how to set it up (if they devote themselves to setting it up). Language choice isn't that big of a deal but getting a teacher who knows how to guide the student and teach them everything in said language is (the article shows how the author having a good command of D and knowing said tools taught effectively while he struggled with JS and Lua).
Limiting to top 30 programming languages based on a particular ranking can be biased and misleading. For January 2024 D TIOBE ranking is 21, just outside Top 20 while your top 6 choice of Julia is outside top 30 at rank 33 [1]. D also support scripting and REPL feature as Julia, but D is much faster at them in which faster feedback is very important for new learners.
For proper pedagogical approach we should refer to the experts and educators. There is one paper from Monash University that have come up with major sins of introductory programming languages that are not suitable for new learners including Pascal that you used during your teaching time. I have provided the link to the paper in my other comment.
I would say of your four contenders, you eliminated Julia too quickly, it's perfect.
For one reason: it's a dynamic language with types. It's good to have types in a first language, they're too important to neglect. But with Julia, you just introduce them later.
Also, 1 based indexing is easier on anyone who hasn't already gotten used to 0 based indexing, and it's the only language in your last paragraph where zero isn't false.
But it depends more on why they want to learn than anything else. If they want to make web apps, for some reason, obviously JavaScript, and if they like games, it should be Lua. Data and numerics stuff, AI? Julia obviously ;)
There are various reasons to rule out JS. It's a scripting language for browser engines, it's about as general-purpose as GLSL or ActionScript. Node grabbed it and forced it into a general-purpose suit it wasn't made for, but that's not a good reason to learn it as a first language. It's also simply a poorly designed language.
On the other hand, the reason given for excluding Java is seriously reaching. The JVM isn't "complex" from the student's point of view, and hello world (and other exercises) can be compiled with a simple javac invocation.
I think you tossed VB for the wrong reason. It's definitely a general purpose language but it's mostly limited to one platform so that's handled a few lines lower and it would still have led it to be tossed out. I agree with JS over TS for first learning because of the complete lack of a toolchain but later on you probably want to move to TS. Python agreed on as well, Go requires a lot of other knowledge and is a far more advanced eco system already so I'd have ruled out that one as well.
What happened to C? It's the #5 top language and you never ruled it out but it is missing from the final list? It seems like a reasonable first language with simple operations and not much magic happening behind the scenes.
It's available but not in common use, and where it is used it is used mostly as a portability option (though it is very well possible that is no longer the dominant use, I just haven't seen it used any other way outside of the Microsoft eco-system).
Main deployment platform for back-end workloads using .NET is Linux. There are GUI frameworks which support it (Avalonia and Uno), file and sockets I/O support is first-class. CLI tooling is platform-agnostic, paid and free tools for developing in C# are available under Linux and macOS. With some effort it can be also run on FreeBSD (not mentioning interesting but niche projects like BFlat which can target UEFI directly).
For example, getting the SDK on Fedora is just
sudo dnf install dotnet-sdk-8.0
It is as cross-platform as it gets, far more easier to manage than installing JVM implementation and then dealing with a switcher or just the fact that Java needs Gradle to build projects over trivial dotnet new console; dotnet run/build/publish
In my experience, the only places pushing for C#/.NET in Linux are places that were already C#/.NET before the core started to support it.
It's still fairly popular but that popularity is waning as languages with more modern design principles are gaining momentum without relying on a heavy framework like .NET. This could make it a poorer choice for somebody just learning as there may be fewer opportunities for junior devs by the time they graduate.
Even Microsoft has started transitioning to Rust in some cases. I'd hesitate to recommend a language to somebody getting started if that language is under publicized risk of being replaced by its maintainer.
I would add that a purely OOP language also probably isn't ideal for a first language, though. Being able to start teaching with just functions is quicker to introduce than having to describe objects first.
An OOP centric language is definitely appropriate for a second language. But if we are talking "intro", the faster somebody can type hello world while still having more programming concepts in the file than just the print statement, the better. For that last statement, I'd also exclude Python.
I always recommend talking about goals first then recommending a path.
If they know web dev is their future, JS.
If they know IOT is their future, C.
If they know games, probably still C as C++ is still likely the path for a while.
We are talking first language. Not people who are looking for a job right now. What about that doesn't make sense? These are people who are likely months to years away from getting a job.
> Furthermore, let's remove languages that aren't general purpose; this knocks out SQL, HTML, R, Shell, PHP, SAS, Matlab, Assembly, Visual Basic, and Verilog.
Just a nitpick, but modern PHP is definitely a general-purpose language, and quite a decent one. Assembly is also inherently general-purpose, and might have a much higher learning curve, but its foundational nature also makes it an important step in a layered approach to learning (a la Nand2Tetris).
I'd throw Python out too, as it's just far too slow*, which would set wrong expectations for learners. While itmcaan be sped up by writing everything in C and calling it from Python you've already thrown C out, so that's not an option. The languages remaining are very unfortunate though: JS is infamously the language designed in 14 days, and Go is a Google project, so I wouldn't be surprised if programming in it awakens Deep Ones to feed on your sanity.
Why would execution speed be particularly relevant? Python is slow but that hasn't stopped many useful applications from being written it, plus proper use of libraries written in C (e.g., numpy) again mitigates the issue.
From a learning perspective, a slower language could actually be beneficial in the sense that it's impractical to brute force a solution to a problem in a way that you can get away with in C or similar.
> I'd throw Python out too, as it's just far too slow*, which would set wrong expectations for learners. While itmcaan be sped up by writing everything in C and calling it from Python you've already thrown C out, so that's not an option.
I'm not sure I follow you. Are you saying using e.g. numpy is not okay because it's implemented in C? How does that make any sense? The cpython interpreter itself is implemented in C so everything interpreted by cpython is just as much "in C" as something else like e.g. numpy.
I can see why people think the tool chain may be hard for adults, but if the focus is on children learners, you can get Lua with the batteries included.
As a first language, I would teach python or javascript with java, C#, C, C++ as strong contenders depending on what they study, and possibly R or MATLAB is there is a very specific and good reason to do so
Sorry but it just isn't. Nor are a whole pile of other interesting and useful programming languages. You need something that offers instant gratification, preferably an interpreted language or a language organized around an interactive prompt.
If I had to teach someone programming today I'd pick JS because it is available everywhere and it doesn't need any tooling at all. It's far from a perfect language but availability and ease of use trump language elegance and correctness. Even if that might mean you have to learn new concepts later and/or unlearn bad habits.
> After half a year we moved on to our second language: Lua, specifically in the video game system Roblox. I almost wish we had skipped this one because it was a bit too advanced for these students, and I was not familiar with the language and the system to begin with.
Teaching something, like a programming language, that you don't know is really hard. But in this case there are 100's of Lua tutorials around Roblox. I would think that they could have done that.
I spend an inordinate amount of time helping the kids set up their build environments, and having this built-in to the IDE or dub would be immensely helpful for using D for learning.
8<-------------
it does seem to have worked out in the end, but I would personally not have considered anything where building was not one click of a button in an ide; build toolchains add a tremendous amount of complexity to learning a new language, and especially if this is also an intro to programming I would consider it a fatal lack.
I ended up teaching a friend to program using Kotlin. The downside was just telling them to just accept what the IDE wizard lays down as gospel first but the advantage was that running code from main() or tests was always a fully IDE integrated experience. Explaining the build system boilerplate became natural when it came time to start adding dependencies to the project.
Don't underestimate how important that integrated experience is. Within their first month or so they were already using a real graphical debugger which is something I didn't pick up until much later because of where I started.
As a D cultist, I don't see why D would be any more viable rather than PureBASIC, microStudio, or Basic4GL if we're talking about kids that want an immediate result in an integrated IDE.
I don't know, man. I am in a few casual programmer circles and I know two people who have stuck with D like their life depends on it, and they are constantly facing issues with weird language quirks making it impossible to write good, safe code. Through their fandom, I've made the personal decision to just stay away from it.
I think Scratch makes a great introduction to programming because of the playfull assets which are bundled with it, sprites, sounds, backgrounds etc. This significantly lowers the bar to making something productive and visually stimulating, something which I believe is necessary to engage when competing with modern games, phones etc.
There is no text based language (please correct me if I have missed one) that makes any attempt to bridge this gap by providing a library of assets on tap. Yes there are places you can find sprites etc, but they are not just there, included. I feel this has been the biggest stumbling block for my daughter moving on from Scratch. To produce something in a text based language that even comes close is so much more work, anything that is achievable just isn't stimulating enough.
We have looked at Roblox, I agree with the article this has potential, making a moving platform in an obby for example, but this hasn't stuck with her. We have had more traction with custom ents in Minecraft, creating in Blockbench then messing with the configs to alter the behaviour, but this is just Mineraft specific.
I should hope to do more with js/ts scripting in Minecraft, but using bedrock this is in it's infancy so there isn't much out there for inspiration, hacking around with or tutorials for her to look at herself. In this regard, D is no better a first language than any other.
One of my favorite professors was using Processing, which was confusing for some, but it really helped that the students got to visually see results.
I have to wonder if we allowed people to learn programming significantly better when RAD IDE languages were more common like VB6 and Delphi. Something about visually seeing what you're building vs just seeing text on a screen. I guess it would only affect SOME people learning to code this way, because we have plenty of brilliant minds who had even less than a terminal at one point or another.
> Something about visually seeing what you're building vs just seeing text on a screen.
When i learned programming as a child, the programs i wrote just produced text on a screen -- but text on a screen was an actually encountered everyday UX on the Apple IIe or Commodore 64 too.
I think it does make a difference how quickly you see yourself as making something that could actually be useful, and it's maybe harder to do that in 2023.
> After half a year we moved on to our second language: Lua, specifically in the video game system Roblox. I almost wish we had skipped this one because it was a bit too advanced for these students
I wonder if they meant Lua or its integration with Roblox was too advanced. I would think Lua is a simpler and easier to learn language relative to Javascript and D.
Lua's simplicity is a liability for someone new to programming. The tiny standard library means you need to write by hand a lot of things you could just use in another language. Arguably good for learning fundamentals, but in practice just a good way to kill momentum and smother that learning spark that is the best resource of a novice.
Similarly the best way for a learner to stay motivated is to make something they are personally invested in, which usually involves integrating with something. With lua you need to get your hands into the toolchain and distribution stuff very early to do that, which has nothing to do with programming per se and is frustrating and disorienting for a newcomer.
I've taught people to code from scratch and lua is a worse-than-average language for it. It's a small language but that doesn't help a total novice very much. It's the core concepts of programming that is difficult for them, not memorizing language features. The only situation where I would use it is if they have a specific motivating goal that uses it, usually yes roblox.
My 10 year old loves programming and has a fair number of hours in Scratch and Roblox.
I've noticed when messing around with Scratch, he quickly progressed from leaning the language to using the language to solve his own problems. He moved from following tutorials to creating his own games and ideas quickly.
When playing with the the Roblox editor he would follow the Youtube tutorials, but never made the leap to making his own games. Roblox scripting is fairly wordy, you spend a far amount of time binding methods to long event handlers. There is a lot of text you have to type, and spell correctly, and remember. 10 year olds are very slow typists. I also spend a fair amount of time helping him fix small syntax errors which slowly sapped his enthusiasm.
The drag and drop, and drop downs in Scratch really helped him move quickly from learning the language, to using the language to make games.
If you want a compiled language with strong types, Swift actually is a very nice language for learning. It has very nice ergonomics, and the Swift Playgrounds iPad apps are really nice and engaging.
The last thing you want is types when you're a beginner. TCL/Shellscript, for all its defects, just has strings, which means you have expr num OPERATOR num. you also just have commands. I've seen beginners try to set a variable from whatever is printed, so the concept of a return type is a tricky one. funny, now that I think about it, php is actually a great introductory language because it just prints everything to stdout.
> The last thing you want is types when you're a beginner.
I disagree. Data types are an intuitive concept. Integers and strings are obviously different, and you can do further and distinguish arrays, characters, and dictionaries.
I'd argue Python is slightly beginner unfriendly in this one way because variable types are implicit rather than explicit (unless you use type annotations), but still important, as you'll get a type error if you try to, for example, sum a number and a string.
Perhaps its because I learned programming via shellscript(rc not bash) and piping text into programs. I never had to deal with the difference between a string and a number unless I did something that actually needed the difference to be distinguishable. especially dealing with awk which just coerces greatly, hell, I didn't even have to deal with size limits since pure awk supports bignums. Sure, awk has types as well, but that concept came much later, especially things like scope. I think it both helped me and hurt me. I never understood why people said static typing was great, only after you had a huge program did you see where the pitfalls were.
That's an interesting perspective. It probably does have a lot to do with the first programming languages you learn. The first programming languages I learned were all strongly typed, so it seemed inherent to the concept of a variable when I learned it. I had to wrap my head around dynamically typed languages as "Ah, all variables are actually just pointers to structures with a tag indicating the type, and they can be rebound to objects with different types." When I write Python, I use type annotations, or I keep track of the type in my head, and use casts as convenient conversion functions. But, since Awk and shell script don't make you cast things explicitly as much as Python, I can also see how someone would learn programming with dynamic types in a really natural way.
My first program was in BASIC. I was 6, and had other things to do before I got back on that journey, but the next one was in PHP.
By conventional wisdom and common proverbs, my mind should've been mutilated beyond any hope of recovery. (And maybe it is, who knows.) But this conventional wisdom tends to ignore the barrier to entry.
The C64 not only booted straight into BASIC, it also came with a book, and that first program that I copied from the book was not some silly "hello world" or a fizzbuzz, it was a piano. It demonstrated to me, that a computer is a means of expressing yourself creatively, and it did so in a form that was digestible to a 6yro.
The best first language is the one that comes pre-installed on your computer, with enough example code to get you hooked. (Which is why the iPad / Swift Playgrounds fills me with both hope and dread. But, considering where I came from, mostly hope.)
Something I've been tinkering with for a few years now - a learning programming language that runs in the browser and makes it easy to draw on the screen.
Pretty much anything can be a viable first language. My first language was 1980s BASIC, starting with very limited version (ZX80 and then Grundy Newbrain). I do not think that was a good first language though. It did not teach good habits, and it lacked a lot of concepts I had to start learning later.
1. James M. Cook & Dawn Plourde. (2016). Do scholars follow Betteridge’s Law? The use of questions in journal article titles. Scientometrics, 108(3), 1119–1128. https://doi.org/10.1007/s11192-016-2030-2
2. Boris Peon. (1988, August 4). IS HINCHLIFFE’S RULE TRUE?·. Annals of Gnosis.
> I am confident that D can be a viable first language
Not sure what this confidence is based on, the basics are broken (toolchain, basic syntax errors you shouldn't even need a compile step to figure out, the squiggly error underline should be right there in your editor!), and what does sticking to "Vanilla D" offer as a benefit vs. some other language?
I’m not sure that the choice of the language matters a great deal for an intro course to be honest
There’s no way students can wrap their heads around advanced topics to the point where language selection matters that much
Of course toy languages like Brainfuck, low level stuff like pure assembly or archaic languages like COBOL would be detrimental to learning. But any mainstream language from the last forty years or so will have major crossovers with most others
I fail to see how D is that extreme compared to most other languages or any reason it should be pedagogically dismissed as a first language
> I’m not sure that the choice of the language matters a great deal for an intro course to be honest
Huge disagreement from me! The choice might not matter for the already motivated students who were going to learn to code no matter the language, but for folks on the fringe of CS the language matters immensely. There are arguments to be made about frustration, developer experience, grokability, but imo the most important is distance between code and gui. It’s very motivating to build something you can interact with. It’s very demotivating to work on contextually-meaningless algorithm problems.
agreed -- i really like python a lot for a first (and long term lang). it reads like english compared to C or Java and you could toss up a website or something like that very quickly with it.
It really does matter at least according to this paper [1]. However I think the paper missed one major sin of not having a GC for introductory programming language. D actually avoids most of these sins and it is GC by default.
[1] Seven Deadly Sins of Introductory Programming Language Design:
Not sure I agree. GC is essential in industry (well, I'd argue that! Ignoring embedded anyway) but I think the programmer has to understand the real cost, and that means allocating and de-allocating, and if that is hidden by the GC then they're not learning that.
True, but you don't need to get them to write C (or similar) in order for them to get to that point later on, once they can write basic stuff.
In that regard, D is excellent because it does allow you to write code without the GC once you've mastered the basics, so it may be a (very) advanced part of a course to optimize some algorithm by manually managing memory, and seeing how much difference it makes.
Sure they do. You can tell anyone to "just install IntelliJ" or "just install Xcode" and they'll have a working environment with zero effort. All the popular languages don't require handholding
I would attribute that to the language/company putting in the effort for an easy install. I am sure it is easy to install Swift on Mac but I was trying to guide my friend through it on Windows and he gave up because it was too complex and the installer didn't work immediately (some library path error).
SwiftUI and all the other Apple frameworks that allow you to do more than read and write text to a console don't work on Windows. Beginners should just use an IDE. If one isn't available for their language/platform, that's a sign of things to come
"Most people don't setup their own environment for their first language...."
Since most people probably try out js as their first language (often without knowing what js is) - setting upt the environment and IDE is as simple as open dev tools ..
But why? Why use esoteric languages no one knows?? Why teach someone a language they can’t use at work? Just teach Go it’s so simple and teaches you actually good practices unlike Python. Senior devs hate it and junior devs love it for the same reason.
I think “esoteric” is meant for brainfuck, maldbrot and similar. D, nim and co, are quite traditional in language design languages, just not popular (yet).
> 1. understood by or meant for only the select few who have special knowledge or interest; recondite
> 2. belonging to the select few
Just because some people give special meaning to the phrase "esoteric programming language," doesn't mean that people who don't know about it should be chastised for not knowing the... esoteric meaning of the phrase. This reeks of "my club uses this adjective only for this occasion, you're not using it right, you don't belong to the club, go away".
> An esoteric programming language (sometimes shortened to esolang) is a programming language designed to test the boundaries of computer programming language design, as a proof of concept, as software art, as a hacking interface to another language (particularly functional programming or procedural programming languages), or as a joke. … The creators of most esolangs do not intend them to be used for mainstream programming, …
And the death blow, by a fun fact: week has 7 days because babylonians named them after seven planets - Sun, Moon, Mars, Mercury, Jupyter, Venus, Saturn.
It seems to me less like some elitist exclusionary thing, and more like they're objecting to the idea that if a language isn't within top 10 programming languages used, it must be esoteric and only weirdos and enthusiasts use it.
If you don’t teach children to succeed at work and get ahead you are knowingly putting them at a disadvantage. If I knew programming when I was much much younger I would be in an even better position than I am now, and I’m in a great position.
Do you have any actual children? This is lousy advice. A parent's job is to love their children and provide opportunities for growth, not to teach them to "succeed at work". I can't think of anything more dreary than that, in fact.
You can't teach children how to succeed at work by having them learn whatever language is trending in the industry, if only because things will have changed and they will be remembering very little of it by the time they will be adult and joining the workforce.
You can teach children programming by using any language. You can do so even more effectively by teaching them many languages, to make them learn how to program rather than how to write code in language X.
If I knew programming when I was much much younger I would be in an even better
position than I am now
In what way? Looking at everybody I've known and worked with over my career, I'd say the correlation between how good they where at programming as a child and where they were in their career at 40 was basically zero.
I enjoyed that year and, for the most part, my "students" were easy to teach, and Pascal held up well. They were all programmers already, so I didn't have to go slow through the basics and introducing ideas like recursion (absent in Fortran, COBOL, and assembly language of the period) kept the classes new and interesting to the students.
Unfortunately, standard Pascal isn't really a good choice for a first programming language today, even though modern Pascals have removed many of early Pascal's limitations (packages, batteries included libraries, etc.)
So, how can we decide if a language is a viable first language? Employing the wisdom of crowds, here are the top 30 languages in the 2023 IEEE Spectrum rankings:
1-10: Python, Java, C++, C, Javascript, C#, SQL, Go, TypeScript, HTML.
11-20: R, Shell, PHP, Ruby, SAS, Swift, Dart, Rust, Kotlin, Matlab.
21-30: Scala, Assembly, Perl, Visual Basic, Objective-C, Lua, Fortran, Verilog, Groovy, Julia.
I contend that we should limit our choice of first-languages to some language in the top 30. This rules out many languages that I consider important, but we should stick with a language that is likely to benefit the student more than others as a first-language. That means not teaching Lisp or Racket or Ada or Ocaml or Prolog or even D for that matter as a first language.
To narrow our top 30 down to a handful of alternatives, I'm going to use my own subjective difficulty rating and remove C++ and Rust and Scala from the list because they will be too hard for beginners.
Furthermore, let's remove languages that aren't general purpose; this knocks out SQL, HTML, R, Shell, PHP, SAS, Matlab, Assembly, Visual Basic, and Verilog.
Some languages require more complex build or execution environments; I would remove Java, Dart, Kotlin, and Groovy from our list for this reason.
Finally, there are some languages that are not as easy to use outside of specific hardware or operating systems; I consider these languages C#, Swift and Objective-C to be ruled out.
For good measure, I'm removing Perl from the list (a bit too irregular) and Fortran (not widely used outside of some important areas).
Our condensed list now look like this:
Possible first languages: Python, JavaScript, Go, TypeScript, Ruby, and Julia.
To narrow it down even a bit further we can observe that one should learn JavaScript before learning Typescript. (Is this opinion shared by HN?)
Ruby and Python seem like close cousins with Ruby being a bit prettier and Python being much much more popular.
Julia is a bit specialized and a bit harder than the others so now we are left with just three: Python, JavaScript, and Go.