Comments URL: https://news.ycombinator.com/item?id=47342817

Points: 2

# Comments: 0

- Through the last two decades of the 20th century, Moore’s Law held and ensured that more transistors could be packed into next year’s chips that could run at faster and faster clock speeds. Software floated on a rising tide of hardware performance so writing fast code wasn’t always worth the effort.

- Power consumption doesn’t vary with transistor density but varies with the cube of clock frequency, so by the early 2000s Intel hit a wall and couldn’t push the clock above ~4GHz with normal heat dissipation methods. Multi-core processors were the only way to keep the performance increasing year after year.

- Up to this point the CPU could squeeze out performance increases by parallelizing sequential code through clever scheduling tricks (and compilers could provide an assist by unrolling loops) but with multiple cores software developers could no longer pretend that concurrent programming was only something that academics and HPC clusters cared about.

CS curricula are mostly still stuck in the early 2000s, or at least it feels that way. We teach big-O and use it to show that mergesort or quicksort will beat the pants off of bubble sort, but topics like Amdahl’s Law are buried in an upper-level elective when in fact it is much more directly relevant to the performance of real code, on real present-day workloads, than a typical big-O analysis.

In any case, I used all this as justification for teaching bitonic sort to 2nd and 3rd year undergrads.

My point here is that Simon’s assertion that “code is cheap” feels a lot like the kind of paradigm shift that comes from realizing that in a world with easily accessible massively parallel compute hardware, the things that matter for writing performant software have completely shifted: minimizing branching and data dependencies produces code that looks profoundly different than what most developers are used to. e.g. running 5 linear passes over a column might actually be faster than a single merged pass if those 5 passes touch different memory and the merged pass has to wait to shuffle all that data in and out of the cache because it doesn’t fit.

What all this means for the software development process I can’t say, but the payoff will be tremendous (10-100x, just like with properly parallelized code) for those who can see the new paradigm first and exploit it.

Could I speak Japanese at that point? No not really… I even had a Japanese spouse! But we spoke mostly English at home. I could read quite well, but conversation was very challenging.

Then we moved to Japan. Despite not having a job that requires me to speak Japanese, I got enough live exposure just from chatting with people at the gym or in social activities that now, a few years later, I’ve backfilled all that conversational fluency that was missing. No special extra effort required, just living in an environment where I used the language reasonably often.

Anyways, the point is that all the time spent in Anki laid a rock-solid foundation that merely needed activation in the right environment for active fluency to emerge. Of course I no longer do my daily flashcard drills (and I’ve forgotten how to write quite a few kanji as a result) but the work paid off.

From my own personal experience, this realization came after finally learning a difficult foreign language after years and years of “wanting” to learn it but making little progress. The shift came when I approached it like learning martial arts rather than mathematics. Nobody would be foolish enough to suggest that you could “think” your way to a black belt, but we mistakenly assume that skills which involve only the organs in our head (eyes, ears, mouth) can be reduced to a thought process.

Early resistance to high-level (i.e. compiled) languages came from assembly programmers who couldn’t imagine that the compiler could generate code that was just as performant as their hand-crafted product. For a while they were right, but improved compiler design and the relentless performance increases in hardware made it so that even an extra 10-20% boost you might get from perfectly hand-crafted assembly was almost never worth the developer time.

There is an obvious parallel here, but it’s not quite the same. The high-level language is effectively a formal spec for the abstract machine which is faithfully translated by the (hopefully bug-free) compiler. Natural language is not a formal spec for anything, and LLM-based agents are not formally verifiable software. So the tradeoffs involved are not only about developer time vs. performance, but also correctness.

It is the miracle of modern capital markets that enables almost anyone to quickly and easily invest their savings in productive assets, but of course capital markets aren’t perfect. The availability of “none of the above” options (like gold) that remove savings from the pool of active investment capital is the essential feedback loop that balances risk and return.

- To the greatest extent possible, base interfaces should define a single abstract method which allows them to be functional and instantiated through lambdas for easy mocking.

- Terminal interfaces (which are intended to be implemented directly by a concrete class) should always provide an abstract decorator implementation that wraps the concrete class for (1) interface isolation that can’t be bypassed by runtime reflection, and (2) decoration as an automatic extension point.

I’m also going to point out that this is a data structures course that I’m teaching, so extensibility and composability are paramount concerns because the interfaces we implement are at the heart of almost everything else in an application.

1. All public methods must implement an interface, no exceptions. 2. The super implementation must be called if overriding a non-abstract method.

The end result of strict adherence to these rules is basically that every feature will look like a GoF design pattern. True creative freedom emerges through constraints, because the only allowable designs are the ones that are proven to be maximally extensible and composable.

I thought that I would be using LLMs for coding, but it turns out that they have been much more useful as a sounding board for conceptual framing that I’d like to use while teaching. I have strong opinions about good software design, some of them unconventional, and these conversations have been incredibly helpful for turning my vague notions into precise, repeatable explanations for difficult abstractions.

The answer is not more natural language guardrails, it is in (progressive) formal specification of workflows and acceptance criteria. The task cannot be marked as complete if it is only accessible through an API that rejects changes lacking proof that acceptance criteria were met.