Leaving Haskell behind
Basically, the author&#x27;s criticism is that the language is too powerful, too expressive, people try very abstract things, tooling is bad and no one cares about the language.<p>There is something sinister in this - first, in the author&#x27;s lamentations about bad tooling. Other languages require linters, formatters, static analysers, etc. because the language&#x27;s built-in features and type system are sub-par. In Haskell, that&#x27;s not true, so the lack of &quot;sophisticated&quot; tooling is way less painful.<p>Second, this is similar to the &quot;equalise things by dragging everyone down to the same level&quot;-type of thinking. It &quot;makes maintenance a chore&quot; because the language allows you to be creative and shoot yourself in the foot! Sure, you can have languages like Go where the language is simple and it&#x27;s hard to write &quot;unreadable&quot; code, but that comes at a cost of being very verbose, and not allowing for an opportunity to write <i>really good</i> code. Basically, enforced mediocrity.
&quot;Hard to maintain&quot; is also used as an euphemism for &quot;this is too complex and I can&#x27;t be bothered to try to understand it&quot; sadly. I find that quite ironic in the face of all the needless complexity in the software industry (just look at k8s, terraform plugins or the web development stack)... I know way too many programmers like that, who argue endlessly about what is the &quot;most readable&quot;, which in practice just means to write the most straightforward, laziest, zero optimisation code, and giving themselves an excuse for that.
Even if a less-capable language hinders development (either by making things non-verifiable like no proper optional&#x2F;nullable handling or simply by making the code more verbose and&#x2F;or less readable) their advocates justify it on the basis of being standard or &quot;best practice&quot;. I think Haskell and similar languages intimidate similar people because they can&#x27;t shrug and say &quot;well the language can&#x27;t do that&quot; to justify their laziness, but would have to actually make a reason up to why they don&#x27;t want to write sound, safe and performant programs.<p>Third, about backwards compatibility.... this is a &quot;damned if you do, damned if you don&#x27;t&quot; situation. On one hand, you have languages like C++ and JavaScript which are really backwards compatible, and have really sizable drawbacks because of it. Sure, your code will compile in 5 years most likely without changes, but the language as a whole suffers because of it. There should be a place for languages which are ambitious and aren&#x27;t afraid to break things. Backwards compatibility is simply a design aspect, not some holy commandment you must adhere to all times.