I’m not a computer scientist; I’m not a software engineer; I am a programmer. I see the difference as being between a theoretical view, an engineering view, and a “craftsman’s” view of creating software to run machines. That is to say; I don’t build software, I craft it. Everything is unique, hand-made. Tools matter to me in so far as they let me express my craft. I want the tools that best help me do the work.
Here is a list of languages that I have used to solve real problems. It does not include those I learned purely for the fun of it.
- 80×86 assembly language
- C
- C++ (although the C++ of the ’90s, exceptions were new back then)
- Java
- Perl
- Javascript
- Usertalk
- Ruby
- Objective-C
- Clojure
- Elixir
The choices in bold are those languages I’d go back to reasonably happily. Here are languages I actively avoid:
- Python
- Javascript
- PHP
- Go
- Swift
- Scala
My reasons here, as much as anything else, are reasons of taste. Python I dislike because I don’t think significant white space is a good idea (as opposed to programming in an outliner which works well and I’ve no idea why the Python community never cottoned on to this) and I never liked its feel.
Go, Swift, and Scala, are on the list because they make choices I find distasteful. For example, Swift feels like the authors have to include every possible good idea from the programming field. I’m reminded of this by Antoine de Saint-Exupery “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.”
More language authors should take a stand like Rich Hickey and José Valim by having a language philosophy dictating that they reject good ideas because they don’t fit that philosophy. Their languages feel coherent, and designed toward a purpose. They choose not to include the kitchen sink.
The reason I am thinking about all of this is Javascript, a language I have used to solve real problems yet, given a choice, actively avoid.
I’m sure there are good things about Javascript if you look hard enough. It’s near-ubiquity makes it a winner, and I wouldn’t criticise another’s choice to use it (esp. if they are a competitor). But, improve as it may, Javascript has cruft encoded into its DNA, and that cruft leaks out in every direction.
For a new project, I am learning Elixir and its web framework Phoenix. And do you know what has been the most challenging thing? Webpack. Worse yet, Webpack is a tool written in Javascript (using nodejs) for managing project Javascript!
Whenever nodejs hoves into view, I tend to find myself waist-deep in a mess of dependencies and version incompatibilities. Perhaps I have been lucky, but I don’t experience this level of pain elsewhere. So it makes me think it’s a function of the choice of language and the kinds of people who are aligned with those choices.
I guess it is the craftsman’s curse: You come to care about the way the tools allow you to express the work and, therefore, feel pained when forced to confront tools that feel wrong.