Exolon

Exactly! That's also why almost every slop commit I see has a linecount like +700 / -20, whereas human commits often end up net zero. I try to remove more lines than I add, if possible, but LLMs will just add more bloat, forever.

Same here. I was always more of an en-dash enjoyer, and used that back in academia since it's just a double-dash in Latex.

The number of times I've seen phrases of the form "(ingestion|main|ingress|success|designated} path" in workslop docs recently is frankly intolerable. Last week someone sent me a 50 page doc with a proposed update to a (small) system architecture. It was so boring that it took me all day to read it, but the information density was low enough that it could have been written (by the author instead of a chatbot) in like 3 pages. Endless tables comparing the "recommended path" against stupid strawman implementations, and repeated "DO NOT send packets directly to the ingress, ensure they go through ..." statements that were totally unnecessary. Utterly mind-numbing thought-terminating slop.

"Star chamber" is a fabulous term that would seem to describe the situation quite well. Thanks, added to my internal dictionary!

Imagine if someone wanted to play music in an orchestra, but couldn't read music because it was "too confusing", but they'd never even tried to learn. They would be laughed out the door.

I'm not sure why so many laymen devs you mention (who, incidentally, tend to have an affinity for learning music and other "esoteric" skills) seem to apply that same logic. Like, why not learn and try the basics before throwing your hands up and saying it's too hard. It isn't... although it is very, very different.

That's fantastic. It's a shame there isn't more stuff written (and especially, videos/streams) about K, but I get the feeling that will improve since there are a good few open-source K-like implementations (at least ngn/k, oK, ktye/i, kona, kuc and Goal). Recently I stumbled upon iKe (http://johnearnest.github.io/ok/ike/ike.html) which is pretty amazing.

> Your words betray your ignorance. Common Lisp has a type system. Have you ever written it? Do you actually know anything about it? Moreover, macros are a plus - you clearly have not actually used Lisp macros, [...]

This isn't really okay. It's fine if you disagree, but I don't get why such aggression is needed.

I didn't even "interview", just took one of their tests out of curiosity to see how I did. The announcement was especially unwelcome news given that I'm not even looking for another job.

I would dispute the idea that "if they were a lazy coder in TypeScript, they'll be lazy in Elm". The fact that Elm forces you to at least think for a moment about how handle the failure case is a good thing. Even if you're inclined to take the path of least resistance, as probably most of us programmers are, what does that actually look like?

You have one case branch that looks like:

  GotUserList (Ok userList) -> ...

and another that looks like:

  GotUserList (Err _) -> ...

Since we need to pattern match on both types of the Result structure in our update cycle, there isn't really an opportunity to implicitly gloss over a failure to parse. Of course you can try to make the decoder super permissive, but this is harder than doing it the right way. If you're REALLY lazy, you can throw in "Debug.crash" in the failure case, but there's no general solution for throwing grenades at your foot :D