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.
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.
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.
The comparison is not fair though. Modern music notation, despite all its faults, is the Fe facto standard. Many attempts have been made to improve it. Some of those attempts may have been objectively better but the cost to change the standard is too high.
You wouldn't be surprised if somebody criticized an alternative music notation as being too confusing or requiring too much effort to learn for little benefit if they already know the mainstream music notation
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 specifically avoided insulting them. "Ignorance" is not an insult; it's a description of your knowledge on a topic, and if it isn't the right word to describe telling such a blatant and fundamental misunderstanding, then what is?
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
