Teaching programming languages: we’re doing it wrong
A call for debate on how to learn languages in the new century
As a new year resolution, I decided I had to learn Scala. It’s a nice, popular and functional language. So I purposefully started with Functional Programming in Scala. I shouldn’t have done it. I arrived to a point where I didn’t even know how to put whatever code I had written in a file and make it run. So I downgraded to Beginning Scala, where it started with the famous Hello world. A procedural, non-functional, non concurrent, Hello World.
At least it got me a bit further in learning the language. But when I wanted to compile stuff a bit more complicated than a single file, I had to go to
end of the book, where it devotes a single chapter to Scala build tools, or rather Scala Build Tool, the appropriately named sbt.
I ended up using StackOverflow more than the book itself when I actually wanted to do something.
Do you know the joke that says that programming courses should be renamed “googling stuff in Stackoverflow”. Well, it’s funny because it’s true.
But it shouldn’t.
“Hello, world” was introduced for the first time in a book to learn C. You know what they say about C programmers
Or Fortran, or Cobol…
… they are so good at programming that they are able to program C in any language.
There are several problems with that. First one is that current languages are so far away from C as C was from assembly language.
OK, bad simile. That’s not too much…
The second one is that it’s not only about the syntax, it’s about the paradigm. The whole world model that is embedded into many languages is completely different. R, Python, Rust, Groovy, node… can they be further away from the C sequential, synchronous, type-unsafe, single-threaded, procedural, non-functional world view.
Damn, I should have said weltanschauung here. Never skip a chance to use big words in Medium, ever.
But there is a big, fat, final problem. Languages are never alone in that world. They are part of a weltanschauung
That felt sooo good…
that includes, at least, build tools but then a whole well-connected network of operating systems, device substrates and oh so many things that are never, ever, included in that book that teaches that imaginary language. Even C had that. It was created for an operating system, Unix, with its own tools on which it relied; it did have a standard library, many common libraries such as POSIX and build tools such as make. Did all that get into the “Learn C real soon now while you wait in the queue to board the Zeppelin”?
It doesn’t fit into “Learn Futura RSN while you wait in the queue to board the space lift” either.
If you’ve been with me so far, my point is that when teaching any computer language, we should concentrate on the troika worldview + substrate + ecosystem.
Besides, when they learn a programming language, people don’t want to program, they don’t want to write programs. They want to build things.
Including a resume. Maybe exclusively so.
And I mean real things. Real client-server architectures. Real frameworks they can build on to create many different applications. Real apps. Real research workflows that produce something useful (read: publishable) at the click of a button.
So let’s enunciate a few rules, and I want the debate to start here if you have agreed with me so far, above if you haven’t,about what we should do
to teach to learn a programming language good and do other stuff good too
Let’s boil it down to a few rules.
I would love to hear your take on this. Maybe new rules. Whatever.
1. Never teach a language by its lonesome.
Acknowledging the existence of an ecosystem and a substrate means that a language is never taught by itself. Because along with it, you have to learn are at least two, and sometimes up to five different languages,
some of them might be DSL, domain specific or damn small languages, whichever way you might want to call them.
- The language itself. Of course.
- An UI language. Nowadays, in most cases, that language is HTML. In some cases you might need some UI description language defined using XML.
- A serialization language, which puts in text your data structures and sucks them back from that form. Almost always, that language is JSON, but it might be XML.
Was that M4?
2. Stack up for the greater good.
Do you think full-stack programmers learn, one by one, every single part of the stack? Or do MEAN programmers learn to be mean all at once?
No pun intended. No, what the hell, totally intended.
What actually makes a language great and popular is sometimes the stack and how it builds up to create applications. Which is what people want when they learn a language. They want to learn Scala to build stuff using Spark
Well, I did…
Of course, that means that you should build up on concepts such as map-reduce and model-view-controller and noSQL databases, which are part of the stack and intricately meshed with the language. That means that, once again, the stack should be a part of teaching the language. A good part.
3. These apps are made for booting.
And that’s what they’ll do. But in order to boot an app, you need to do several things: build it, test it and they deploy it. All that is specific to the language, and also part of the language.
We can’t keep teaching any language with the purpose of building single-threaded standalone desktop applications with them. Applications are complex, complicated things with many interwoven services connected via APIs, and we can’t pretend otherwise. Compiling whatever.futura and then run ./whatever form the command line just does not cut it. Even simple applications have dependencies, do source conversions or compilations before deploying and then eventually deploy to somewhere else, usually in the cloud, but always to a production machine or machines.
And we have DevOps. Let’s stop pretending when we teach a computer language we are a single programmer with a QA and a production department that will take care of all that later on in the future. We are all DevOps. And teaching a language should be DevOps too.
4. And DevOps work on teams.
How can you learn to create source without source control? Using a source control system
That is, git. For the time being and the foreseeable future.
to write your code and also interact with the rest of the team is essential even if you work alone developing a libre application in places like GitHub or Bitbucket. The source control system and the tools around it will allow you to interact with clients, create a community around it, but also interact with fellow members through issues embedded in milestones.
Because, remember, people wants to create a project. Working off a SCS from the get go encourages best practices for naming, creating a roadmap using milestones and issues, and also working systematically to achieve goals that can be measured and show up on tables. Working to close and issue is great and good. And gamifies learning.
Few source control practices are specific to a particular language, but best practices related to working on a team
Where to put the parentheses, naming conventions, so on
are. And it is the engine that usually makes the testing-deployment cycle go round, which is one of the best practices for creating projects.
5. Best practices are the best.
In order to teach and because in many cases learning subjects are considered brain dead or close to it, example code include an infinite amount of bad or worst practices, which then you have to un-learn when you set down to actually make something that will go to production.
How many times people print debug information from functions? Or use global variables when they shouldn’t (which is always)?
Or don’t include a single line of documentation along with the code? Code should be documented. Period. Beginning Scala introduces comments in page 31, right behind match expressions. And then proceeds to systematically not use them for the rest of the book.
If you’re anywhere close to a serious software shop, you know that functions should be tested or shouldn’t be. Untested code is broken code. But Beginning Scala does not even mention testing. Most books, in fact, don’t, leaving that for the upcoming “Testing Futura”. The Scala Cookbook, for instance, talks about testing in page 578.
Which means you’re back to StackOverflow.
6. But StackOverflow is there too.
And the rest of the Internet, of course. Most books don’t mention a single resource outside the authors or publishing house. But StackOverflow does not contain everything.
They’re almost there. Just wait a bit.
And if you have to ask a question, chances are if you don’t do it properly it will either not be answered or you will be voted down and your karma will go to the wolves.
And we don’t want that to happen, do we?
StackOverflow and other fora, including GitHub issues and mailing lists, do have a certain netiquette that should be followed. Learning it to get your questions answered is as big a part of the language as knowing how to create loops or compiling a file. Because people will have to do it anyway. And it’s the best if you teach them to do it good.
7. Remember to include the batteries.
Part of the reason I had to abandon Functional Programming in Scala is because I didn’t find anywhere how to read stuff from the command line. In fact, it’s not even mentioned there, nor it is in Beginning Scala. What about Scala Cookbook? Page 203.
If you want to do real stuff with a language, you need batteries: reading from the command line, a mini-framework for web publication, a math library to generate random numbers, reading and writing files.
There are all kind of languages, and some include these facilities in it, some have a standard library which includes them, some have several options one of which is considered best practice and other don’t. Leaving I/O, web things, UI and other things for the “Futura hacks” book leads to frustration and, probably, StackOverflow.
It’s difficult to know, however, how many batteries you need. That’s why a course or book is difficult to design. Maybe your best bet is to create a real application while you write the book, and include it as examples, do it in a source control system so that people can check in vivo its evolution and so on. But there are no silver batteries.
The Ikea batteries, for instance, are silver and yellow. And dirt cheap, too.
This is just the start.
I’m probably missing lots of things, but this is just a start, a call to action, a set of 7 rules that might eventually become 24. But I need your help. What do you think? Have you felt something like that when you were learning? Do you have a proposal on how to fix it? More examples? A banana? I want to hear from you!
After the fact, I have found this article which raised, two years ago, some points of this article:, focusing on how learning today is basically about the syntax and grammar and not the complexity of delivering business value. This article has the same motto: we’re doing it wrong. And it was written in 2012, commenting on “Learnable Programming”, a reflection on what learning a programming language really means. Same here: teaching programming is broken, but it focuses on the problem of grading, which does not scale up. That is so true… Even in the old and unenlightened year of 2009, somebody already thought up that teaching introductory programming war wrong.
This article muses how we’re still teaching programming like they did in the teletype era. “Hello world” is not only wrong, it’s also a residue from where the only thing computers produced were lines of text.