When developing a piece of software, the choice of programming language is moderately important, and the larger the project (in terms of longevity and/or scope), the more important this choice is. On one end, if you’re just writing a short one-off script to do some data processing, you should just reach for whatever language you’re most comfortable with, because you will spend most of the time actually typing code. On the other end, a large project that will need to withstand multiple maintainers, modifications, and new features does require quite a bit of planning and anticipation.
But I think Graham takes it a little too far. He gives the impression that choosing the wrong language—or even not choosing the best language—will drag the project down and hamper its commercial viability. The reality, in my experience, is that every project can be successfully implemented in any mainstream, general-purpose language. Of course, certain languages are better (quicker or shorter to program in) than others, but there typically isn’t a wrong language. Asserting that there are inherently bad languages is contrary to the hacker mindset; spending hours researching or thinking about the pros and cons of languages doesn’t seem very hands-on. Instead, we should be encouraging people to dive in, pick a language and run with it. If it turns out to not work out perfectly, that’s still a better outcome than paralysis over choosing the best language.
His advice is more sound for an experienced, multilingual hacker, and I think that’s who he was aiming at. This type of programmer has learned and tried a multitude of languages and has a strong sense of the strengths and limitations of each language. They can quickly and intuitively decide on a good programming language for a particular project. However, it takes a great deal of experience to reach this level, and it would be unwise for a beginner or intermediate programmer to choose one or a few favorite languages (even if it includes Lisp) and assume these are always best. Different people think differently, so there is no one silver bullet that every person will program the best in.
To some extent, I think I fall victim to the “Blub” mentality that Graham mentions in “Beating the Averages”. I am very comfortable in C and Python and JavaScript, and I do sometimes think features in more non-traditional languages are weird and avoid them, rather than learn to harness their power. For this reason, it is difficult for me to assess what is missing in our current set of tools. Meta-programming and macros seem powerful based on Graham’s description, but I don’t understand them well enough to see how or if they can truly be revolutionary.
I think that strong typing will continue to be popular, and weakly-typed languages will turn strong (like TypeScript adding types to JavaScript). This is no longer for the purpose of memory optimization or compiler limitations, but rather for robustness and developer assistance. I believe artificial intelligence–generated code is still a ways away from being practical, but just like we have automatic assistance for drivers instead of widespread self-driving cars, intelligent assistance for programmers will continue to improve. If an IDE knows the structure and types of variables and functions, it can offer suggestions, analysis, and bug fixes, which will make programming faster and more robust.