A question programmers frequently ask when they’re considering career growth or personal learning is “which programming language should I learn next?”
Why would learning another programming language help? If you only know one programming language and it is provided by a single vendor, then learning another will decouple your success from theirs, but that might not be such a common situation. Well, a book like Seven Languages in Seven Weeks makes the point that it’s not about learning the language, but about learning the model and thought process enabled by using that language. OK, so why don’t I learn that model or thought process, using the tools that are already available to me, instead of having to add fighting unfamiliar syntax to the problem?
And if what I’m truly trying to do is to learn to think about problems in a different way, a week-long effort at dabbling in a side project isn’t going to change my way of thinking. Those years of learned processes, visualisations and analyses are going to take more than a couple of hours to dislodge. I’ve worked through Seven Languages, and the fact that I spent a couple of hours solving the Eight Queens Problem in Prolog (or in fact telling Prolog what a solution to Eight Queens looks like and letting it solve it) doesn’t mean I now think about any other software problem as if I’m using a logic programming tool, or even as if I have such a tool available. I’ve spent much longer than that studying and using the relational calculus and SQL, but don’t even think about every problem as if it should be a collection of tables in the third normal form.
It may be that it would be useful to learn something that isn’t a programming language, shock horror! It turns out that programming is an activity embedded in a socio-technical system comprising other activities, and you might need to know something about them: software security, testing (I think I can count on my noses the number of programmers I’ve met who haven’t responded to the phrase “equivalence partitioning” with a blank stare, and I wouldn’t use all of my noses), planning, business, marketing, ethics…I even wrote a whole book on the things programmers should know that aren’t programming.
And then there’s the thing that your customers, clients, colleagues, or victims are trying to do with the software. Learning something about that would make it easier to empathise with them, to evaluate your solutions in context, and to propose better ways of working and better ways for your software to enable their work. Rewriting your code in Elixir would…not do that so much.
“OK, so why don’t I learn that model or thought process, using the tools that are already available to me, instead of having to add fighting unfamiliar syntax to the problem?”
As Greenspun, Yegge, and others have pointed out, because syntax is fundamental to language. That’s like asking “Why not learn Latin declension using familiar English words?” It doesn’t work that way.
If you tried to write CLOS’s MOP in C, for example, you’d first need to implement several layers, because C not only lacks multiple dispatch, but objects, lists, closures, symbols, (non-trivial) macros, and a whole host of other things that the MOP requires. In fact, the most efficient way would be to implement Lisp in C, and then build CLOS on top of that.
You don’t even have to do something sophisticated like MOP to run into trouble. What is a function call? What is a string? What is a number? The answers to these questions vary greatly across languages. Write a Scheme function call in C syntax: which semantics does it adopt? If it’s “C”, then you aren’t really teaching any new concepts. If It’s “Scheme”, then you’re really going to confuse the C programmers because nothing acts like how it looks.
It’s been shown that the number of bugs is roughly proportional to the number of lines of code, in any language. That shouldn’t be surprising. When you’ve got constructs which are an order-of-magnitude shorter (or more) to write in a different language, it’s worthwhile to have the reader learn this new language. It increases understanding. You’re not doing any favors by punting on syntax. You can write something like CLOS in 25,000 lines of C, and newcomers may understand the syntax of each line, but nobody will be able to see the big picture because the language wasn’t designed for what you’re trying to show.