Let’s establish a few terms.
Computation is what computers do. And a programming language is a system for expressing computation.
I take it as an article of faith that the value of a programming language is the degree to which the language makes it easier to reason about computation. This is a departure from the implicitly stated value of a programming language in Hague’s article, which is to “reduce the pain of programming.” I think the latter is reducible to the former. But if you don’t say that outright, I think you can miss it. A lot of Hague’s article expresses a sense that he and others are using the wrong programming language; that there are certain languages that are appropriate to use, and others that are inappropriate to use, and that too many people are using the inappropriate ones. That is, it seems that a lot of his dilettantism is driven by a sense of anxiety about his chosen milieu and tools at a point in time.
Programming, I should say, is reasoning about computation. That is, not exclusively writing the code the first time, but also coming back to it and making changes, and having a solid enough mental model to explain the behavior of the system to others. And in my opinion there are some languages that make this easier than others, and I’m actively interested in learning them and working in them. This does not mean that the languages which make it easiest to reason about computation are the appropriate ones to work in. A good, proper, modern functional language is a delight to me, but I am primarily a Python programmer and will reach for Python most times. This is not simply because I haven’t put in enough effort to learning J—that’s one reason among many that Python, which is probably not as good a language as J, is much more often the right tool for the job.
After all, I think it’s quite arguable that idiomatic Python style (and Python is language and community with a particularly acute focus on idiomatic style, much for the better) has shifted (perhaps with the rest of the mainstream programming community) to a greater embrace of functional principles. Generations of Python programmers, myself included, have bit by bit spent a few weeks or months trying and mostly failing to wrap their heads around Haskell, but have returned to the fold with a greater appreciation for referential transparency, for the minimization of mutable state, for orderly and perhaps somewhat austere scoping (maybe even for types?). Clawing our way through the first half of Learn You a Haskell For Great Good! has given us new skills in the art of reasoning about computation, which is roughly equivalent to making us better programmers.
And this is the blessing of dilettantism. I think that’s an important word, if somewhat inapt for much of the habits and motivations described in Hague’s article. Dilettantism is not technocracy or progressivism, and the dilettante need not spend their life in search for the better and ultimately best way. The dilettante allows themselves to sample and dabble, to dip a few toes, to paddle around, to put up a repo with the first 7 Project Euler problems, and then to recede and carry on their merry way. Once in a while they will hit on something marvelous that really speaks to them and become a True Believer. This is a grand thing and I live my life in the eternal faint promise that at some point in my life I will spend my whole days thoroughly ensconced in one tiny corner of the programming language firmament that has made itself known to me as The Best Way, where all the libraries are well-formed and all the code is concise, and until that day I am content and grateful to dabble, with the knowledge that every new expression of this same computation that all computers do might grant me a new and valuable perspective.
|2017-06-06||Compile-Time Sort in Nim|
|2017-05-07||Unit Testing in Nim|
|2017-02-19||Nim for Python Programmers|
|2017-01-12||The Dark Path, or, What if I Don't Want to Quit My Job?|
|2016-05-30||Thoughts on "Death of a Language Dilettante"|