With respect, this take is a good example of all or nothing thinking. It’s not too late.

This. Fatigue and despair are by far the most effective way to control a population. You don’t need to convince people you’re doing the right thing, you just have to convince them that it’s too late.

Has no one written a python! macro for this use case?

That’s usually ok bc in most code your N is small and compiler optimizations dominate.

You’re not wrong, but that win would not get as many views. It’s not clickbaity enough

Some abstractions are obvious though. There is value in reusing them across projects and not reinventing the wheel each time. I don’t think this is counter to what you propose necessarily, just adding the nuance that abstractions serve another purpose: communicating intent to the readers of the code. Sometimes a concrete type is unnecessary detail.

Absolutely. I don't take that quote to mean we should all start from ground zero every time...if so experience wouldn't have much value.

I more think the point is that the abstractions now obvious to you emerged at some earlier point that you now recognize, and application makes sense. Speculative implies predicting, and if you've been around long enough in the same domain, it's likely you aren't guessing.

It's probably something that applies more to younger devs than older, but not exclusively of course.

I kind of feel like the specification would call for an idealized lock free queue. Whereas the code would generate a good enough approximation of one that can be run on real hardware.

To invert your polynomial analogy, the specification might call for a sine wave, your code will generate a Taylor series approximation that is computable.

A thorough specification might even include the acceptable precision on the sine wave; a thorough engineer might ask the author what the acceptable precision is if it's omitted.

I suspect your probably right, but just for completeness, one could also make the argument that LLMs are better at writing Haskell because they are overfit to natural language and Haskell would avoid a lot of the overfit spaces and thus would generalize better. In other words, less baggage.

I would guess they’re better at python and SQL than Haskell because the available training data for python and SQL is orders of magnitude more than Haskell.

> There's no good way to get a high fidelity change feed from a POSIX file.

Personally, my main point of frustration with git is the lack of a well-supported ast-based diff. Most text in programming are actually just representations of graphs. I’m sure there is a good reason why it hasn’t caught on, but I find that line-based diffs diverging from what could be a useful semantic diff is the main reason merge conflicts happen and the main reason why I need to stare hard at a pull request to figured out what actually changed.

Collaborative coding is a niche but possibly interesting use case. I’m thinking of notebook cells with reactive inputs and outputs. Actually not dissimilar to a spreadsheet in many ways.