Death of a Language Dilettante

I find there are roughly two categories of languages that are worthwhile (based on my opinion of course).<p>1. Easy to write&#x2F;produce: Languages&#x2F;Framework that are easy to write because they are highly expressive (Haskell&#x2F;Scala) or are very opinionated (Rails).<p>2. Easy to read&#x2F;maintain: Verbose languages with excellent tools... cough... Java&#x2F;C#.<p>As for reading code I don&#x27;t know what it is about crappy verbose languages but I have yet to see Java&#x2F;C# code that I couldn&#x27;t figure out what was going on. Sure I have more experience with these languages and the tools (particularly code browsing with an IDE) make it so much easier... but so do most people.<p>The reality is language dilettantes think writing code is painful (as mentioned in the first paragraph by the author) but the real bitch is maintaining.<p>I feel like there must be some diminishing returns on making a language too expressive, implicit, and&#x2F;or convenient but I don&#x27;t have any real evidence to prove such.

There are a couple of implicit assumptions in the final paragraphs that I think should be made explicit. One was that we can evaluate these languages based on this experiment <i>with a single programmer</i>. Another was the not-clearly-defined term <i>strong work ethic</i>, by which I <i>think</i> he means someone who will strive to make the program work properly, not have horrible kludges, will avoid known problematic aspects of the language, etc.<p>The problem with these assumptions is that you don&#x27;t run into situations like that often. You&#x27;re far more likely to run into a team of people of mixed abilities, and with some languages, one or two of them will be able to inflict horrors on the whole codebase.

Temper the soldier rather than steel, and a club becomes a sword. A fairer example might be to compare the Nix and Guix package manager codebases, which aim to implement the same model of declarative system wide dependency management. The former is written by a university team in C++ and Perl, the latter by GNUcolytes in Guile Scheme and a touch of C.

My take away here is that it only pays to be a programming language dilettante if you are actually building a programming language, especially if it&#x27;s a dedicated language for a new platform. Otherwise, you&#x27;re mostly going to be subject to whatever&#x27;s already mostly in use on your platform of choice, up to minor tweaks in that language over time.

Unfortunately, the real value of anything is almost entirely due to extrinsic factors. Air? Very valuable if you&#x27;re underwater, on the moon etc.<p>Which human language? The one spoken by the people you need to communicate with is most valuable.<p>The first iPhone? Very valuable then; not today.<p>But some people love intrinsic value. And it&#x27;s what they create that ends up having real value. They would say that intrinsic value is the only &quot;real&quot; value. They aren&#x27;t very practical.

Give me Scala and a real-world problem vs someone using using PHP or Javascript and I will beat them on the initial write, and destroy them on the maintenance. I wouldn&#x27;t use Scala professionally if I didn&#x27;t believe this.<p>In the short term practical concerns can be more important than PLT ones - in five years&#x27; time I&#x27;m sure Idris will be a better language than Scala, but for some tasks it isn&#x27;t yet - apart from anything else, you need a strong library&#x2F;tool ecosystem before a language is truly useful. But that&#x27;s a temporary state of affairs. If you were making this kind of judgement 20 years ago, and chose a popular language like Perl or TCL or C++ over a theoretically-nice language like OCaml or Haskell, how would you be feeling about that decision today?

It seems to me that if everyone followed the kind of pragmatism that this post argues for, nothing new would ever be adopted.

This article isn&#x27;t exactly wrong. Certainly, running on your target platform and having library support for the things you&#x27;re trying to do are critical features for getting anything done, and a great language that lacks these things in the wrong tool for the job. That doesn&#x27;t mean criticism of bad design choices in, say, Javascript is mistaken, or as the author describes it, &quot;troubling&quot;. It just means you probably have to use Javascript anyway[0].<p>It also leaves out another reason for learning languages and using them for pet projects: it makes you a better programmer. The more good languages you know, and idioms from those languages, the more likely you are to recognize when an ad-hoc implementation of one of those idioms is the right solution to a problem in the language you&#x27;re actually using.<p>[0] Though possibly only as a compilation target.

When doing serious development and hitting these issues, the workaround isn&#x27;t to continue using a broken language. The workaround is to use a different language. The first question &#x27;Does this language run on the target system that I need it to?&#x27; isn&#x27;t a yes or no question.<p>Take a look at this example - <a href="http:&#x2F;&#x2F;blog.fogcreek.com&#x2F;the-origin-of-wasabi&#x2F;" rel="nofollow">http:&#x2F;&#x2F;blog.fogcreek.com&#x2F;the-origin-of-wasabi&#x2F;</a><p>A language that compiles to PHP and ASP, what a relief.<p>And for the contemporary result - <a href="http:&#x2F;&#x2F;blog.fogcreek.com&#x2F;killing-off-wasabi-part-1&#x2F;" rel="nofollow">http:&#x2F;&#x2F;blog.fogcreek.com&#x2F;killing-off-wasabi-part-1&#x2F;</a><p>When the platform catches up, then you can go back to mainstream development with a useful language.

<i>Even something as blatantly broken as the pre-ES6 scoping rules in JavaScript isn&#x27;t the fundamental problem it&#x27;s made out to be. It hasn&#x27;t been stopping people from making great things with the language.</i><p>No, it hasn&#x27;t been stopping them, but I guarantee you it&#x27;s been slowing them down, at least a little. If nothing else, it makes the language a little bit harder to learn than it needed to be. I&#x27;ll wager it also causes actual bugs that people have to spend time tracking down. It&#x27;s true that those bugs can be avoided by proper discipline, but the brain cells required for enforcing that discipline could have been used for something else.<p>ETA: I agree with the author that a certain pragmatism is useful in selecting a language for a particular project, but I still think it&#x27;s important to raise people&#x27;s consciousness about warts in language designs. Doing so improves the odds that the next language someone designs to scratch their personal itch, but that happens to catch on for some reason, will have fewer such warts.

matlab? custom function was (or still is?) a one-function-one-file. i had bunch of function-files in a project directory. my mind was literally scattered.<p>then i moved on to languages that allow binding function to variable. i had much less files. simpler.<p>FP with anonymous function further frees my mind from naming variables so i have zero chance of mistyped function names. easier maintenance? sure<p>those didn&#x27;t stop me from getting work done; however, i prefer to not waste time on weaker programming languages, although coding on those languages did broaden my mind (yeah, now i know they suck)

Kinda mean to Ruby.<p>Also misses the point, it&#x27;s not the job at hand that matters, it&#x27;s the 10000 jobs that keeping the thing alive that matters.