It's orders of magnitude cheaper to serve requests with conventional methods than directly with LLM. My back-of-envelope calculation says, optimistically, it takes more than 100 GFLOPs to generate 10 tokens using a 7 billion parameter LLM. There are better ways to use electricity.
How this works is the LLM predicts the probability of the next token and then an arithmetic coder turns that probability distribution into bits. So it will never hallucinate. In the worst case, when the LLM makes an outrageous prediction, you just use more bits, but it doesn't affect correctness.
My main point is that these jobs are fundamentally different and people spend their time differently as a consequence.
At this point, I am more curious about how what I argue even comes across as me feeling superior or being disrespectful to people who aren't developers. (I am not a developer and would rather spent all my time running if I could)
Not writing code doesn't equate to not working. Thinking, documenting, designing, discussing, etc are all important parts of their job. I don't understand why you seem offended by my take on this. This line of reasoning doesn't by any means diminish athletes/musician's work.
Training is work but their main “events” are just much shorter than say that of a programmers. Even the longest athletic event like TdF lasts only several weeks. A programmer or lawyer worker 9 to 5 (at a minimum) doesn’t have time after work to practice.
Athletes and musicians pursue fundamentals because they have time; their “work” occurs in intense but short bursts of performances, leaving them the rest of their days to practice. Knowledge workers don’t “practice” because their job (long-term research or whatever) demands much more time and commitment.
> Functional programming doesn't have state, so you don't need locks, so you can get better concurrency.
This is not true.
Many algorithms are intrinsically imperative (e.g., quicksort). You can represent it using some monads in Haskell to hide this, but in the end your code is still imperative; and if you want to parallelize it, you still have to think about synchronization.
It's related to intelligence in the sense that being able to predict well requires intelligence and helps compression. If you have an intelligent model that predicts new words with high confidence, then you can use fewer bits to encode them. If I were to be even more handwavy, I would say having the ability to summarize effectively is a sign of intelligence.