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. 🤷

Is the link correct?

The website tries selling something, but I can’t decipher what exactly. Certainly does not seem ESP32- or Arduino-related.

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.

Always good to know that after sitting on it for 2 decades, shipping some half-assed shit was the best they could do.

Yikes, thanks! Good to know.

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

Good decision. Sounds like a decent human being!

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.

😂

Yeah, but compared to counting money, nobody cares if some physics paper got its numbers wrong. :-)

(Not to mention that would require the paper to have reproducible artifacts first.)

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 |>.