Atlas · Details
Allocation Styles
Author’s note
This is a gargantuan post, but I enjoyed re-reading it in 2026. It views programmers and programming languages through the lens of how they think about allocating memory as they work. It turns out to be astoundingly nuanced, and sits at the center of language design, programming styles, and expressiveness/resilience tradeoffs.
The post is not for the faint of heart. You probably have to be a hardcore programming languages nerd in order to make it to the end.
AI Notes
Written April 2005 from inside Amazon's C++ codebase. Programmers, Steve
notices, talk about languages in terms of paradigm — imperative,
functional, declarative — but the more predictive axis, the one nobody
has named, is how the programmer thinks about memory. He names it
allocation style, and counts six of them: allocation-free,
buffer-oriented, collection-oriented, list-oriented, query-oriented,
pattern-match. Each gets a tour — the languages it feels native in, the
tell-tale signs in code review (double-pointers, explicit length params,
heavy memcpy), the trade-off between expressiveness and
control. The bit everyone remembers is the Ruby/Java string-reflection
example: one Ruby line ("".methods.sort.grep(/!/)) versus
ten lines of Java grind — a point about the
ceiling each language puts on the styles you can naturally reach, not its syntax.
The closing turn is the line that aged: use the most expressive style you can get away with; let the profiler tell you when to step down. Twenty years later the six categories still describe production code accurately — only the ratios have moved — and the advice is still one most programmers haven't taken, because most inherit the style their first language taught them, mistake it for good engineering, and spend years cutting against the grain of whatever they are paid to write.
Related listings
-
2005
Is Weak Typing Strong Enough?
Same drunken-rant move applied to a different axis. Weak Typing is about the type system you inherit from your first language; Allocation Styles is about the memory model. Both end with the same advice: stop confusing your first idiom for the right one.
-
2006
Math For Programmers
A year later on the Blogspot side, Steve makes the parallel argument for math literacy — climb as high as you can and step back down only when you must. Same shape of argument, different dimension.
-
2005
Lisp Wins (I Think)
The Lisp piece is the practical sequel — once you accept that you should program as high as the problem allows, Lisp is the rung that keeps refusing to be displaced.
From the peanut gallery
Read the rest of the thread · 4 more
-
"Hardware is expensive, people are cheap."
The modern thought in most companies is the opposite. It appears that you are speaking tongue-in-cheek, so my comment is probably redundant.
In the end thanks to Taiwan and other countries, hardware is often the cheapest part of any business.
-
Yes, it was tongue-in-cheek. Although I was speaking on behalf of all the people at Amazon using C++, because obviously they feel that hardware is indeed the gating resource. That, or they don't realize how much trouble they're giving themselves for no good reason.
-
Clearly you and me talk to different people. Most definitely everyone near me considers that people and our ability to actually get things _done_ with those people (think 6 hours builds) is the gating "resource" here. Hardware is cheap, plentiful and while not an excuse for bad code, we have gotten more in trouble for not delivering, or delivering buggy code, than delivering slow code.
-
Well... my feeling is that Java is the best solution out there today. Our support for it at Amazon isn't ideal yet, but the gains you get by switching to Java far outweigh any Amazon-specific build or deployment difficulties you'll encounter.
I also like Ruby a lot, and it wouldn't surprise me in the least to see Ruby become a viable language for a great many production tasks.
Personally, I think C++ doesn't really have a place in server-side software development today. I'd use C (or D) for anything truly and demonstrably performance-critical *and* for which you could make some financial case that Java isn't capable of performing well enough. And I'd use Java or higher-level languages for everything else. But that's just my opinion, and this is just a blog...
"But that's just my opinion, and this is just a blog..."
Don't let me get you down. :)
Actually I agree with you here. I like C++ a lot, for the problem areas where it's suited. But I actually turned to an office-mate the other day and said "why do we use C++ for our services, anyway?"
When I first got here, 8 months ago, I assumed that services were written in C++ because the service layer was a bottleneck in the critical path. But when I think about the services that our team owns, they're all database-bound. All C++ has going for it in this space is inertia.
— Josh H · April 22, 2005 09:06 PM