Comment by Mawr | Hacker News Reader

Comment by Mawr | Hacker News Reader

Parent Full thread

Don't get your hopes up, Crystal is doomed to never become mainstream.

We can divide programmers into two camps, those that enjoy programming itself and those who use it as a means to an end. The latter greatly outnumber the former, let's say 9:1. That massive disparity in numbers is why only the languages that enable the latter group thrive.

Ruby is the perfect example, the language got a massive exposure boost due to Rails, but once the hype died down, everyone left. That's because beyond Rails, Ruby has nothing to offer to programmers who want to get stuff done. Nothing besides pain, of course.

To those who enjoy playing with languages, "did you know there are 10 different ways you can filter an array in Ruby?" ([1]) is joyful to hear. But when you're woken up at 3am to find a bug in production `arr.reject(&:even?)` is the last thing you want to see.

This sort of cleverness, ambiguity and implicitness in language design repels 90% of programmers, and that is the reason why languages like Perl, Ruby, Scala, and now Crystal are either dead, dying, or destined to die.

[1]: https://news.ycombinator.com/item?id=35836570

(self-reply) Addendum:

EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]:

"The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called “the one-liners”. It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question “Can you code this in less symbols?” —as if this were of any conceptual relevance!— or he just asks “Guess what it does!”. From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of “richer” or “more powerful” programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. "

[1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD03xx/EWD340...

> when you're woken up at 3am to find a bug in production `arr.reject(&:even?)` is the last thing you want to see.

Really? Because even if you're seeing it for the very first time, it means exactly what you'd think it means. The only thing that's even potentially sort of tricky or non-obvious is the ampersand. And there's nothing implicit or ambiguous in the expression, either.

> implicitness in language design

In a sense, all languages have implicit aspects. Can you characterize the problematic implicitness? (I guess python's TOOWTDI helps, when reading code).

I've been studying bidirectional transformations, and a survey paper notes that "relational" methods have died off (somewhat "declarative", where you specify how things should be connected, with the details implicitly worked out for you... something like set-builder notation), while various coding methods remain (where you code for forward transformation, and the backward transformation is automatically derived). They hypothesise it's because relational tools (libraries and projects) are difficult to maintain - but I suspect it's because they are difficult to use.

Which is a shame: something that automatically "does what you want" seems like a great idea! But being difficult to predict and diagnose - not being in control - is not great. So, to rephrase my question, what characterizes "good" automation?

implicitness examples: precedence, type coersion, overflow, polymorphism.

But I suppose (e.g.) precedence doesn't arise that often; it "should" be familiar from high-school algebra; it can be made explicit (with parentheses or successive assignments).

"Explicit" would seem to be "obvious" - is that necessarily true? Too much code can obscure what is happening.

Familiarity helps implicitness be understood. Some would argue lack of familiarity is the only problem with the languages you mention. Certainly, it helps: as you become more expert in anything, you start using short-hand and jargon, and skipping details.

Adoption is easier when it's similar to the familiar. Hence, "c-like". And python, psuedo-code-like.

But are some things easier to grasp, by nature? I think, "intuitive" often means familiar. And there are things that all human beings are familiar with, like space, trade and language. Perhaps this is where intrinsically obvious and familiarity coincide?

Reply on news.ycombinator.com