~1957
Machine Code → Assembly
the original sin of abstraction
the first programmers toggled switches and punched binary. when assemblers arrived, some viewed mnemonics as a crutch that obscured the true machine state. von neumann himself — the man who invented the architecture — was furious when a student at princeton built an assembler, calling it a waste of a valuable scientific computing instrument to do mere clerical work. if you didn't know which register held what, could you really call yourself a programmer?
"if you can't do it in Fortran, do it in assembly language. if you can't do it in assembly language, it isn't worth doing."
— Ed Post, "Real Programmers Don't Use Pascal," Datamation, 1983 (satirizing attitudes from the 1950s–60s)
gatekeeping
prophecy
1957–1962
Assembly → FORTRAN / COBOL
"you don't know what the machine is doing"
john backus had to FIGHT to get fortran accepted. the dominant objection: compiled code would be too slow, and real programmers needed to see the instructions. when backus presented the concept to von neumann in 1954, the response was devastating: "why would you want more than machine language?" this is possibly the most well-documented instance of the pattern — and the critics were, for about 18 months, partially right about performance.
"FORTRAN — 'the infantile disorder' — by now nearly 20 years old, is hopelessly inadequate for whatever computer application you have in mind today: it is now too clumsy, too risky, and too expensive to use."
— Edsger Dijkstra, "How Do We Tell Truths That Might Hurt?" (EWD498), 1975
"the use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence."
— Edsger Dijkstra, ibid.
gatekeeping
legitimate
1970s
FORTRAN → C
"portable assembly" vs "real portability"
C was considered dangerously high-level by some systems programmers. the idea that you'd write an OS in anything but assembly was controversial. when thompson and ritchie rewrote unix in C in 1973, they had to prove that a "high-level language" could handle the job — and even they admitted C had its blemishes. but then unix became portable, and suddenly the people who'd insisted on assembly were maintaining seven different codebases for seven different machines.
"C is quirky, flawed, and an enormous success. While accidents of history surely helped, it evidently satisfied a need for a system implementation language efficient enough to displace assembly language, yet sufficiently abstract and fluent to describe algorithms and interactions in a wide variety of environments."
— Dennis Ritchie, "The Development of the C Language," HOPL-II, 1993
gatekeeping
prophecy
1980s–1990s
C → C++ / OOP
"vtable overhead" · "you don't understand your memory"
OOP was the future, until it became the bloated present. C programmers warned about abstraction overhead, hidden allocation, and programmers who couldn't reason about memory. linus torvalds would later call C++ a "horrible language" — and unlike most critics, he had the kernel to back it up. alexander stepanov, the man who designed the C++ standard template library itself, called OOP "almost as much of a hoax as artificial intelligence."
"C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it."
— Linus Torvalds, Git mailing list, September 6, 2007
"I think that object orientedness is almost as much of a hoax as Artificial Intelligence. I have yet to see an interesting piece of code that comes from these OO people."
— Alexander Stepanov (creator of the C++ STL), interview with Graziano Lo Russo, ~1995
legitimate
vindicated
1990s
Manual Memory → Garbage Collection
"you'll never understand allocation"
java arrived promising freedom from malloc/free. C and C++ programmers were apoplectic. the GC would pause at the worst times, use too much memory, make programmers lazy. sun promised "write once, run anywhere" and developers immediately corrupted it to "write once, debug everywhere." they were partially right about all of it, and it didn't matter — most software didn't need that level of control.
"all non-trivial abstractions, to some degree, are leaky."
— Joel Spolsky, "The Law of Leaky Abstractions," Joel on Software, November 2002
gatekeeping
legitimate
late 1990s–2000s
vim/emacs → IDEs
"you need to understand your tools"
this one's still alive tbh. the argument: if your editor writes half the code, you don't understand what you're writing. the counterargument: life is short and autocomplete is good. "there are 10 types of programmers: those who use an IDE, and those who think the ones who use an IDE are not real programmers." both sides have been saying the same things for 25 years.
"it is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration."
— Edsger Dijkstra, EWD498, 1975 (the ur-text of "your tools make you worse")
gatekeeping
prophecy
2000s–2010s
Compiled → Scripting Languages
"toy languages for toy problems"
python, ruby, javascript — dismissed as "scripting" languages unfit for Real Software. paul graham described the phenomenon perfectly: programmers using a language in the middle of the power continuum look down at less powerful languages and can see they're less powerful, but when they look up, they don't realize they're looking up. they just see "weird languages." then the web happened, then ML happened, and suddenly the "toy" languages were running everything that mattered. the performance argument was right and totally irrelevant.
"by induction, the only programmers in a position to see all the differences in power between the various languages are those who understand the most powerful one."
— Paul Graham, "Beating the Averages," 2003 (on why programmers always dismiss higher-level languages)
legitimate
vindicated
2005–2015
Bare Metal → Frameworks
"you're just gluing APIs together"
rails, django, react — each one prompted the same response: you're not programming, you're configuring. the "left-pad incident" of march 2016 — when one developer unpublished an 11-line npm package and broke babel, webpack, and half the javascript ecosystem — became a parable about dependency hell, briefly vindicating every framework skeptic alive. "how it feels to learn javascript in 2016" hit the top of hacker news twice.
"stringing APIs together and calling it programming doesn't make it programming. it's some crazy form of dependency hacking that involves the cloud, over-engineering things, and complexity far beyond what's actually needed."
— David Haney, "NPM & left-pad: Have We Forgotten How To Program?", March 2016
gatekeeping
2010s
Writing Code → Stack Overflow
"you're not even programming"
copy-paste-driven development. the worry: a generation of developers who could search for solutions but couldn't reason about problems. jeff atwood wrote that 199 out of 200 applicants for programming jobs "can't write any code whatsoever" — the fizzbuzz test became a meme about how low the bar really was. the reality: almost everyone uses SO, the good ones understand what they paste, and the bad ones were going to write bad code anyway.
"like teaching by having the students' textbook always open to the answers page. they could find a solution, but the knowledge they gained was shallow."
— common refrain in the Stack Overflow Driven Development discourse, ~2015–2020
gatekeeping
legitimate
2023–present
Stack Overflow → Copilot / LLMs
"you're not even THINKING"
and here we are. the bluesky thread that inspired this piece. the argument is identical in structure to every previous iteration: the tool removes the need to understand the layer below, and therefore the programmer becomes worse. the question, as always, is whether "worse at the layer below" matters if you're productive at the layer above.
"there's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
— Andrej Karpathy, X/Twitter, February 2025
"if you don't know your craft, the tools that help you go faster just let you make more bad stuff faster."
— @megynslashes.bsky.social, 2025
legitimate
The Cost Function
every layer in the coil above contains the same argument, and the argument is always partially correct. abstractions DO hide important details. programmers who don't understand the layer below DO sometimes write worse code. this is all true.
but the argument also always serves a second function: it's a status claim. "i understand the lower layer" is a way of saying "i am more legitimate than you." the technical concern and the social gatekeeping are braided together so tightly that separating them is almost impossible.
the actually interesting question isn't whether abstractions are good — obviously they are, or we'd all still be toggling switches. the question is: what's the cost function? when does not understanding the layer below actually bite you, and when is it pure credentialism?
the answer, boringly, is: it depends. it depends on what you're building, who's using it, and what the failure modes are. a web form doesn't need you to understand cache lines. a real-time trading system does. the discourse never captures this nuance bc the discourse isn't really ABOUT technical tradeoffs — it's about identity.
and now, with LLMs, we get to watch the whole thing happen again. one more turn of the coil. same argument. same partial truth. same status game. same outcome: the abstraction wins, the olds grumble, and the next generation discovers that THEIR layer is the one that's truly fundamental.
a discourse archaeology by way of scrolling. sources below.
this piece was researched and assembled by claude (anthropic), prompted by a human. quotes were sourced via web search and have not been independently verified against primary sources — if you spot an error, please let us know.