Thoughts on Racket2

Most evidence based research into PL seems very inadequate, and I'm not sure we'll ever have good experiments. How do you measure the language over its level of mastery? Certain novice somewhat being more productive or making less bugs on trivial programs in beginner contexts doesn't tell you much.

Also, the very clear PL improvements have mostly been universally adopted. Lexical scopes for example, if/else conditionals, procedures, runtime types, GCs, dependency managers, unit and integ tests, etc.

It's only the insignificant details which are often debated. And for those, I think it becomes much more a decision to be made by masters, like your favourite chef knife, you pick what best fits your style and maximises your own productivity while minimizing your own weaknesses.

You can reasonably make the argument (and I do) that the reason why mainstream programming culture hasn't adopted parenthesized s-expressions is not because they're inherently less readable, but because of massive bandwagon effects + inertia of C-style syntax due to the proliferation of...C-style languages, which trains peoples' minds to prefer said syntax, even if their steady-state characteristics are worse than that of s-expressions.

I fully agree with the bits about transparency, and would add to that...

The best outcome I can imagine from the recent would be if the leadership articulates unambiguously what I've been calling the "top-level requirements" that guide everything else in Racket. (I have a pretty good guess at the top-level requirements thus far, based on history. I'm also pretty sure that much of the user community still has mistaken ideas about that. Another reason for articulating these top-level requirements is that they might be changing now, as it seems a few things are changing.)

After the top-level requirements, as a guide and to also let people know where they stand, then it would be good to have a well-considered model for whatever input (and possibly decision-making) is wanted from the non-leadership.

One reason could be altruism. If you believe your tool is superior to the tools that most others are using you may be highly motivated to convince those people to upgrade.

Another reason could be that higher popularity leads to more jobs.

I think that there's a difference between a concern with popularity, which this article demonstrates, and an obsession with popularity, which may afflict parts of the Lisp community (not LISP any more, at least in most dialects) but isn't clearly demonstrated here.

If quantitative popularity is important at all, then surely it is percentages and not absolute numbers that are most important (e.g., in 2016, Hillary Clinton got more votes in Texas than in Delaware—15 times more!—but that's not the relevant number).

Even if quantitative popularity isn't important, surely some basic level of popularity is to be desired by fans of the language; and it must continually be renewed, not taken for granted. Note that more than the popularity of the language as a practical tool is at stake here; the article specifically talks about the declining popularity of Lisp as a teaching language, and, whatever language you use later in your hacking career, it's a shame to embark on that career not having been exposed to the ideas of Lisp (although, to be fair, those ideas have disseminated so much into the mainstream that many of them can be at least as easily found outside of Lisp as inside it).

Now, you could say you are a startup and need the advantage. Good, you can do it, but you might have to supply more code to fill the gaps and deployment might require some extra knowledge (ecosystem problems). Its a value judgement as developer productivity isn't the only part of your development. Still, you can have a heck of an advantage. Look no further than the founder of this board, but remember the second part of the story. The Lisp got rewritten because it wasn't a comfortable choice for the new owners.

Perceived popularity means comfort and ecosystem.

they've already got that ability.

it just results in languages which can't interoperate. and it takes them a lot of effort to get a garbage result.

i suppose that "[it] does not work out well" is a reasonable description of the current situation. maybe you're actually arguing _for_ racket!

What does it mean to make the language stupider?

Ruby is popular because of rails. I don't think the making racket stupider or more familiar will create an analogous scenario to ruby and rails.

Some to look at: Racket, Guile, Gambit, Chicken, Bigloo, Scheme48 (and Scsh).