Is it surprising that a “worse” language won, when Scala kept making one strategic blunders after another for more than 10 years?

It’s not as if they didn’t know they were making costly mistakes, they just didn’t care.

Absolutely wild that apparently some people thought this was a good idea.

spitzensparken blinkelichtzen

What a fucking retard that guy is.

Ruby’s identity appears to be largely DHH?

Then do whatever you need to do to stop freaking out about other peoples’ right to choose to not deal with LLMs.

Jeez. Calm down.

Sadly, the developers of these apps can’t even be bothered to not dump random folders into $HOME. 🤷

I tried it and moved the directory. Results:

• Firefox opens, settings from the profile are still there.
• Empty ./mozilla/extensions directories are recreated on startup.
• Firefox cannot show any websites anymore.

Yikes.

Considering how they fuck up everything they touch, is this more of a sabotage?

Ok, didn’t want to discourage you!

Might be useful to some, but the underlying assumption that “more features = better” is questionable in general.

Just take the L and go away.

What an absolute bunch of nonsense.

If that’s were your performance problems come from, you are either a junior developer yourself or using some PHP-quality framework written by juniors.

I can see the point that too many program elements get too much color, but:

Suggesting to not color keywords and use a single color for the names of top-level elements at the same time simply doesn’t mesh well.

I’m coloring keywords exactly because I do not want to invent a new color for each individual top-level element name or require backtracking from the (in his proposal) highlighted name to the (in his proposal) non-highlighted keyword preceding it.

Looking at the code example here I’d be open to have less things highlighted, but where to start? I guess parameter names, but apart from that?

I’m working on Core whose primary design goal is to not invent any new features, but implement existing things correctly.

The grammar is implemented with recursive-descent, one could define an equivalent EBNF, but I haven’t found the need to do so yet.

Working on my programming language, and improving some blog posts of mine. :-)

It’s interesting to me, because I wrote an article giving an overview of the possible combinations mentioned in his blog post a few years ago.

This is one of the rules I religiously follow in the design of my language.

It’s one of the reasons

• why I removed unary operators like ! and ~ and made -foo.bar parse as (-foo).bar;
• why the order of elements in a type or function definition is the way it is; and
• why I use an OOP-style value.member design instead of piping syntax like |>.

Kinda nice that they are adding Algol68 unions to C#!

Removing let-else is the whole point of the linked article series:

Being able to do to everything Rust does, but without Rust’s zoo of if-then-else, match, if-let, let-else etc.