A key reason is that so many CS concepts are already well packaged in very nice libraries or frameworks. And unfortunately many people do not have to use very advanced CS concepts. Look at the so-called top 10 algorithms or data structures for , how many of them are invented recently, and how many of them do not have an amazing library of production quality? Note this does not mean that the CS field is not advancing. It's just that we have yet to find another hyper-growth area that demands novel algorithm, except probably the AI infra - except that only very few people get to work on that area.

Exactly! There's so much paperwork that a doctor sometimes need two assistants just for the paper work. There's so much cost for independent practice that increasingly more doctors end up joining big hospitals. Charges with and without insurance have a huge difference. Just to name a few.

> while Go forces channels for `select` whether they model your problem nicely or not, and they're very difficult (often impossible) to wrap without changing semantics.

I understand that Go's concurrency model is based on CSP and fork-joins and the primitives like locks, but they are not mutually exclusive with concurrency containers, right? It's okay if the Go team's core philosophy is that channels are the universal abstraction, but I don't get why the community didn't produce 3rd-party containers as robust as JCTools.

True. And there is another angle: ownership. The author also said “having clarity on the priorities” boils down to “just tell me what to do and don't switch it up every two days”. This is like saying that a programming language designer does not own the spec of the language itself but just wants to write hte compiler. I find such altitude counterproductive. Case in point, many companies hire PMs for their internal infra org. I mean, shouldn't the engineers in the infra org know exactly what they design to build? If you don't want to own what to build, you end up letting someone else tell you what to do, except that the person is neither an expert nor even your user.

I still read TAOCP occasionally as a hobby. The combinatorial algorithms and data structures are just fascinating. That said, this argument seems irrelevant to majority of the programming jobs. I doubt most engineers will ever need to implement anything mentioned in TAOCP, thanks for all kinds of powerful abstractions.

I'm not sure I follow the logic here. Wouldn't this mean that product design is hard?

That said, yeah, coding is hard. I suspect that those who claim that coding is not hard are high-level ICs. For better or for worse, as the size of a company grows and as one's career progresses, engineers will often tranform to professional box drawers, expert meeting goers, seasoned report writers, fierce gatekeepers...Anything but deep coders. Over time, they lose touch of the actual building and think that any code can be handled by people under them.

People like Jeff Dean, who still codes and optimizes things like TPU kernel code, is very rare.

Eh...not that different from pre-AI era, when executives have more confidence with people who can talk smoothly and confidently?

Is it possible that the effectiveness of an LLM user with respect to the expertise of the user is like a sigmoid function or at least a step function in that shape? That is, one has to know something like the basic concepts and the vocabulary to bootstrap a programming project, but one does not have to know too much to do lots of meaningful work, and then again one needs to be en expert to build something extraordinary. Since most of the work is somewhere middle, most of us mere mortals are still concerned or stressed out for the possibility that LLMs will squeeze out too many job opportunities.

Modern AI feels like a godsend to mathematicians. It helps them break down boundaries and connect concepts in ways a mere mortal couldn't imagine.

Very true. Unfortunately, when there are people, there will be politics. I remember when reading Yau's autobiography, I kept marvel how much calculation, or "politics" if you will, that Yau mentioned or implied in the book.

> My guess is the outcome would have been the same for the same reasons?

At least Zhang didn't have to spend 7 years working on the Jacobian conjecture. He said in an interview that he always wanted to work on number theory. Moh asked him to work on Jacobian, and he obliged.

Interestingly, Yitang Zhang of the twin-prime-conjecture fame spent 7 years working on the Jacobian conjecture under the advisor Tzuong-Tsieng Moh at Purdue. A key step in his thesis used a corollary of Moh's. It turned out that the corollary was incorrect. As a result, Moh refused to write any recommendation letter for Zhang, and Zhang couldn't find any teaching or research job and ended up spending years working at a Subway[1].

Imagine Zhag had ChatGPT in 1986 when he started working on the Jacobian Conjecture.

[1] Of course now this has become an inspiring story. That said, the story definitely invokes complex emotions. The best way to describe it is probably this Chinese poem, which I have no idea how to translate: 庾信平生最萧瑟，暮年诗赋动江关

I agree with the lesson too. Just to be precise, wouldn't the current model war be more akin to open-source office suite versus MS office suite? If so, then the cheaper option didn't really win. That said, the open-source alternatives didn't really feel the same as MS Office, and it took them a long time to reach the feature parity (or did they ever?). In contrast, the open-weights models are getting close enough to the SOTA models, and users can easily switch from one to another without feeling any difference for mojority of the tasks.

Maybe killing Anthropic is a good thing? Anthropic believe that they are the moral god and they get to determine what we can do and can't do, and they get to tell us what model to use and what not to use. I find it very counterproductive.