i’m a huge fanboy of much of [paul graham](http://paulgraham.com/)’s writing. i haven’t tried out [arc](http://paulgraham.com/arc.html), his pet programming language, but i love [this bit of philosophy behind it](http://paulgraham.com/power.html) (and [these concrete results](http://paulgraham.com/arcchallenge.html)).
programming-in-the-large consists of pouring a ton of stuff into your working memory and kneading it all around together, sometimes gently, sometimes forcibly. we use screens to physically edit code, of course, but i mostly see my screen as a kind of backing store where i can swap chunks of code in and out of my head. when code is concise, dense, and high level, i can fit more of it in both my working memory and on screen, which lets me work effectively across more of a codebase at a time.
working memory isn’t always the bottleneck, of course. lots of tasks are small, or block on communication instead, or all sorts of other things. when the rubber hits the road, though, the working memory boost you get from succinct code can be really powerful.
(it’s not just for coding, either. it works with system design and debugging in particular too.)
Cool, I had not read those before (I’m a little embarrassed to admit). It definitely fits your style and what I’ve picked up from you — inlining temporary variables and functions that are only called once means fewer AST nodes! The usefulness is especially apparent when I’m trying to pick a variable name for a particularly hairy concept, eventSectionSetList or something, and realize the concept is better expressed as code (duh).
Also “[2] I did once try representing the integer n as a list of length n, with horrifying results.” Hehe, I’m pretty sure that is from The Little Schemer! Computer goes a little crazy when addition is O(n+m)