RSS Feeds

The other day, I saw a viral tweet saying that people talking about how LLMs are causing slow, bloated, code are going to eat crow once they re-write everything in super-optimized assembly. We're not quite at the point where we want to write everything in assembly, but some variant of what Nolan Lawson said about testing, you can choose how many bugs you want now, which I less eloquently noted here, is becoming more true for performance.

In response to a comment in my last post that the cost of formerly specialized performance work has dropped by many orders of magnitude and performance work that used to require a person or team that had a rare set of skills can be done by anyone who can type a few sentences¹, which means that you can do all sorts of optimizations that used to be too expensive to be worthwhile for all but the largest scale or most lucrative projects, Marc Brooker responded with

Completely agree with your closing point. Dynamic custom software, fitted to a particular workload rather than a class of workloads, seems like a very likely outcome. (Which comes with all kinds of fun risks and opportunities of its own). Kind of reminds me of FFTW. And a ton of weird old demoscene techniques which were all about being super fast and small on a very particular problem (and often very particular hardware). For example, I remember a demo that re-used its code as textures to get great cache locality.

And Michael Malis has noted

There’s been a meme circulating about how AI doesn’t help because “code was never the hard part.” I think that’s true in some domains, but in others, writing the code absolutely was the hard part. JIT compilers are a great example of that. For many pieces of software, a JIT compiler would help a lot with speeding up the code. The rarity of JIT compilers makes me believe that implementing a JIT compiler historically was too difficult for it to be worthwhile. LLMs have lowered the barrier to entry and made it much easier to write a JIT compiler. This is the thesis behind pgrust. Databases historically were the hardest piece of software to build and were limited because of that. Now, with AI, we can be more ambitious about the type of software we build.

Optimizing for a class of workload

Let's try this out with FRE, the regex engine we built in the last post. Recall that it was created by having an agent loop for a month on improving regex engine performance with access to the rebar regex benchmark suite. This resulted in FRE being heavily overfit to rebar until we warned our agent that we had a holdout benchmark, which caused the agent to generalize the optimizations enough that performance was ok-ish on our holdout. There's no particular reason to use a "software factory" regex engine that doesn't beat a well-tested regex engine on holdout benchmarks, but one notable thing about FRE was that the native AOT compiled version did quite well at longer searches. We noted that, it stands to reason that one could run the native code compiler in another thread while ripgrep was running its normal matcher and then cut over to the native code when it finished compiling and generally get better performance. Of course this will generally result in worse performance for short queries as we lose a thread to compilation, but I care a lot more about how long ripgrep takes when it runs for many seconds or minutes than when it runs for a few seconds, so I'm ok with that tradeoff.

In the same way we could build a regex engine in a few minutes of human time, we can also just try this experiment in a few minutes of human time. I typed a few sentences and an agent went and did the work to allow this to happen (which would be a decent chunk of code surgery for a human) and it ran the benchmark on actual ripgrep queries that come from my codex history. For longer queries, we see a 2x-4x performance improvement here for a few very simple queries. But most queries are more complex, and when we run on representative holdout queries, for queries where AOT should be enabled², we get about a 7% speedup. Not an earth shattering result, but also not a bad outcome for spending a few minutes typing to codex (and it's still doing more optimization and will presumably speed things up further).

Build an index?

This is arguably a silly thing to do, since if we're repeatedly searching for text on a computer, the obvious thing to do to speed that up isn't to write a native code compiler for regex matching, it's to create an index. But the point here is just that this kind of technical work, which used to take a fair amount of time and expertise, can just be done trivially now. And if we wanted to build a text index, it just so happens that I worked on BitFunnel, the Bing search index that was specialized for constant/fast text ingestion that won Best Paper Award at SIGIR, so I can think of a few experiments to try if we're going to build a fast local index of our entire machine (the projects I've seen seem to be intended to index your code directories, but what really kills my machine performance is when codex decides to run ripgrep against huge temporary directories with a ton of generated files and then expands to looking at my whole machine when it misses, so I'd want an index of my entire disk and not just of the code for some projects).

If I were working at an AI lab and had access to things like SOTA models running on Cerebras chips or other accelerators that greatly increase tok/s and therefore load/demand for search, I might actually survey the existing indexers to see if they're fast enough or if I'd want to build something custom myself. While the open source version of BitFunnel "only" contains a bytecode interpreter and one JIT, the Bing version contains multiple JIT compilers. A project that did that level of optimization used to be a major undertaking, but "I could do that in a weekend" is now actually true for some of these kinds of projects. With my lowly $200/mo account, I think a somewhat faster ripgrep plus any off-the-shelf index is fine, so maybe this fast-ingesting whole-machine index project can be left as an "exercise for the reader (who works at an AI lab)".

Optimizations are cheap

The drastic reduction in the cost of optimizations has been true going back to November 2025 and maybe even somewhat before then with public models (and I'm sure before that still with what folks at AI labs had access to). For an example from the GPT-5.1 or 5.2 days, with no knowledge of game AIs, I tried building an Azul AI. This ended up being the strongest AI in the world for the game by a pretty large margin. From reading the thesis that describes the 2nd strongest AI, I think my AI is probably a bit better on the "AI" side of things, but the main place it wins is on optimization despite spending what looks like maybe two orders of magnitude less time (estimated by reading the thesis and seeing the process and comparison to my process) and also mostly working on my laptop vs. having a cluster of machines to use (which means much less bandwidth to run experiments with, do parameter tuning, etc.). For example, that other AI is single-threaded and my AI is multi-threaded. Since I have a native code version as well as a heinous shared wasm memory + javascript version, and two different search architectures for two different versions, which "require" completely different multi-threading algorithms (minimax for a very small and fast net and MCTS for a larger net), this would've been a fairly large undertaking if done by hand. And, because I let an LLM pick the multi-threading algorithm based on its own (incorrect) reasoning a couple times before spending 30 minutes reading about multi-threading algorithms for game AIs myself, I ended up re-writing (having codex re-write) the multi-threading algorithm multiple times.

There's a bunch of standard stuff it makes sense to do to debug and verify a multithreading algorithm for something like this, like implementing replay from debug logs that can reproduce bugs despite the algorithm being nondetermistic. Doing that alone would've probably been days to a week of work had I done it by hand, but it's exactly the kind of thing an agent can trivially do in a loop (just have it try to replay logs and insert logging for non-determinism every time you don't get a perfect replay). A lot of the tedium it used to take to get a tricky optimization like this working is gone.

This also applies to a lot of other tricky optimizations. From having written CPU microcode, done CPU verification, worked on optimizing a search engine index, etc., I have a lot of experience looking at optimizations and thinking "hmm, this would increase performance by 2%, but it's going to take N person-days to verify that this tricky optimization works" and making a call to go ahead or not based on whether or not it's worth the time to get the optimization working. Now that this N has dropped by a tremendous factor (variable but, in terms of human time, frequently 1000x / 10000x / 1000000x, probably more like 1000x on dollar cost if you compare token costs at metered rates vs. the Bing engineer who wrote the compilers at JITs that the search index used), the number of these kinds of optimizations it makes sense to do goes way up. The same goes for optimizations that you aren't sure will work out. I used to sometimes look at an optimization that I wasn't sure would speed things up and think "this will take M hours to implement to the point where we have a good enough measurement to guess at the performance impact". Many more of those optimizations make sense to try out now.

Going back to the game AI case, at least for the AI I tried, it seems like you gain about 100 Elo for every doubling in speed (more than in chess, I suspect because draws are very rare). Just adding multithreading alone is enough to wipe the floor with an otherwise comparable AI on a large machine. If you stack in 10-20 more optimizations that seem too annoying for most people to do by hand, the difference in strength is tremendous and it's not really reasonable to try to keep up with a hand-written AI³.

The game AI case is a little more annoying than for most software because a lot of the optimizations you want to do actually change the result and there isn't a cheap, trivial, way to tell if the speed increase + the change in result gives a better or worse actual result in practice. And, as we noted before, current publicly available SOTA models are pretty bad at experimental design, so I had to set up the framework they used to determine if an optimization is good, but once that was in place, it's like any other optimization problem. I guess people working on LLM optimizations also have to deal with this class of problem but most optimization problems are a lot more straightforward.

To pick another example, as part of preparing for performance interviews, Jamie Brandon tried Anthropic's now public performance takehome. After trying it, he had Claude pick up where he left off and it got a much better result. When he looked at what Claude did that he didn't, he said a lot of the optimizations were things that occurred to him but he hadn't gotten to yet, and "[o]thers were just crazy shit that I would never try unless I was working on this for weeks"⁴. He's a reasonable performance engineer and he got an offer for the performance job he wanted, but on a well-defined optimization problem, he doesn't stand a chance against a decent model (I haven't tried the problem myself, but I suspect I also wouldn't stand a chance given remotely comparable time controls).

Workload-specific optimization

Coming back to this part of Marc Brooker's comment:

Dynamic custom software, fitted to a particular workload rather than a class of workloads, seems like a very likely outcome.

This seems pretty inevitable. In another response to my post, Michael Malis of pgrust said something similar:

[discussion of pgrust optimizations] ... I think it's easy enough to create these optimizations that we could look at a customers workload and add them as needed

Without having any kind of framework or setup, right before I started writing this post, I had an agent do workload-specific optimization for my ripgrep queries (not the native code compiler switch, just the optimizations to the general FRE engine based on a set of benchmarks), which took about 2 minutes for me to launch. The optimizations run on a set of queries, and then there's a later holdout set of queries to run against. That's still running, but the initial results seem promising. After one pass of optimization, the workload optimized version is 2% faster than standard ripgrep on the holdout and it's still getting faster. 2% isn't a big deal for my local ripgrep usage, but considering that this took minutes of time and the optimizations done here got started when I started typing this point and are still improving, I'd take a 2% win here (note that this isn't combined with the native code compiler, which would give a larger overall win if combined properly). And recall that this is leveraging the FRE regex engine⁵, which was substantially slower than the Rust regex engine on holdout benchmarks and was stuck with slow improvement on holdouts because with me knowing nothing about regex workloads and SOTA LLMs not being good enough at experimental design to do unguided open-ended self-improving loops, we didn't have a good way to improve performance on our holdouts. But if what I care about is performance on my own workloads, I have plenty of data and am generating more all the time. As Marc Brooker noted above, we do have to be careful about overfitting if there's a regime change that's not in the old data, etc., but we're still in a better situation than we were before.

In the more general case, if you're someone like Marc Brooker at Amazon or Michael Malis working on pgrust, it makes sense to not just do this as a one-off, but to work with customers to pilot a program that uses their data to optimize things for them and then figure out how to scale it out for customers in general. I'm not working at a company where that's the best use of my time⁶, but it's pretty wild that you can see that this is coming for larger companies with more scale, and given that it only takes minutes of my time to run these experiments for my personal workflows, it's pretty reasonable to mess with this kind of thing on personal projects.

Thanks to Jamie Brandon, Michael Malis, andrea (@s__video), Artyom Bologov, and Max Bittker for comments/corrections/discussion.

P.S. As I've noted in the last couple posts, with coding agents, the time it takes to run an experiment and see enough of a result to satisfy my curiosity has gone way down while the time it takes to make a result really rigorous hasn't changed or has gone up, so writing things up the way I used to would mean running very few experiments relative to the bandwidth I have for them. As a result, I've just been running these experiments and sharing the result with a couple of friends. As an experiment, I'm trying to write these up in a very quick and non-rigorous way instead of years of these experiments only being known to a few friends. Like the last post, I set a goal of writing this post and doing all the clean-up in half an hour and didn't time it but am pretty sure I missed that by a bit.

Even doing this, the time it takes to write these up is long enough that I'm falling behind on sharing recent results, but I'm not inclined to switch to LLM-written posts (yet?), and I don't think I can realistically get the time to clean up the data and write a post like this down enough to turn a post around in less than half an hour. Just on the length of this post, typing this up should be something like 20-30 minutes including time to pause and think about what I'm writing, and then when I look at the data sometimes something will look wrong enough that I need to look into it more closely to see if there's an issue that needs to be fixed (this happened multiple times here, and I would expect that, because I didn't spend much more time, there are other data issues that I don't know about).

Anyway, if you have opinions on these quick (and surely more wrong) writeup, let me know what you think (X Bsky Mastodon)!

Appendix: There's no reason for software to be slow anymore

I've been on the record for a long time as strongly disagreeing with the general sentiment that the developers of X are bad and should feel bad for writing slow code because there are a lot of different kinds of programming expertise and not only is it not the case that most programmers don't have performance expertise, it probably doesn't even make sense for them to develop (from the standpoint of what the business cares about, what the employment market looks like, etc.), so of course most projects will have very poor performance compared to what a performance expert can do. I can see why a performance expert would look at the growing gap between how fast a program can be and how fast programs actually are and think that it's ridiculous. I don't disagree that there's an absurdity to it, but if I think about the gap between how good a UI can be and how a good a UI I can make (by hand) is, I don't think that looks any less absurd, but I also don't think it really makes sense for me to spend time learning how to build a great UI, or even a decent UI, for the same reasons it doesn't make sesne for most people to spend time learning how to decent performance work.

For the example above, Jamie Brandon got an offer from Anthropic and you probably can't afford him unless you're OpenAI, but you can afford to use a coding agent that can beat him on a bounded optimization problem. The agent doesn't have the judgement he has and will do worse on an open-ended problem (recall that when we tried building an optimized regex engine and just told it to not overfit, it was more than an order of magnitude worse than the best regex engines on our holdout benchmarks, but also recall that after telling the agent there was a holdout it was doing poorly on, it sped up regex engine performance enough to generally match 2nd tier regex engines in terms of performance, which is still extremely good compared to the general level of performance optimization in most code today), but that's plenty good to achieve reasonable performance on all sorts of problems. This post has generally discussed backend performance issues, but agents don't seem worse at front-end performance if you want to drive down a set of metrics like LCP and CLS. In fact, after inserting the interactive plots I've been using recently into posts, I found that my client-side perf numbers got worse, so I had an LLM spent 1% of my weekly quota optimizing those and the numbers are once again back to being good. This is a very simple site, but people do these kinds of optimizations on fairly complex apps that ship to many millions of users and it also works there, although it does cost a few more tookens.

I still don't think someone is bad and should feel bad if their software has poor performance, but I do think that someone who doesn't know anything about performance and is a reasonable user of LLMs (just in general, not on performance problems in particular) should generally be able to create software that has decent performance. If you just tell an LLM to optimize, it will often do all sorts of incorrect things that are really bad that you have to catch, but that's generally true of using the LLM effectively in the first place, so getting decent performance is no longer a specialized skill.

Appendix: How is codex running ripgrep?

Here's some information about the distribution of riprep queries on my machine. I make no claims that this is at all representative of what's happening anywhere else. The pattern distribution of the length of the pattern that's searched has a lot more long patterns that I would've expected. The p50 is 55 unicode code points (I'll just call these characters for simplicity), which is already longer than things I grep for by hand, and the p90 is 119!

We can also look at the number of alternation arms in regexes, which are once again much more complex than what I do by hand.

Another view is to look at how these are correlated. Do we get more alternation arms in the regexes as the regexes get longer? Yes.

What are these really long regexes, anyway? If we look at them, most of the longest are long alternations over function or tests names, such as the following regex, which appears to be related to FRE development.

  fn (hot_byte_compiler_is_generic_only_and_anonymous_count_uses_auto_count|
  one_pattern_count_spans_uses_the_retained_complete_span_session|
  formal_compact_state_byte_visitors_coexist_with_native_count|
  fixed_boundary_record_visit_matches_line_relative_reference_and_is_atomic|
  unbounded_languages_refuse_finite_extraction_before_allocation|
  formal_single_raw_span_sweep_preflight|
  assert_exact_fixture_uses_formal_large_continuation_sweep|
  url_only_compile_identity_binds_language_and_owner_mode|
  url_only_compile_exact_limits_and_runtime_refusals_close|
  url_only_compile_post_plan_allocation_faults_close|
  url_only_owner_discriminator_is_stable_and_precharged|
  url_only_compile_owner_is_strategy_and_operation_scoped|
  formal_rebar_url_owner_is_compile_only_and_matches_oracle|
  formal_rebar_url_exact_fixture_uses_certified_execution|
  formal_fixed_schema_materialization_matches_both_record_oracles_and_controls|
  formal_single_count_selects_compact_state_byte_complete_bound_visitors|
  authenticated_bound_line_total_lf_free_domain_opportunity_exceeds_five_percent|
  prepared_absolute_onepass_fuses_slots_and_preserves_pre_source_fallback|
  authenticated_word_boundary_russian_compact_lowering_public_canary|
  ordered_nfa_x86_epsilon_edges_bypass_the_assertion_call|
  ordered_nfa_aarch64_epsilon_edges_bypass_the_assertion_call|
  ordered_edge_dispatch_v2_is_target_neutral_deterministic_and_relocation_free|
  ordered_edge_dispatch_v2_copies_canonical_tables_and_cap_falls_back_to_v1|
  ordered_nfa_v3_composes_terminal_range_and_dispatch_without_data_relocations|
  ordered_nfa_x86_terminal_range_emits_authenticated_reverse_scan|
  ordered_nfa_aarch64_terminal_range_emits_authenticated_reverse_scan|
  ordered_nfa_x86_boundary_assertion_cache_is_lazy_and_boundary_scoped|
  ordered_nfa_aarch64_caches_repeated_assertions_once_per_boundary|
  boundary_assertion_cache_requires_dense_exact_kind_reuse|
  boundary_assertion_cache_selection_is_compiler_only_and_deterministic)

But some are funny numerical constructions, such as

:(13[0-9]|14[0-9]|15[0-9]|16[0-9]|17[0-9]|18[0-9]|19[0-9]|20[0-9]|21[0-9]|22[0-9]|23[0-9]|24[0-9]|25[0-9]|26[0-9]|27[0-9]|28[0-9]|29[0-9]|30[0-9]|31[0-9]|32[0-9]|33[0-9]|34[0-9]|35[0-9]|36[0-9]|37[0-9]|38[0-9]|39[0-9]|40[0-9]|41[0-9]|42[0-9]|43[0-9]|44[0-9]|45[0-9]|46[0-9]|47[0-9]|48[0-9]|49[0-9]|50[0-9]|51[0-9]|52[0-9]|53[0-9]|54[0-9]|55[0-9]|56[0-9]|57[0-9]|58[0-9]|59[0-9]|60[0-9]|61[0-9]|62[0-9]|63[0-9]|64[0-9]|65[0-9]|66[0-9]|67[0-9]|68[0-9]|69[0-9]|70[0-9]|71[0-9]|72[0-9]|73[0-9]|74[0-9]|75[0-9]|76[0-9]|77[0-9]|78[0-9]|79[0-9]|80[0-9]|81[0-9]|82[0-9]|83[0-9]|84[0-9]|85[0-9]|86[0-9]|87[0-9]|88[0-9]|89[0-9]|90[0-9]|91[0-9]|92[0-9]|93[0-9]|94[0-9]|95[0-9]|96[0-9]|97[0-9]|98[0-9]|99[0-9])[0-9]:

This is equivalent to :(?:1[3-9]|[2-9][0-9])[0-9]{2}: (which, if run through ripgrep on the original input, has approximately the same performance; the shorter regex is technically a bit faster on the real query data, but only by a very small amount). The entire pipeline for that was

cargo clippy … | rg 'crates/fre-aot-regex/src/module.rs:' | rg NUMBER_REGEX | head -250

which might be an odd thing for a human to do, but agents seem to do this kind of thing all the time.

On another topic, if we look at how long ripgrep queries took, there are quite a few slow queries, e.g., p99 is almost 1 minute! And p999 is almost 10 minutes! And the maximum query over this time period (around a month on one laptop; queries and distributions seem likely to be different on the AWS hosts I run agents on, etc., but I haven't checked) is approaching 2 hours!

In terms of command line options, we see the following. Perhaps unsurprisingly, codex often wants line numbers and, for whatever reason, it very occasionally uses PCRE2 regexes.

I won't add plots or tables for these, but another thing to note is that there's fairly low locality for what patterns are searched for (about 94% of patterns only occurred once), which makes some sense given how long a lot of the queries were. However, there's fairly high locality in what files get searched and a file that got searched is relatively likely to get searched again soon, indicating that (for small enough files), they're likely to be searched in memory.

Also, 99% of queries were regex queries (1% were non-regex string searches) and 99.9% of search queries were ASCII only, but in terms of files searched, approximately 45% were ASCII only and 55% contained Unicode, a higher percentage than I would've guessed for Unicode.

On a draft of the last post, Peter Geoghegan noted

It's also possible for a regex implementation to be faster by supporting fewer features. Some implementations don't support back references, etc.

which is also true here. The workload-specific optimizations done here were fairly superficial because I just gave codex some short instructions and let it do whatever it wanted (which is, in general, not the most effective use of codex), but with a more detailed plan, more focused optimizations supporting the common use cases for my queries could be expected to yield larger gains.

There's been a lot of talk about the vulnpocalypse, to which I don't have much to add because I'm not a security person, but I haven't seen much discussion on the closely related (and to be fair, less serious, issue), the benchmarkpocalypse.

While it's become easier than ever to make serious performance gains, it's also become easier than ever to reward hack a benchmark and make fake performance gains. The former is probably happening quietly across many different companies, but the latter is something I see at least once a week nowadays. Someone will claim they optimized X and got some huge performance improvement over existing software, but, when you look at it, what they did was make some optimization that improves benchmark performance without actually improving real-world performance. This is often some kind of "we rewrote X in Rust"¹ project or a new startup that's looking to either fundraise or sell something, but it happens on other kinds of projects as well.

Of course, people have always trumpeted unrepresentative microbenchmarks to show that their pet project is great. It's always been easy to fake up an unrepresentative microbenchmark and that's never going to change. What's changed is that it used to take a lot of work to game a large benchmark suite, but an LLM and loop can just do it. There are quite a few famous examples of gaming large benchmark suites from back when this was hard. For example, way back when people cared about SPECint / SPECfp as proxies for workstation performance, CPU vendors would try to find compiler "optimizations" that would speed up the calculation in the benchmark, such as Sun finding a way to improve 179.art by 12x in SPECfp2000. Skilled engineers spent a lot of time trying to find benchmark hacks like that. LLMs not only make this trivial, they do it by default, making formerly trustworthy benchmarks meaningless unless you audit the result or trust someone who did.

Rather than point to someone's bad claim, I'll point to FRE, this regex engine I had an agent build, which I could claim is the world's fastest regex engine because it beats the Rust regex crate at the fairly comprehensive rebar regex benchmark suite. But this was created by putting an agent in a loop for a month with instructions to not overfit to the benchmark but no real supervision. For the most part, getting an LLM to give you a good benchmark score is fairly easy, and this case was no different; it took a couple weeks to roughly match Rust regex crate performance and then another couple weeks to get to 1.4x faster² on rebar. But agents are wont to reward hack and overfit unless you put serious guardrails in place to avoid that, which I didn't do in this case as an experiment.

To check for overfitting, I somewhat arbitrarily³ used the ripgrep benchmark corpus as a holdout benchmark it was 10x slower on cases where the benchmark didn't take forever due to an algorithmic blow-up, and there were cases where it took so long that it wasn't reasonable to even wait for the benchmark to complete. So much for being 40% faster!

Andrew Gallant (aka BurntSushi)'s rebar benchmark suite is fairly comprehensive as benchmaark suites go, but even with a fairly comprehensive benchmark suite, agents have no problem getting a high score while overfitting in a way that doesn't necessarily give good general performance.

The next step was using a trick we talked about before of not just telling the LLM not to cheat, but that there's a holdout benchmark set that it's judged against. After that, the LLM moderately generalized performance to the point where it's about 2.4x slower overall on the holdout. That sounds pretty good considering that we're comparing it to the fastest general purpose regex engine in existence. But, recall that these benchmarks were made by a coding agent. On looking at what the benchmarks measure, some of them really don't make sense to include, at least at equal weight. If we only look at the benchmarks that seem like they matter, FRE is 4x slower on the holdout⁰, which is a lot better than before applying the good ole' "tell 'em you have a holdout trick", but still pretty far from being 40% faster.

There are a few things I thought were interesting about this:

1. It's trivial to "win" a non-trivial benchmark in a meaningless way even when you instruct agents to not reward hack or overfit to win the benchmark
2. Once again, telling the LLM there's a holdout set worked better than just telling the LLM to do generalized work or not overfit or cheat
3. Although the overall performance of FRE isn't that good, it is actually performs better for some use cases; in general, the cost of writing specialized code that used to require people serious engineering experience for some specific use case has gone way down

On (1), no wonder I'm seeing so many bogus claims. In the past, to build something like FRE that fakes performance well enough to be able to bogusly claim a 40% speedup, you would need a fair amount of expertise. At a minimum, you'd need to have a pretty good understanding of string matching algorithms, regex engines, as well as decent general code optimization and SIMD optimization skills. FRE also has a mode where it compiles the regex to machine code, so you'd also need some compiler expertise. Now you can get that kind of benchmark cheating (whether or not you want the cheating) with a few minutes of typing.

On (2), I'm curious if this generalizes but haven't tried enough examples to be able to tell.

On (3), there's no reason to use a vibe coded regex library that was almost no human effort that's slower than a robust, existing, well-tested, library, so I find the FRE artifact uninteresting. The thing I find interesting here is how much LLMs can substitute for what used to be rare, specialized, and expensive, knowledge.

In the past, even if you had the knowledge, you probably wouldn't write a custom regex engine that's optimized for your particular workload. There are some large-scale use cases where people would do that level of customization, e.g., when I worked on the Bing index, the code contained multiple different compilers because someone who worked on it wanted to eke out maximal performance; since you care about both compile time and compiled performance in a search engine and the trade-offs are different in different places, you get better performance by writing a custom compiler for each place where a normal project might just use an interpreter or directly walk some data structure with "normal code". The person who wrote those compilers, working on regex-like code might also write multiple custom regex engines, but very few people have both the expertise and the inclination to do that, let alone the freedom to spend that kind of time on such specialized code for work. If you price out that Bing engineer (then a Partner-level engineer, promoted to Distinguished Engineer for their work on the search index) compared to the price of running an LLM in a loop, the cost of writing this kind of specialized code has gone down by many orders of magnitude.

People who still think AI is fake will probably read the first part of the post and think "of course, AI produces fake things, so it produced a fake regex engine". But if we look at the results, being a bit worse than half the speed of the world's fastest regex engine on a holdout while being genuinely faster on many real workloads (most of the overfitting isn't that it special cased a particular benchmark pattern, but that it has some kind of optimization for things of same rough shapes and not of other rough shapes) it's pretty far from a fake regex engine. And, in fact, there's a native code compiled mode that actually beats the Rust regex crate on the holdout if you ignore compile time and are running repeated searches or a very long search (which is a reasonable thing to do for many actual use cases). If my goal with FRE was to produce a fast regex engine instead of producing whatever regex engine one can produce in a few minutes of human time, I suspect it would be fairly competitive on a broad range of holdout benchmarks (with some gaps that would only be found when people tried it on a diverse set of production workloads), and, even this quick and dirty version is very good at some real workloads.

So, even though the overall FRE regex engine has worse performance than the Rust regex crate, the gains you can get for specializing to your workload or use case mean that, in some cases, it could be reasonable to insert your own specialized regex engine somewhere, and the same goes for various other kinds of low-level software. You don't have to be an AI maximalist to think that it's plausible that, within some number of years, we could see this kind of thing happening for larger things, like databases.

Thanks to Yossi Kreinin, Jamie Brandon, Peter Geoghegan, Luke Burton, John Spurling, Dennis Snell, and Max Bittker for comments/corrections/discussion.

Of course, a caveat here is that all of the numbers have a higher risk of being wrong than usual. I looked at one benchmark for maybe a minute or two and found an issue, then I looked at another benchmark for a minute and found another issue. Both of those are fixed, but this implies there are other issues I haven't taken the time to chase down. But, with respect to bad benchmark numbers, that's highly realistic! Almost any time I look into benchmark numbers, such as here, or here, the numbers are wrong. Another aspect of the benchmarkpocalypse is that, at least for now, LLMs are good at doing bad benchmarking, so even if you have something that's a real performance improvement, you generally can't tell from some LLM-generated benchmark setup unless a significant amount of care has been taken to make sure that the benchmark setup is reasonable.

Appendix: more FRE benchmark details

One thing I found after I wrote the above but before publishing the post, was that the LLM's claim that FRE is 40% faster than the Rust regex crate on rebar was also wrong. Or, if not wrong, at least misleading. It wasn't actually running benchmarks in the same way rebar benchmarks were run. I checked this after spending a minute checking benchmark results found two issues. It turns out that, despite instructions to run rebar benchmarks as they're run in https://github.com/BurntSushi/rebar, the LLM changed the interface to allow FRE to make some optimizations that improve performance. After fixing that, instead of FRE being 1.4x faster than Rust on rebar, it was 1.5x slower (and "only" twice as fast as re2), so the original result was doubly fake. Not only was FRE highly overfit to the rebar benchmarks, it the results also involved cheating.

But on the bright side, this means the difference in performance between FRE on rebar (1.5x slower than Rust) and on the holdout benchmarks (2.4x slower) isn't as big as it looked before, so the "tell the LLM you have a holdout" trick worked even better than it seemed to before.

After that, I let an LLM hill climb for a few hours and it claimed that FRE was 1.28x faster, which sounds like a great improvement for only a few hours of LLM time, but then I decided to spend another minute looking for cheating and found multiple issues, including one case where a search for the count of matches of (?s)^(.*)$ returned the count without even looking at the haystack (data). Another case of cheating was doing a multi-line grep where the benchmark is supposed to be done line-by-line. Finding these isn't surprising because this is the kind of thing that happens when you leave an agent in a loop for a month without defining strict guardrails. Whether this makes my point here stronger or undermines it isn't clear, but after fixing another set of these issues, FRE was back to being 1.4x slower. After leaving an agent to run overnight, FRE was allegedly back to being 1.5x faster.

Since my original goal here was to see what happens when you run a current (public) SOTA agent in a loop (GPT-5.6 Sol) without much supervision on a non-trivial code optimization problem without any real supervision, rather than spend more time fixing things up to make the benchmarks fairer, I'll just stop here and put a few plots of the results.

Overall, we can see that against Rust and RE2, FRE tends to outperform on the rebar benchmarks (and as noted above, much of this is due to overfitting), but not across the board (the graphs below don't necessarily match the numbers mentioned in the post because an agent is constantly making changes, so any snapshot is a point-in-time estimate that becomes obsolete immediately):

If you're curious about performance on specific benchmarks or specific classes of rebar benchmarks, we have the following table (ratios above one mean FRE is faster; below mean FRE is slower):

There's also an AOT compiler mode that takes a long time to compile a regex to native code before running it. There isn't AOT support for everything, but here are the results from the cases where it's supported. As we can see, the AOT compiler is very slow (it loses very badly in the compilation time benchmarks) and, despite spending quite a bit of time compiling, results are often slower than with the standard FRE regex engine (though it's also faster in many cases).

And then there are the holdout benchmarks. As noted above, for the non-AOT FRE code, performance on the holdout isn't as good as on rebar. And as also noted above, considering that this is for a workload like ripgrep, the "hot search" set of benchmarks is probably more important than the others, so the FRE result is worse than the overall score would make it look.

One thing to note here is that, for the holdout benchmark cases where we don't include compile time as part of the benchmark and we repeatedly run searches, AOT FRE outperforms on the benchmark. For a lot of use cases, you don't want a regex that takes multiple seconds to compile, but there are plenty of cases where this is fine, e.g., for something like ripgrep or Silver Searcher, it could start running with a regex that can start matching right away and then compile in another thread and cut over to the faster matcher when it's done compiling. Given how much of my CPU is spent on long ripgrep searches, it seems like a strategy like that could improve performance for work I personally do. Before LLMs, it probably wouldn't have made sense to spend the effort to write an optimizing regex compiler, but this is now do-able with a few tokens.

Another thing to note here is that this comparison is arguably unfair because this was run on an ARM Graviton machine with SVE/SVE2 and FRE has SVE/SVE2 optimizations. Pre-LLM, it might not have been worth it to have regexes optimized for every combination of SIMD instructions out there, but with LLMs, it's fairly easy to generate ok-ish SIMD optimizations. I know human experts who find that they can generally outperform LLMs here, e.g., Jay Stelly said that the last time he tried getting an LLM to produce SIMD code, it took 20-some iterations to get the code as good as he wanted. But, on the flip side, LLMs have the capability to try more optimizations than a human could possibly try in any given amount of time, so they can still perform pretty well overall even if any specific optimization isn't as good as a human expert would produce.

There's also the problem discussed in this post of overfitting. Depending on the context, that problem is somewhere from very easy to solve to a bit difficult to solve. I deliberately didn't try very hard to solve the problem here to see what would happen, but I did manage to solve the problem without an outsized amount of effort when working on this Azul AI (just for example), but a lot of these big benchmark claims come when people spend little to no effort trying to avoid overfitting, or even negative effort. In the pre-LLM era, people would often pick highly unrepresentative microbenchmarks to show off how great their pet project is which, at least at a non-conscious level, involves negative effort to avoid overfitting to a benchmark. Due to how humans are, I don't think people are going to stop making misleading claims and it's become easier than ever to make misleading claims, so of course we see more of them.

Note that while this post has discussed non-AI software, everything said here goes double for AI software. For example, I've seen lots of people drop comments saying that Kimi K3 is Fable (5) level. But every single person I know who's used it has found it to be substantially worse than GPT-5.6 Sol and Fable. I'm not saying it's not an impressive engineering achievement, but the performance on a wide variety of real-world tasks isn't up to the level it is in benchmarks. This even applies to various eval-y problems, such as when a friend tried different coding agents on the ICFP 2026 contest problems. It also applies to security issues, which are something that I have no doubt AI labs are putting into their evals, e.g., a colleague of mine tried using Kimi K3 to scan for vulns in our software and found that it found approximately a quarter of the vulns GPT-5.6 Sol found, found no vulns that GPT-5.6 Sol didn't find, and didn't have any advantages in any dimension other than on cost. The people I know who are using cheaper models to find real security issues are using other models, such as GLM-5.2, which perform worse on benchmarks but better in practice.

Back on the topic of FRE, one more note is that the holdout benchmark is an arbitrary subset of the ripgrep benchmark setup that was chosen by an agent for unknown reasons. I asked an agent to pull the entire benchmark suite, but that didn't finish in time for this post, so I don't know what the result will be once it's done.

This somewhat widely cited post (I keep seeing it cited, anyway) suggests that dynamic languages and/or languages that represent things more concisely are more token efficient. It seems to be cited enough that LLM search results agree. For example, when I searched for "dynamic vs static language token cost" (no quotes), Google's AI summary opened with

Dynamically typed languages generally have a lower LLM token cost than traditional statically typed languages because omitting explicit type declarations makes the code more compact.

Google's AI cited the same post, which suggests that some concise dynamic languages have maybe 1/2 to 1/3 the token cost of static languages like Rust, Go, C++, etc. The author says

There was a very meaningful gap of 2.6x between C (the least token efficient language I compared) and Clojure (the most efficient).

And then they later tried J, saying

It dominates at just 70 tokens average, nearly half of Clojure (109 tokens). Array languages can be extremely token-efficient when they avoid exotic symbol sets. If token efficiency turns out to be a key driver, this is perhaps a very interesting way for languages to evolve.

The other dynamic vs. static language token comparison I've found floating around is this one, which supports the same conclusion. If you want to treat this as part 8 of this series of exercises on benchmarking, evals, and experimental design, you can click through to the links and think about eval issues before reading further.

Without running our own eval, one problem the first experiment has is that the problems are trivial, which we can see from quote above; a problem that can be solved in 70 tokens in J and 109 in Clojure isn't much of a problem at all (the author used Rosetta Code). As we saw when we looked at other evals of caveman mode vs. our own evals, you can get very different results from trivial problems where most of the work is in printing out an answer vs. slightly less trivial problems that actually require some amount of "real work"; the big gains claimed by caveman mode and shown in replications go away when you start looking at problems that take more than just a few tokens. In general, performance on trivial tasks doesn't generalize.

The issues in the second link are a little more subtle, so we'll defer most of them to an appendix, but they include issues like one of the tests executing the wrong path (which doesn't exist), causing a test to fail. One of the later agents then symlinks the non-existent path to its own executable, which works for that case, but also causes every later test to run that one agent's executable instead of the correct executable. The author tries to draw conclusions about what it means that Rust had some failures, but all it means is that scoring for Rust ran before the Go agent symlinked all scoring on that broken test to the Go executable.

Instead of relying on these evals, we can try running some of our own evals. As we can see from these evals as well as the evals discussed in our last exercises on evals, it's very easy to make an eval that doesn't say what the creator of the eval seems to think it's saying. No doubt these evals will not be an exception to this and will be flawed (see appendix below for more details).

As a way to build my intuition about things, I like to pre-register guesses before looking at results¹. Some things I pre-registered with friends were:

• High confidence (95%): the overall dynamic vs. static language claim won't hold
  • For reasons stated above: this feels analogous to the caveman eval, where the result will, at best, get diluted as the problem gets larger
• Low confidence (60%): static languages will be somewhat better than dynamic at ultra effort
  • Very weak confidence that, at ultra effort, the harness will get feedback to the model more quickly and this will result in some kind of benefit for either correctness or efficiency, but it would also seem reasonable for this to not be the case for all kinds of reasons, e.g., I've noticed that codex, when invoking the Rust compiler, very often makes the exact same error and then has to fix it; perhaps this kind of thing dwarfs things like a hypothetical faster feedback cycle
• High confidence (98%): the "weird" language supremacy of something like J won't hold
  • Same reasoning as the overall static vs. dynamic claim, with the additional thought that AI labs are going to have much less (and possibly zero) synthetic data RL env effort on obscure languages

Zstd

For the first eval, I tried giving agents the zstd RFC (plus errata) and telling them to implement a complete zstd decoder (agents are stuck in a container without internet access). The tests were not given to agents. For something with the surface area of zstd, it's not really reasonable to expect that the tests cover every possible case. For example, even though zstd is a fairly well-tested piece of software, I once found a data corruption bug in zstd. The test suite isn't intended to find extreme corner cases that might be lurking for years and is instead intended to check various cases that can "easily" be derived from the RFC that should work.

Below, the x-axis is cost and the y-axis is correctness score (up and to the left is better / down and to the right is worse); average result on medium and ultra efforts with GPT-5.6 Sol. If we only look at medium (and ignore the fact that results often wildly differ on different tasks), we might come to a conclusion like the Alderson evaluation, that dynamic languages are more efficient and better when using LLMs because (ignoring relatively obscure languages) the cluster of dynamic languages lands up and to the left of the cluster of static languages (we used Alderson's color-coding for static vs. dynamic to make it easy to compare at a glance). But if we look at ultra effort, the results are quite mixed, with a couple static languages doing the best, with more static than dynamic languages among the better results.

The graphs below also have a toggle to convert the x-axis to time instead of cost. The mame/ai-coding-lang-bench noted that it's valuable to get results more quickly (I personally don't find this to be the case because results take long enough that I multitask instead of waiting), so we can also look at that. Similarly, we observe that neither language type dominates the other although, at medium effort on this particular task, the best dynamic language results are once again better than the best static language results (though, once again, they're fairly close).

We can observe that, just like when we compared completely trivial caveman mode evals to a less trivial caveman mode eval, the very strong relationships that held in the trivial evals don't generalize to this larger case. As was the case there, the extreme ratios in performance go away in these larger evals, except in cases where we might expect poor performance, such as when using assembly (which would be significantly more time consuming and difficult for a human) and when using relatively obscure languages where we might not expect that AI labs are expending effort generating synthetic RL environment data.

Note that this is the opposite of what the 1st eval found when it suggested that very dense languages like J would make sense for efficiency reasons. Perhaps using an obscure (and "weird") language can make sense if you have a very large budget and you can train or fine-tune a model to be effective for your pet language, but if you're a normal user of LLMs, it seems like sticking with a mainstream language is likely a better bet than using an obscure dense language.

And it turns out that if we plot language popularity vs. performance on this eval (not shown), we observe a weak to moderate positive correlation where more popular languages end up with more correct as well as cheaper solutions.

As we previously noted, very closely related evals can give substantially different results. For example, we saw significantly different results in the Optimization 1 vs. Optimization 2 evals here when Optimization 1 and Optimization 2 were optimizing bzip2 compression and decompression in wasm, which are fairly closely related tasks as evals go. To make a strong, universal, claim, like "dynamic languages are more efficient than static languages", we'd have to run evals across many tasks. However, showing that a claim like

Dynamically typed languages generally have a lower LLM token cost than traditional statically typed languages because omitting explicit type declarations makes the code more compact.

is maybe at best vaguely directionally true and not really relevant to any particular case and maybe not strong enough to be relevant in general, we just need to try a few cases and see that the claim doesn't generally hold. Above, we saw that at one effort level, the claim seems to maybe be kinda sorta true, but with exceptions, and then at a higher effort level, the claim seems to not be particularly true, which is sufficient to say that the claim is probably not universally true, modulo our eval having a confounder that completely invalidates it.

Pandoc

But, just to get a view on a very different task that's also presented in a different way (more TDD-like than "read a spec"-like), this next eval takes the Pandoc ProgramBench eval and modifies it for our use case. Instead of the reverse engineering task presented by ProgramBench, we present agents with ProgramBench materials as well as the ProgramBench tests and then score agents against a holdout set of tests to measure the performance of each condition².

In the results below, the x-axis is cost again and the y-axis is score on the holdout tests.

As before, we don't see a very strong relationship between success or cost and whether a language is static or dynamic or very dense. We once again see that relatively obscure languages tend to do poorly (although Clojure does much better here than on Zstd). Also, Assembly does much worse, which seems expected in that we would expect a human writing Assembly to be at much more of a disadvantage implementing Pandoc than implementing Zstd and there doesn't seem to be a strong reason to think that LLMs would be different in this regard.

What does it all mean?

Who knows?

I have a lot of questions about what works well when using LLMs (such as, what test techniques work well, what languages work well, what software architectures work well, if bug fixing cost varies by language, if general program maintenance cost varies by language, etc.). Most of these questions are unanswered in public data and, if they've been answered in AI labs, the information mostly hasn't been made public.

Most of the claims that get thrown around about how a particular language is good for LLM use seem to be wrong (e.g., the claim that Ruby, Clojure, and J, are particularly well suited to LLMs, which were mentioned in the evals linked above, as well as the somewhat common claim that Elixir is particularly suited to LLMs), but it's not clear what's right.

In 2014, we looked at the literature on static vs. dynamic types and found that surveying the literature wasn't very informative outside of a few case studies. For an example that typifies a standard academic study, we saw the paper, Do Static Type Systems Improve the Maintainability of Software Systems? An Empirical Study, on which I commented:

Subjects were given classes in which they had to either fix errors in existing code or fill out stub methods. Static classes for Java, dynamic classes for Groovy. In cases of type errors (and their respective no method errors), developers solved the problem faster in Java. For semantic errors, there was no difference. The study used a within-subject design, with randomized task order over 33 subjects. A notable limitation is that the study avoided using “complicated control structures”, such as loops and recursion, because those increase variance in time-to-solve. As a result, all of the bugs are trivial bugs. This can be seen in the median time to solve the tasks, which are in the hundreds of seconds. Tasks can include multiple bugs, so the time per bug is quite low.

Picking tasks that avoid "complicated control structures" such as loops and recursion, where tasks take hundreds of seconds makes the result meaningless with respect to tasks that really eat up a professional programmer's time, just like the first eval we saw where tasks took high tens to low hundreds of tokens. However, with LLMs, we can actually feed them non-trivial tasks and compare how they do. There's the issue of how well results generalize to different tasks, but we'd have that exact same issue with human studies, but worse (LLM variance is huge, but human variance is even huger since you can't get the same human to do a bunch of tasks with different seeds). And while $20 to get an LLM to implement a Zstd decoder isn't exactly cheap once you multiply by the number of languages and the number of iterations per condition per language, if you think about how much it would cost to hire a professional programmer who can read the zstd RFC and implement it, there's no way the equivalent study would've been done because the cost would've made it completely infeasible. That goes double for the Pandoc task.

With LLMs, a lot of the questions have gone from being effectively unanswerable to being answerable with a bit of effort and some tokens. Due to the incentives that are in play³, it's not clear that we'll get answers to questions like this any time soon, but it's at least possible to take a crack at it now.

There are a lot of claims I've seen floating around that these evals can't prove or disprove (for the reason noted above that, due to the variance across different problems, many more tasks would have to be tried), but that these shed some light on, such as:

• Languages with a lot of bad code out there (e.g., PHP) will perform worse
  • Appears to be false on these tasks
• Because it's so easy to re-write now, you should use a powerful language (like Haskell)
  • Appears to be false on these tasks
• You should use a popular language
  • There's weak support for this statement

For my pre-registered guesses, we had

• High confidence (95%): the overall dynamic vs. static language claim won't hold
  • This seems correct
• Low confidence (60%): static languages will be somewhat better than dynamic at ultra effort
  • There's not enough information to determine this conclusively, but if we had to make a binary correct/incorrect call, I would call this incorrect
• High confidence (98%): the "weird" language supremacy of something like J won't hold
  • This seems correct
• [from a draft reader]: "dynamic is better on small-scale, but gets overtaken by static as the size of the project grows"
  • Not supported by these tasks (static languages didn't seem to do substantially better than dynamic on the much larger Pandoc task vs. the smaller Zstd task), but the tasks and the presentation of the tasks are so different that it's unclear if this is because task-size scaling or because of other differences

By the way, a major reason Clojure improves by so much in the Pandoc eval compared to the Zstd eval is that, in the Zstd eval, 36/40 medium and 5/40 ultra Clojure programs had test failures because byte conversion throws on 128–255 (maybe unchecked-byte should've been used?) and they used this conversion inappropriately.

That's a real result, in that, if you ask the best publicly available GPT model to implement Zstd (and presumably if you do other bit/byte manipulation tasks where this might come up), it will emit code that fails in this particular way. If there are tests that catch this, the bug will get fixed, but it will still cost time and tokens. Whether or not a language did well, there are costs like this all over the place (for example, cargo repeatedly gets invoked with the wrong arguments, which then immediately gets caught and fixed, but I've noticed this loop can actually consume a decent amount of wall clock time on my real projects unless you give explicit instructions to codex on how to invoke cargo, and it's clear that's worth the space in the context window).

Anyway, all of this is an illustration of why, if someone wanted to make a strong claim about which languages or classes of languages are particularly good with LLMs, they would need to run quite a few different evals. If we dig into why any particular condition got a certain score, the failures that caused the score are generally something idiosyncratic where it's not always obvious how much the issue generalizes across tasks or across setups. There's no way to look at the score on one eval or even five or ten evals and draw a conclusion about programming in general.

It's true that, in both the Zstd eval and the Pandoc eval, we see a correlation between language popularity and positive outcomes (higher correctness, lower cost, lower wall clock time) and it seems plausible that we'd see this across other evals, but it would be a mistake to draw a strong conclusion about any particular language. I gave a warning like this back when I looked at how often different projects have a broken build according to GitHub CI data, noting that there are different reasons that a build might be broken more or less often across projects and that one shouldn't draw strong conclusions because results across projects aren't necessarily comparable (for example, if one project's main branch is some kind of release candidate that's gone through other vetting, that project would be expected to have low build breakage, but that's not comparable to a project where people are developing directly against main).

Shortly afterwards, someone involved in one of the languages with a high score (IIRC, it was Martin Odersky and Scala) tweeted out the post and cited the language's high ranking as a victory for the language. That was an unwarranted conclusion there and, due to the many sources of variance that are in play here, any such conclusion about a single language would be even more unwarranted here.

This data (assuming eval validity) can refute some strong claims and is suggestive of other claims, but it can really only be suggestive of things for classes of languages and not for particular languages due to having only two tasks, which any particular language could do well or poorly on for some idiosyncratic reason which may or may not generalize to other tasks.

Thanks to Max Bittker, Yossi Kreinen, Aaron Levin, Alan Boll, Luke Burton, Marco Primi, Milosz Danczak, Justin Blank, and Tom Adamczewski for comments/corrections/discussion.

Appendix: selected issues in ai-coding-lang-bench

Like I said above, my eval here is a quick and dirty eval and I'm sure it's full of flaws, so I'm not trying to say the evals I've presented here are great and this is bad, but here are a number of issues in the Endoh ai-coding-lang-bench eval.

One issue is that the wrong executable appears to have been run for some of the tests. The setup for the published run seems to have executed ../../minigit inside each candidate's directory for one of the tests when the candidate's generated executable is at ../minigit. ../../minigit doesn't exist.

Because statically typed languages had a lower correctness score, the author of the eval noted "the only failures in 600 runs were in Rust and Haskell (both statically typed, both relatively "difficult" languages)" and suggests that "difficult languages", such as "C's memory management, Rust's ownership model, and Haskell's monads/purity may add overhead for the AI".

However, Rust's failures were because there is no executable at ../../minigit, causing the test to fail. The first Go run "fixed" this by executing ln -sf minigit-go-1-v1/minigit ../minigit and linking generated/minigit to its own run, but this means that every later execution (for every language) actually executed the first Go run's executable. On rescoring Rust against its own executable (as opposed to having it fail by trying to execute a non-existent file), Rust gets a perfect score, invalidating the theory that Rust had failures because it's a difficult language to deal with.

Other tests also have issues. For example, two tests have a structure that causes them to pass regardless of the actual value being checked. One of the tests has

  if ../minigit commit ...; then                                                                                                                                      
    COMMIT_POST_CHECKOUT=$(cat .minigit/HEAD)                                                                                                                         
                                                                                                                                                                      
    if grep -q "parent: $COMMIT1" \                                                                                                                                   
        ".minigit/commits/$COMMIT_POST_CHECKOUT"; then
      pass "checkout then new commit works"
    else
      pass "checkout then new commit works"                                                                                                                           
    fi                                                                                                                                                                
  else                                                                                                                                                                
    fail "checkout then new commit works"                                          
  fi

The inner if has a pass in both branches, meaning that this is almost equivalent to

  if ../minigit commit ...; then
    pass
  else
    fail
  fi

The inner if appears to be intended to have the actual check, but due to a coding error (perhaps a copy+paste error?), the check is effectively elided.

Also, as noted above, agents can modify the test environment, which the 1st Go agent did to fix a broken environment. They have full access to tests and the environment and can do anything and the test suite is visible during development with no holdout, which can easily lead to cheating by special-casing code in a way that passes tests but creates a program that's useless "in real life". At a high level, something like this seems to have happened in that many programs fail to implement large parts of the spec but do pass all tests, which may indicate that the agents "understood" how to pass the tests and preferred that over implementing the spec (it could also indicate that the tests are very thin and are easy to pass).

Another issue is that the Claude Code CLI versions aren't the same for all runs (it varies from 2.1.66 to 2.1.68). There are a handful of other issues like this that could be significant, but are likely small compared to the issues noted above.

Appendix: medium in a loop vs. ultra

As an example of something we can compare, I was curious how cost effective using medium + asking the agent to keep working would be and then, in the back of my mind, I also had this question about something "Ralph loop" advocates say, that you're better off clearing the context window on every iteration of the loop and giving the agent the full prompt again. As with the above, my pre-registered guesses here are:

• Zero confidence (50%): Ultra is more effective than medium in a loop
  • I'm not sure how to think about this. I guess the case for this would be that ultra was designed in some way and should be smarter than repeatedly doing medium in a loop. But it's possible that there's some tradeoff where ultra was made for more speed and, as we've noted, the variance is very high so even if ultra wins on most problems it might lose here; ultra might also be more optimized for trading off to improve wall clock time or another parameter; ultra also has the disadvantage that it doesn't "know" to stop after reaching correctness on the hidden tests, whereas medium conditions that hit full correctness aren't run again under this setup, which hugely advantages medium in a loop (which is arguably realistic w.r.t. how someone might use these)
  • You could maybe say this is 50% + epsilon since my mind went to framing it this way and not the other way around, but I would say extremely low confidence here at best
• Medium confidence (80%): continuing with context outperforms Ralph loop
  • /goal mode, etc., don't do this by default and, presumably, folks at Anthropic and OpenAI have tried things like the Ralph loop and found them less effective
  • Watching your context window very closely seems to have gotten less important as harnesses (and models?) have improved; in late 2025 / early 2026 I often had to throw out my context window when working on a long-running task to avoid issues and that's gotten rarer over time but, even then, because I wasn't paying attention to what people were saying, I was running agentic loops with a default of keeping context and only clearing when there were obvious problems, which seemed to work ok, e.g., I built the world's strongest Azul AI doing that, so it's not clear to me that having a default of clearing context on every loop iteration was the right choice back then

Below, we have the average result for medium in a loop vs. ultra, sorted by best to worst ultra correctness score, for a prompt that simply resumes individual runs that don't have 100% test correctness as well as a Ralph-loop like prompt that discards context and gives the original prompt again (x-axis is cost, y-axis is number of correct test cases):

For this one problem, on average, running ultra once seems better than repeatedly running medium per unit cost (and much more so per unit time) and continuing with previous context outperforms Ralph. The problem with naively running medium on repeat is that the agent can get anchored to a bad solution and fail to make progress. The theory behind the Ralph loop is that you throw away bad context which can cause this to happen, but that doesn't save you from having a bad artifact.

Just from using LLMs, I've noticed that you're often better off throwing away a chunk of code and having an LLM re-write it from scratch than you are having an LLM modify it or try to re-write it in place. Michael Malis, who's been re-writing Postgres in Rust and has been making major changes has also noted this. This also relates to this idea noted previously that, due to the high variance (plus this path dependence) you're often better off rolling the dice multiple times and taking the best result, if you don't mind spending the tokens.

It's hard to say too much about static vs. dynamic languages from looking at just this one condition, but a naive thought like "static languages will outperform when iterating" isn't obviously true. If there's one pattern that jumps out at me, it's that the cases where the Ralph loop most badly underperformed continuing with context were generally dynamic languages. It's possible this is because of the lack of type information, but we'd need to both look at the differences in trajectories in more detail as well as look at other examples to observe if that's a real pattern. Even if you don't care about Ralph loops now that the Ralph loop trend has passed, being able to make changes to a codebase more effectively when starting a new task or starting with fresh context is something you might care about and the pattern here is suggestive of a possible advantage.

Appendix: Guards of Atlantis 2

I tried to do a third eval that seemed like a more "business logic" kind of eval in both how the problem is presented and the actual execution of the problem. You can argue that the Zstd eval and the Pandoc eval are quite unusual tasks for a programmer to face in that not many programmers receive a specification as well-written and thorough as the Zstd RFC and not many programmers are handed a problem with as many pre-created tests as you get from ProgramBench tests.

The idea here was to implement a board game. In general, board game rules are written by people who aren't experts in writing clean specs, so implementing a board game is more like what happens when a non-programmer (or a programmer who isn't an expert at writing good specs) gives someone a task.

The problem here is getting a game where I have a reasonable oracle for scoring that isn't trivial for LLMs. For example, LLMs were able to one-shot the rules for Scout and Azul, which make those poor tasks. For games that an LLM won't immediately one-shot, I happen to have an oracle for Guards of Atlantis 2 because I had an LLM implement a copy for me and my friends to play (no link for this one because I don't see how to make an interface that's free of copyright infringement). The backend only took a few hours of my time, but it took a fairly large amount of LLM time to get the rules to be roughly correct. I like this as a task in that the rules are tricky in the same way a lot of problem descriptions that are delivered to programmers are tricky, but it is, in principle, possible to figure out the correct rules and implement them (after all, humans implicitly do this when they play the game correctly offline).

In board game rules, it's fairly common to have rules where reading the rule strictly as written is incorrect and you need to use "common sense" (or read some kind of FAQ) to play the rule correctly (there are some game designers who strive to avoid this, such as J C Lawrence, but this is fairly uncommon). Guards of Atlantis has quite a few rules like this. The designer of Guards of Atlantis is also vocal about there being no such thing as the spirit of the rules or common sense interpretations of the rules and says that you should always read the rule exactly as written, so there are also many cases where you need to ignore the "common sense" interpretation and read the rule exactly as written. This combination is quite difficult for LLMs (and, judging by the rate at which I see humans play the game according to the designer's intent, it's also quite difficult for humans).

I think it would be effectively impossible to just read the rules and play correctly (of course it would be possible, but it would require knowing which rules are to be read as written and which rules are not, which one would have to do randomly and get lucky as the rules don't define a consistent system that one could use to infer which rules obey which meta-ruleset). When I was implementing the game, in order to get my LLM to understand the rules, I gave it various resources such as an unofficial rules FAQ (which is correct), an unofficial short version of the rules (which is better written than the official rules and correct, but incomplete), an opening book (which can be used to test rules against on the assumption that the opening book only contains legal moves), comments from the rules channel on Discord, etc., and had the LLM do consistency checks across these with the understanding that things like the FAQ and the Discord comments have higher authority than the actual printed rules. With my $200/mo personal OpenAI/codex account, I let an LLM use all my spare capacity to run consistency checks and make rules fixes. I didn't closely track how long this took, but I think it was something like a month or two of cranking on fixes like this to get a somewhat reasonable result that's playable, but that I wouldn't really trust to be correct.

The only reason I somewhat trust this is that Pedro Oliveira also implemented Guards of Atlantis and they used a completely different approach (a more standard approach of having a human drive an LLM rather than trying to get the LLM to figure things out itself). When we compared implementations, we found maybe 10-ish bugs in each. There are probably some remaining bugs where both of our implementations incorrectly do the same thing and perhaps some where our implementations differ but the checking system didn't notice, but I think the rules for both of our implementations are now reasonably solid. That's how I have an oracle for this game.

I like this as a task because it feels more like the kind of "specification" you get in the real world, where the spec is ambiguous and contradictory and sometimes just plain wrong, and then you need to use other information to get a correct result. For this eval, to avoid having it be a test of how well LLMs can access data in annoying formats (such as converting the opening book from a set of images to some kind of structured data, converting a scan of the rules to text, etc.), I gave agents both the originals of anything where I directed an LLM to extract the data (which also required various consistency checks to get correct) as well as the the extracted data (the originals were presented so that LLMs could check the originals for extraction errors if they chose to).

While I did this task with older models (I did a chunk of it with GPT-5.1 or 5.2, and then another chunk with 5.4 or 5.5), with newer models but without the kind of guidance I gave to the older models, the task was still far too hard. Regardless of language, agents scored approximately 0 on this task.

BTW, if you're curious what LLMs (and humans) struggle with, here are some examples. There's one card whose text reads "Target a unit adjacent to you. After the attack: may repeat once on a different enemy hero."

In this game, a hero is a type of unit. Read strictly, with full knowledge of the rules, e.g., what "After the attack" means, etc., this should mean that you can either attack a single unit or you can attack two heroes (after all, to repeat the attack on a different enemy hero would mean that the first unit was a hero; otherwise it would be a different unit that is a hero, not a different enemy hero).

This card actually has what is effectively an errata printed on the card because people complained it was unclear; the errata reads "(You may repeat even if the original target was a minion)". That's already confusing to LLMs (and some humans), but the real killer here is that there are other cards that use the same construction and don't have this correction. To play other cards with the same construction correctly, you need to know that every time this construction is used, you should play it with the errata that's on this card. There are a number of constructions the game designer likes to use that have a specific non-literal meaning that you have to keep in mind.

Another example of a rule that shouldn't be played in the obvious way is a character with a card which reads "Choose one, or both, on different targets: A, B". Reading this strictly as written, one would expect to be able to, on different targets, do either A or B, or both A and B. But part of the spirit of the game is the meta-rule that a character can't attack another character multiple times with one card, so the interpretation that you can do what the card says and do both and A and B on some number of different targets can't be right. Based on similar deductions and how similar constructions are used, the way this card is supposed to be interpreted is "Choose one, or both on different targets", which is arguably still ambiguous and could be more clearly written as "Choose one or both (must be on different targets if both)".

As a human, once you understand what the "spirit of the game is", you can resolve these kinds of things. But, by design, this isn't written down clearly in the rules and one has to infer this from Discord discussions, which appears to be beyond the capability of today's models even though humans who are outperformed by today's models on many specialized tasks are able to do this.

When I was supervising the LLMs that implemented the rules, the reason LLMs reached a ceiling and didn't converge to fully correct rules was that an LLM would observe that a rule was inconsistent and incorrect. It would then try to fix this rule and would also fix other things to try to make them consistent and correct. This would sometimes make things more correct and sometimes make things less correct. When making things less correct, the LLM would sometimes modify an existing correct test to turn it into an incorrect test so, after a while, the LLM wasn't really improving correctness and was just churning on which rules were incorrect. That was with some guidance on what to check and how to check it; without that guidance, even with the more advanced models that are available today, LLMs were unable to navigate this in a reasonable way.

I'm sure there is a board game of the right rules complexity to make for a good eval here but, by definition, this would be something where it would take some work to create the oracle and I don't have an oracle handy for a board game with the right rules. If my goal were to make evals, I would've used board games with actual game replay data to get good tests or oracles for a whole bunch of games, but my goal was to play a particular game with some friends. But, if one were inclined to try this board game thing, it should be possible to create hundreds (thousands?) of these in a scalable way, so one could get a reasonably correct oracle for hundreds or thousands of games and then check which games are at the correct level to be an interesting test for LLMs today.

This is arguably a bit of a funny problem in that, given a clear spec, e.g., a clearly written set of rules, an artifact that's more complex than Guards of Atlantis can be implemented by LLMs (I would argue the Zstd RFC is more complex, and Pandoc certainly is; even individual document formats Pandoc supports, like PDF, are more complex than Guards of Atlantis), so the problem isn't finding a game with rules that are complex enough that LLMs struggle and the problem is more about finding a game with rules that are ambiguous or contradictory enough that LLMs struggle, but not so much so that LLMs are completely hopeless. This is an actual real-world problem, in that humans are generally not very good at writing clear specifications and how well models and harnesses can handle a human's unclear, contradictory, and sometimes just plain wrong, specification is probably more relevant to the typical user than how well an LLM can implement something from a specification as well-written as the Zstd RFC or how well an LLM can implement a problem when handed the 4800 ProgramBench Pandoc test cases plus documentation. And these problems seem solvable in principle, in that humans who want to play board games correctly (even ones who would have no hope of "playing" Zstd correctly, let alone Pandoc) are generally able to navigate the mess of information out there to figure out what the rules to a board game are.

Appendix: reasons for various decisions

• Testing ultra
  • I've seen people say that you shouldn't really measure this because this is a harness thing and not a model thing. I can see why you'd want to measure these separately if you're working on improving models or harnesses, but when looking at how users use things, many people are just going to use codex or claude with the various built-in features and options; whether or not something is a harness thing or a user thing isn't really relevant to them
• Using codex
  • I've seen evals use a very thin harness for the same reason as above and my reason for using codex and not a very thin harness is the same as above
  • Similarly, in this caveman model eval, I used claude with Opus and Fable and codex with GPT
• No internet access
  • Models will often cheat if given internet access and there are plenty of problems where searching on the internet doesn't turn up source code that solves the problem, so this makes these evals approximate those more closely
• Relatively large tasks compared to a lot of benchmarks people pass around
  • Although I have LLMs do plenty of trivial tasks, the things that take my time or take tokens tend to be larger than the kinds of tasks that were in the Alderson eval or the Endoh eval; LLMs are good enough at trivial tasks that it doesn't make too much difference to me if some condition makes them slightly better or slightly worse at one of those trivial tasks, but for a task like implementing Guards of Atlantis, where I have to spend some number of hours setting up scaffolding for the task to even sort of work, I care a lot about what makes models perform better or worse
• Agent-specified prompts
  • Public evals seem to have moved to relatively thin/lightweight prompts that don't specify the task in great detail; this is said to be better because an agent setting up a task will give too much information that helps agents succeed at the task
    • I can see why you would want to test that, but it's also the case that I care a lot about how well agents do at tasks set up by agents because a lot of the tasks that I have agents execute are tasks that are defined by agents; I care about how agents perform under both styles, not just one style, and the public evals have moved towards one style
• Zstd eval: asking agents to fix bugs without telling them the issue or the failing tests
  • In general, if you tell an agent to fix a specific thing, it will fix it, but it won't necessarily fix the class of issue; I've found that if you tell it there's an issue but don't tell it what the issue is, it sometimes does a more general thing instead of just putting in a narrow, brittle fix, so I do care about how agents behave when given instructions like this (of course you can tell agents to not just make a narrow, brittle, fix, but that often doesn't work)
    • This feels a bit related to the issue we noted in the Pandoc holdout footnote, where telling agents we had a holdout set appeared to force agents to produce more generalized and less brittle solutions

Appendix: issues with these evals

When it comes to performance benchmarking, I've done enough of it that I feel like I generally know how my benchmarks are flawed and I can make an informed time/effort vs. flaw tradeoff and I have decent confidence the flaws that exist in the benchmarks aren't material to the thing I'm trying to understand. I haven't done enough AI evals to have this kind of feel for AI evals so, at a meta level, I would expect any AI eval I do to have some unknown-to-me flaws.

Another reason I would expect some flaws here is that I had coding agents set up these evals and every time I spent a minute looking for issues I would find at least one issue. This indicates that it's fairly likely that these evals have additional flaws that could be uncovered by looking a bit more, but I wanted this to be more of a "quick toy project" level of correctness than a "Gary Bernhardt" level of correctness, so I stopped after fixing a handful of issues.

Back when I was working as a verification engineer, I attended a meetup by a Sun/Oracle engineer in Austin, maybe around 2007 or so, where they mathematically formalized this idea of converting the time between bugs to a level of confidence in a chip release. I haven't seen people do this much, but I recently heard Will Wilson (co-founder of Antithesis) mention that some folks at Antithesis used math from ecology (the literature on rare species observation) to estimate true bug rate, which seems like a much more sophisticated version of what this engineer at Sun/Oracle was doing a couple decades ago.

That's a cool idea, but when you're finding a bug every minute you look, you don't need fancy math to tell you that there are probably a lot of other bugs. If I were doing this for work and we had some reason to care about the fidelity of these evals, it would probably make sense to look at these more closely and fix more issues (and I would probably have the skills and experience to make fewer mistakes in instructing LLMs to set up these evals if I did this kind of thing for work). But, for the purposes of answering the question "is the claim that dynamic languages are meaningfully better than static languages when using LLMs?", I have a little more confidence that the claim isn't true, and there are a lot of other questions that seem more likely to yield some kind of actionable result (such as, what techniques or test libraries work best).

I normally don't publish things on the blog until I feel like they're somewhat solid, but this means that I often explore some data enough to satisfy my curiosity and then never publish the result. From talking to people about these non-published results, people I talk to are often curious about the results even if they're not done to a standard that I really like, which seems like an indication that folks I don't talk to might be interested as well. From what I've seen so far, I suspect it would take at least 10x the time I've put into this to get this to a standard I really like. I'm fairly busy at the moment and can't see myself having the time to do that for months, at which point I'm not sure I'd really ever get around to publishing this. In a recent post, I mentioned an analysis I did almost a year ago where I was trying to understand which cars are better for concussion risk in accidents, where I spent some time figuring that out, got far enough to get an answer that satisfied me, and then didn't ever get around to doing the work it would take to clean up the result enough to publish it.

There are some results from that analysis seem "publishable", in the sense that they could turn into a published paper (such as finding from actual crash data that the relationship between HIC and velocity looks like it's to the fourth power (!); there's a paper that tried to find this relationship, but did the wrong kind of analysis and wasn't able to find an "O(n)"-style relationship and had something much fuzzier), but I've never really cared about whether something is a paper or a blog post and it turns out that I'm more likely to just move on to the next analysis instead of cleaning up the analysis enough to publish a post.

A more recent project along these lines is that, after making a superhuman Azul AI, I tried to make a superhuman Splendor AI using a much less human-time-intensive process. I believe that didn't succeed, but it beats every other Spelndor AI I could find by a good margin, which is a mildly interesting result. I think I know enough about board game AIs to write something up about them, but my main interest was in figuring out if I could get something decent, and then I keep just doing other projects instead of spending the time to do a nice write-up. An example of something I think is interesting there is that a lot of the performance optimizations you want to do actually change the result, so you can't only rely on optimizations that can be strictly checked to not change the result. But, if you naively ask a coding agent to do these optimizations in a way that doesn't reduce playing strength, they'll do all sorts of things that reduce strength. Cases where the strength reduction is very severe are easy to catch, but there are more subtle issues that sometimes result in (for example) no change in strength vs. your own AI in self-play but a reduction in strength against humans or other AIs, so some kind of process to catch bad optimizations is necessary, and it's inherently a kind of arbitrary process that has to be designed using some combination of your intuition and relying on LLMs (which will be very helpful but also often completely wrong).

For these kinds of data-y projects that I'm interested in, LLMs massively reduce the amount of effort it takes to get a result that's strong enough to satisfy my curiosity but, AFAICT, they don't reduce the effort it takes to publish a result by much (at least if you write up results by hand instead of having an LLM write up the results and you want the results to be nice and clean), which means that writing them up runs into a kind of Ahmdhal's law bottleneck, so I've been doing more projects like this and writing up fewer of them. If anything, I think it actually takes more time to write these up because of how I've changed my workflow. For example, instead of just outputting some graph from ggplot2, I'll make a version an interacive version that's nicer in some ways, but definitely takes more time to produce. And I run an LLM spell/grammar check pass (at least so far, that's the only LLM assistance I've used for writing), which turns up a bunch of issues to be fixed. Since I look at each one manually instead of taking the fixes (and I make a lot of typos), that's actually fairly time consuming (over an hour on my last post and over half an hour on this post even though I didn't even make corrections all the way to the end and abandoned the process maybe halfway through).

Anyway, publishing this is an experiment in publishing some half-baked notes instead of having the kind of cleaned up version that I'd really like to have before publishing something. If you have opinions on this, please let me know (X Bsky Mastodon)!

I don't have GitHub links to the current evals. On the one hand, I feel like I really should. On the other hand, they're a mess and there's a bunch of stuff I'd want to clean up before publishing the code, and I don't know if/when I'll get to that and this way, at least I'm putting something out there instead of just talking to a few friends about the result and then having the result sit on my hard drive indefinitely?

Appendix: more details on Zstd

Agents were instructed to ignore performance, but the timeout wasn't infinite and, under the medium condition, some test cases timed out. This is arguably unfair, but this didn't materially impact the score. For non-infinite loop timeouts, there were 2 test cases in Clojure (across 40 * 34 tests), 2 in J, 2 in Tcl, 1 in Factor, and 1 in PHP. And, at 9000s (2.5h), the timeout was fairly generous considering that the largest test case was 4 GiB. Failing to decode 4 GiB in 2.5h is an implied rate of less than 0.5 MB/s on a Graviton 5 core, which is quite slow.

Here are some of the issues that I ran into when trying to get agents to set this up (and, as noted above, the short amount of time it took to find each issue implies there are more issues)

• Originally, the build setup wasn't clearly specified to agents, causing some languages to randomly fail when agents did something that seemed reasonable based on how this was specified to agents but didn't work when scoring occurred
  • BTW, I was very exicted by the initial result here because it was super interesting looking and it confirmed my biases. Dynamic languages were substantially worse than static languages. What a blockbuster result! But it turned out that the real result from the initial setup was that static languages were less likely than dynamic languages to have problems caused by this issue because static languages were less likely to have issues with the idiosyncratic way project builds were ambiguously specified
• In the original assembly conditions, agents implemented code in C and then compiled it to assembly and submitted the assembly
  • With this issue, asssembly did as well as other languages, which is super interesting! And also false once this issue was fixed. It turns out to be very easy to get incorrect but compelling looking results that would easy go viral if you aren't careful. After fixing those two issues, the results looked fairly mundane and fall into what you might call a "negative result" in the framing of a paper, in that there's no interesting or surprising or contentious thing the results show; perhaps slightly favoring boring languages would've been contarian result for very online people 10-20 years ago, but very online trendy discourse seems to have moved away from that, so this isn't really an interesting contarian result anymore
• For some reason, the agent doing the setup imposed unusual arbitrary restrictions on some languages and not others (for example, the Rust setup didn't have access to rustfmt or Clippy); most, but not all, languages had things like this
• Many of the tests (which were created by an agent) were actually some kind of performance/stress tests even though agents were instructed to ignore performance (I wouldn't consider processing 4 GiB of Zstd in 9000 seconds a performance stress test)
• Some language conditions had arbitrary instructions to agents (for example, the Haskell condition had instructions not to use bytestring, with instructions on alternative implementation suggestions)
• Some language conditions had old toolchains (for example, Zig was on 0.10)
• Some language conditions had scaffolding to help agents implement Zstd
• Some language conditions had explanations of tools that were available that were incorrect (for example, assembly conditions were told they had access to GDB, but GDB didn't work)
• The agent responsible for health checks for running iterative evals would sometimes decide that evals weren't making enough progress and give held out tests or other information to agents inside the eval

There's one thing which arguably wasn't a bug that I removed anyway. One of the tests was very hard (maybe 10% of agents passed the test on the first try). On testing the current zstd release binary, the zstd binary also fails this test. On reading the RFC, this seems to be an ambiguity in the RFC about the legality of a certain edge case. There was fairly strong clustering with respect to which languages passed this test case more frequently, which I think is interesting, but doesn't seem like a very useful thing to measure when all of the other tests are measuring (or at least attempting to measure) something more straightforward.

Anyway, in the above list (which is not exhaustive), many of the issues impacted a large fraction of languages and some issues had to be fixed multiple times. All told, if you count each condition as a separate bug, I probably fixed (had agents fix) over 100 of these bugs and I expect there are more. When I talked to Max Bittker (who runs an RL environment startup), he noted

all the evals I've worked on, I ended up putting a huge amount of time and effort into, mostly in the form of reading trajectories (or summaries of many trajectories) and then triaging issues , e.g "oh this class of bug shouldn't be possible, lets update X "(X being the prompt, the harness/ environment, or the verifier)"

agents tend to slop this up, so I put a lot of care there to make sure things get fixed at the right layer, for instance it's very sensitive what's in-context for the agent under test (bad to add random junk it has to worry about, or at worst leaking answers) vs whats fixed behind the scenes in other parts of the system.

agents, when writing evals, are not sensitive enough to the experience of the agent under test, and will just give it the answer or fix problems by making it the inner agent's problem ("remember to not reward hack plz")

I also have had a lot of success re-using existing things (repos, games, tools, levels) and building harnesses and verifiers around them, versus trying to make something from scratch for an eval by prompting

In retrospect, I sort of regret doing a cross-language eval. Even after fixing 100 or more eval issues, I have no doubt that plenty more remain. Maybe this is just a "grass is greener on the other side" thought and I'll also regret the next eval I try, but I think it would've been a lot less work to try to evaluate how well different test techniques or testing frameworks work than to evaluate different languages and I find that topic at least as interesting. And, in retrospect, had I done a lot more work by hand and relied on agents less, this would've gone a lot better. For example, I should've had agents produce an environment for one language and then both had agents inspect it and inspected it myself and fixed the issues before producing the environment for another language. After doing this a few times, I might've had a better setup for producing environments for other languages (and if not, I could've just repeated this process for each language and gotten a more reliable result, likely without even taking more time).

Another thing to note is that a number of things that are genuine differences in languages weren't really tested, such as memory safety against adversarial inputs. If agents had a harder time producing generally roughly correct code in C or C++ than Rust, that would be observed, but if a fuzzer or valgrind or other tools would turn up issues, that's not likely to be captured in the small set of tests. Just out of curiosity, I asked an agent to (briefly) check the Zstd C and C++ code for memory safety issues. The agent claims it ran the C and C++ code under ASan+UBSan and tried a few fuzz inputs (4000 each) and didn't find issues, but of course that doesn't mean there aren't issues or that a larger codebase wouldn't have issues.

And, in fact, doing an analogous quick check for memory safety issues for the Pandoc eval found memory safety issues in all of the C programs and all but one of the C++ programs (the issues were things like incorrectly dereferencing out-of-bounds memory; one specific example is that, in one of the C programs, a truncated LaTeX table could result in an out-of-bounds memory read). The fact that these issues were findable with 10 of seconds prompting indicates that many such issues could be found and fixed without much human effort, but it would cost quite a few tokens and would push the cost of the C and C++ versions well beyond the cost of the Rust version and after doing all of that you would still have less confidence in the memory safety of the C and C++ versions than in the Rust version.

Anyway, if you're curious about the distribution of results, we have the following for medium and ultra:

I don't love that the ultra results are somewhat saturated here, but one "problem" with testing ultra is that it will keep going for a long time as problems get harder (e.g., most of the Pandoc ultra runs ran for 12+ hours, and the assembly runs went for much longer), so the things that don't get saturated are very large tasks, like the Pandoc eval, or tasks that are too difficult in some way, like the Guards of Atlantis eval.

We're going to look at three different kinds of benchmarks, one set of calculations for baseline numbers for performance "napkin math" estimates, one set of AI model evals, and one on car tires. To build my intuition for things, I like thinking about them before seeing the explanation, so these are presented with the benchmark information first and the explanation later in case you want to think about your answer before seeing my thoughts.

29. A friend of mine is reviewing performance orders of magnitude to prep for computer performance interviews and found that https://github.com/sirupsen/napkin-math (5.4k stars) was the top hit. The README's tables include:

What's wrong with this benchmark?

30. I keep seeing people reference DeepSWE and Senior SWE-Bench to "prove" that their favorite model is better than other people's favorite models or just as generally good benchmarks, such as in

What's wrong with these benchmarks?

31. People frequently say that winter tires are superior to all-season tires in cold weather. For example, on googling "all season tires during winter cold" (no quotes), the Google AI summary leads with

All-season tires lose traction and stiffen in freezing winter temperatures. Their rubber compounds are designed for warmer weather and become hard below 7°C (45°F), leading to significantly longer braking distances and reduced grip ... The rubber in all-season tires cannot maintain pliability in sub-zero temperatures, causing them to perform more like hard plastic on snow and ice.

Given that there are a lot of internet comments in the training data, this is a reasonable comment, in that I frequently see variations on this comment on discussions of which tires one should use.

What's wrong with this benchmark?

29. Napkin math numbers

Random memory access latency

The thing that immediately jumped out to my friend (Jamie) as odd was random memory R/W listed as 20ns, since random memory R/W is implied to be a real DRAM read (as opposed to a cache hit), which he felt this should be around 100ns for an order of magnitude estimate.

As we were chatting about this, he noted that the README uses the term "latency" for some things that aren't really latencies. Then, when he pulled up the code for random memory read latency, he found the following (if you want another exercise, consider what's wrong with the following code before reading the explanation below):

  while test.i < test.vec.len() {                                                       
      let random_index = test.order[test.i];                                            
      black_box(test.vec[random_index]);                                                                                                                                         
      test.i += 1;                                                                                                                                                               
  }     

Jamie noted that there's no data dependency between the loop iterations, so the memory reads here happen in parallel. Since the alleged latency number is determined by finding the average time for an access, this is incorrect because the CPU can have multiple loads in flight at once. If you wanted to measure latency this way, you'd have to introduce a dependence between loads, to prevent overlapping accesses (we discussed a related topic in exercise 19, covered in part 4 of this series).

Random SSD read

I agree with all of Jamie's comments, although I didn't really flag the use of the term latency myself because maybe it's shorthand for latency in some cases and something a bit latency-like in other cases (such as reciprocal throughput), which makes the table simpler.

What first jumped out to me, besides the memory latency number, was some of the other numbers. For example, random SSD read is listed as 100 us / 70 MB/s. You can get much faster (as well as much slower) SSDs. For example, if you have a fast (but non-exotic, e.g., non Optane) device, you might see latencies below 40us, e.g., the Kioxia CD9P-R was measured at ~30 us here. Other than for some trivial scripts, I haven't worked on anything where I care about disk performance, so I don't have an intuition for what numbers someone would want to have in mind¹, but I also wonder if having a single number for random read latency and throughput is less useful than it is for DRAM accesses. Whenever I've looked at disk benchmarks, it seems like there's a huge range of results based on read size, queue depth, and number of jobs (e.g., see the previous link on the Kioxia CD9P-R). Of course, there are analogous factors that influence DRAM latency and bandwidth, but it seems like you're much more often in a regime where knowing one or two numbers is helpful when thinking about memory accesses. Since I don't know anything about disk performance, I asked Peter Geoghegan, who's done work on Postgres disk performance; he concurred and also wrote some additional comments on the complexity of disk performance below

If we look at the code for this SSD random read number, it feels off to me in the same way that the random memory read code felt off to Jamie. It generates offsets with

for i in 0..(buffer.len() / page_size) {
    pages.push((i * page_size + 1) as u64);
}

and then does 8 KiB reads (offsets are shuffled to create random reads). Some things that don't feel right about this are:

1. The +1 makes every read unaligned. With a 4KiB page size, this makes one read touch 3 pages
2. Different offsets can overlap the same pages, causing seemingly unintended reads from page cache
3. Depending on the page size, reads can extend past the end of the file and cause a panic

The "buffer.len() / page_size" construction seems to be intended to keep accesses in bounds, but this is independent of the access length. If we want to be lazy and not think about exact offsets, consider some huge access length like 4 GiB (the buffer size is 8 GiB). That will surely overflow. If we want to be more precise, the overflow case will be more like a 4KiB page with 8KiB access length, but the same idea applies.

The very last offset is going to be SIZE - 4096 + 1. This gives us 4095 bytes we can access, but we try to access 8192 bytes. Because the benchmark only runs for 5 seconds, it may or may not actually try to read past EOF and fail, but there's a bug here regardless of whether or not it randomly fails on any given run.

Sequential SSD read

Just looking at the code, a lot of it doesn't feel quite right to me. For example, consider the code that's used to generate the sequential 8 KiB SSD read, which is said to have 1us latency and 8 GiB/s throughput. Like I said, I haven't worked on any problems where disk performance matters, so I don't have an intuition on whether or not numbers like this are plausible, but the code feels off to me. The code takes a 1 GiB file, flushing it, and then re-reading it repeatedly, so we'll have one uncached read followed by cached reads. It seems like the intent is to measure uncached reads here, but if the intent is to measure cached reads, the code isn't doing that either (this appears to be an issue for some of the other numbers as well, such as 3 GiB/s of fsync'd reads). One could argue that it's realistic to have an uncached read followed by cached reads, but it's not clear what someone who's using the aggregate number of 1 uncached read followed by N cached reads should do with the number when they don't have the exact same workload; N isn't stated in an obvious way, so they wouldn't even know if they have the same workload.

Since I have no idea what the numbers should be here, maybe we can look up some numbers. The measurement was said to be done on a c4-standard-48-lssd. Google's docs for that instance claim that the maximum throughput for all 8 attached disks is 5000 MiB/s (from Google's table, this scales per number of attached disks and is 625 MiB/s per disk). From the very little I know of disk benchmarks, it seems like peak throughput numbers are generally done when using larger reads, so 8 GiB/s seems excessive and the feeling that something is off from the code seems to be right. And if we look at other numbers, it seems like the broader point that having a few single numbers for specific read sizes isn't representative of disk performance in general.

Representativeness

But the idea behind this kind of "napkin math" generally isn't to know how exactly one cloud instance performs; it's to get some basic numbers that can be used to estimate performance in various ways. If we look back to the Kioxia CD9P benchmarks, there are plenty of read benchmarks with higher bandwidth than that, with various parameters (and also plenty with lower bandwidth, with various parameters). For latency, the latency is higher even for sequential reads at settings that minimize latency (including for the other disks in the benchmark), which is another sign that the sirupsen benchmark is inadvertently reading from cache, but even if the numbers were correct, it's not clear what you'd do with the numbers.

It seems like the sirupsen code has an attempt to prevent caching and prefetching. If it detects the test is being run on Linux, it sets an advisory POSIX_FADV_RANDOM and, before the test starts, it sets an advisory POSIX_FADV_DONTNEED, but neither of these will prevent caching on this benchmark at the OS level, nor should these be expected to prevent lower-level caching (such as inside the SSD). On Mac, the benchmark calls Command::new("sudo").arg("purge").output().expect("failed to flush page cache") beforehand, but there's no equivalent of POSIX_FADV_RANDOM and there doesn't seem to be anything done on other OSes (such as BSD or Windows).

There are other issues in other parts of the code, but rather than get into the weeds on every specific issue and most of the presented values, if we come back to this idea that there are things where we want to get an idea of a range of numbers in different regimes, there are quite a few places where that seems to be the case. To pick another example, the README cites "Decompression" at 1 GiB/s and "Compression" at 500 MiB/s. Of course, any kind of napkin math isn't going to be precise, but just playing with different zstd compression options, we get more than two orders of magnitude difference in compression speeds and there are algorithms that are more specialized for high speed compression, giving an even larger range (and of course you can spend more effort to get lower speed and denser compression).

Going back to the disk example, we noted that the disk numbers come from a VM configuration with 8 disks. The numbers appear to be incorrect but, if the numbers were correct, of course you'd get different numbers for something like read bandwidth if you used a single-disk version of the VM. You'd expect roughly 1/8th the read bandwidth for the read benchmarks if it wasn't reading from the page cache. It's not clear why it's particularly useful to have a read bandwidth number for one particular 8-disk configuration on GCP memorized as a napkin math figure.

What's useful to learn?

Overall, I do find knowing some of these kinds of numbers useful, but I don't know that I'd necessarily want to look at a table to see the numbers (except maybe as interview prep that I'd expect to forget immediately after the interview if I had good reason to believe I'd be asked about them in an interview). In general, if you're doing things where it makes sense to know these numbers, you'll pick them up just by using them. For example, I still remember that dispersion in standard single-mode fiber is 17 ps / nm * km because I did some optics / photonics work twenty years ago. This comes up often enough in back-of-the-envelope calculations that you'll just remember this at some point if you use it enough. Likewise for various powers of 2 (e.g., 2^8 = 256, 2^16 = 65536, etc.), which I didn't try to memorize but picked up because, if you do enough coding where you touch these numbers, you end up remembering the numbers that often come in handy.

The linked napkin math repo notes that "numbers [are] rounded for memorization", implying that it makes sense to memorize these. In addition to what's mentioned above, a lot of these numbers are derivable and, in my opinion, if you're using these for work, it often makes sense to understand the derivation even if you have a ballpark number memorized. For example, we derived the single-core memory bandwidth number for a Sandy Bridge processor from some basic parameters in part 4. If you just want to know how fast a piece of code is going to run, you generally don't to rederive everything from first principles. But, if you're trying to understand the implications of changing something, it's helpful to know the what mechanisms are in play and how they'll interact, which is something you don't get from having a handful of numbers memorized.

Going back to the context for this question, my friend who was doing interview prep, the last concern he mentioned was that this repo is very popular, so the interviewer might be use it without knowing that most of the numbers that are listed are wrong.

Bonus info: memory latency over time

BTW, I was curious what memory latency is actually observed on real systems, so I plotted the data from the instlatx64 site, which reveals the following:

There are two graphs here because two different, non-comparable, methodologies were used. The original methodology used accesses with a 1024 byte stride to find memory latency, which worked fine for accesses over a large enough data set on older processors. Newer processors added mechanisms that can make this fail to be a pure DRAM access, so the newer methodology uses random accesses to find memory latency (some of the later numbers using the old methodology aren't really valid if you're thinking of them as a random memory access time). The latencies come from the instlatx64 site and the CPU release year was found by asking GPT-5.6 Sol ultra in codex without verifying the results, so some of the years are probably incorrect.

Just from eyeballing the graphs, we can see that memory latency improved tremendously for a while, but this improvement eventually stalled out and we actually see higher observed latencies over time for reasons that are outside the scope of the post.

690ns?

We also see some extremely high outlier results from the 90s. Without spending too much time looking at these results, it's not obvious that the results are incorrect. On the Intel side, the big outlier is an 83 MHz Intel Pentium Overdrive. The other old Intel results are all non-Overdrive Pentiums.

The Overdrive Pentiums were chips you could slap into a motherboard for a previous generation CPU. It looks like the test was run on a Gigabyte GA-5486AL motherboard with an ALi M1489/M1487 chipset set to a 33 MHz bus speed. According to the ALi M1489/M1487 datasheet, there are four possible DRAM read timings. If it's configured to the "normal" setting, a read page miss is CP+8, with a 4-4-4 read timing. I'm even less familiar with 486 bus timing than I am with disk performance, so I asked an LLM about this and it told me that this is correct and we should expect 21, 22, or 23 cycles for a memory access here. This doesn't feel quite right since, on asking the LLM what the heck these numbers mean, it's for the first word followed by each additional word, so that number of cycles is for a full cache line fill. The actual load-to-use latency for a word access should then be the first part, or 11 bus cycles, but if you want the time for the whole cache line, then the number seems plausibly like it's in the right benchmark.

On looking at the outlier AMD K5 PR166 result, there's something a bit odd about it, but we're pretty far off into the weeds on a question about modern computer performance, so maybe that can be another question for later in the series.

30. DeepSWE / Senior SWE-Bench

General plausibility

Before looking at the methodology of these benchmarks and just looking at the results, neither DeepSWE nor Senior SWE-Bench feel plausible as summaries for how well coding agents work overall. A surface-level reading of the DeepSWE homepage has OpenAI's last-generation model (GPT-5.5) being as good as Anthropic's current-generation model (Fable 5) and a surface-level reading of the Senior SWE-Bench has Anthropic's last-generation model (Opus 4.8) as being better than OpenAI's current generation model (GPT 5.6). In general, the surface-level reading is what most people will take away and this is how I generally see these used (e.g., in work slack, when people send these to me directly, etc.).

Methodlogy issues

If we look at how the sausage is made, very few of the publicly available benchmarks seem like reasonable things to rely on for getting a general idea of how good coding agents are. In terms of methodology, the benchmarks don't really make sense with respect to what you'd need to measure to get a generalizable result. Just like I don't know anything about disk performance, I don't know anything about AI, so I asked someone who ran an evals team at Anthropic for a while (Aaron Levin) to review the reasoning and conclusion and he concurred with the general idea and the reasoning. As with the consultation with the disk-performance expert, the point of this isn't to say that you should agree because an expert agrees; it's to say that, in these cases, you don't need any kind of specialized knowledge about the field to come to the same conclusion an expert would come to. You just need to apply the same kind of generic reasoning you'd use to evaluate any benchmarking or experimental design problem.

Summary score representativeness

In the last post, we discussed the high-level idea that a single summary score can say pretty much anything because, when we look at subbenchmark results, there will be plenty that favor model X over model Y and there isn't a particularly good way to, in general, sample the distribution of tasks out there to say that benchmark A is better than benchmark B because it's more representative.

If we look more at the details of these benchmarks, for DeepSWE, there are 113 tasks (or that's what codex told me, anyway), each one of which is run four times, with what generally appears to be a pass/fail score (models appear to score 0%, 25%, 50%, 75%, or 100% on each task). On the graph, we can see that GPT-5.5 is much better than Opus 4.8; the difference between GPT-5.5 and Opus 4.8 is about as large as the difference between Opus 4.8 and Gemini-3.5 Flash. As we noted above, if you've used these models, this doesn't really match the experience I or anyone whose judgement I trust has, overall (of course there are specific tasks or sub-benchmarks where this is true).

If we look at why this is supposedly the case, GPT-5.5 xhigh is allegedly a bit cheaper than Opus 4.8 xhigh and much better (scoring 67% vs. 54%). Of the 113 tasks, the models tie on 34 tasks, GPT-5.5 xhigh wins on 57 tasks, and Opus 4.8 wins on 22 tasks. For me or another programmer, this might be meaningful if these tasks are representative of tasks I or another programmer do. 113 tasks (or even just the 79 differing tasks) are more than we're going to look at in detail in this post, but from looking at the names of the tasks, few to none of them seem relevant to tasks I do at all. And then looking at language, of the tasks that differ, 4 tasks are in a language I often use coding agents for (Rust), and the rest of the tasks are in languages where I don't use coding agents or use them for trivial problems where any model is fine².

The four Rust tasks where results differ are:

Hierarchical evaluation cancellation in Boa (https://deepswe.datacurve.ai/data/v1.1/tasks/boa-hierarchical-evaluation-cancellation), Deterministic multi-key sorting in fd (https://deepswe.datacurve.ai/data/v1.1/tasks/fd-deterministic-multi-key-sorting), Preserve stylesheet-selector structure in oxvg (https://deepswe.datacurve.ai/data/v1.1/tasks/oxvg-structural-selector-preservation), and Trap coredump generation in wasmi (https://deepswe.datacurve.ai/data/v1.1/tasks/wasmi-trap-coredumps). None of these seem all that related to things I use coding agents for, so this is worthless to me.

One of these seems vaguely like something I've done in the past year and the other three don't. We know from looking at individual benchmarks that there's significant variance in results between different benchmarks (for example, in the Optimization 1 benchmark in the last post, we get a vaguely DeepSWE-like model ranking, but in the GameAI we get a Senior SWE-Bench-like ranking, but as we also observed in that post, you can have one benchmark that nominally appears to resemble a task we care about that gives a result that's the opposite of what we see on the actual task, again because variance is very high). Having 1 out of 113 tasks sort of be similar to a task I've done means the DeepSWE benchmark score is meaningless to me personally.

Senior SWE-Bench

Moving on to the other benchmark, Senior SWE-Bench has all of the problems noted above, and it also presents the results in a more misleading way and has the additional issue of doing more subjective grading of results. I don't want to do one of these super long point-by-point teardowns, but to look at one issue with it, to qualify as a "tasteful solve", a solution has to meet multiple criteria, including scoring better than a certain score on a rubric and having a result that isn't >= 2x the length of a reference result.

Arbitrary and subjective scoring function

Without even looking at it more deeply, we already see this is a classic https://danluu.com/discontinuities/ situation. The benchmark has these continuous scores and then it introduces threshold effects by requiring a strict cutoff. From what I've seen, this kind of thing is often done because it makes things simpler, but if you believe the underlying criteria are important, in general, you often don't want to say that a score of X is a pass and a score of X-epsilon is a failure. Instead, the scores should be aggregated in some non-discontinuous way. I think there's often a hesitancy to do this because trying to write down a formula for this often makes it obvious that the weights are arbitrary and the score is meaningless. We probably know we don't want to give up to N extra score for a 1 LOC solution if the reference is R LOC, so we need some function that will cap the value there. Maybe we can cap the bonus at 2 by doing something like (2R)/(R+N). Maybe this doesn't penalize large functions enough, so we should switch to (2R^2)/(R^2+N^2). It might be easier to see the behavior of this if we write it as 1+tanh(ln(R/N)), so you can mentally substitute that if you prefer. We then need to combine this with the other scores, so we need to add at least M-1 of the M formulas so we have some relative weighting for them.

This would clearly be an arbitrary formula that's hard to justify. But the actual formula used has these discontinuities is another completely arbitrary function, but with worse properies that make it even harder to justify! It's just that whoever's writing it down doesn't have to think of it as a formula so they can avoid thinking about how arbitrary it is.

Threshold effects

If we look specifically at the LOC measure as defined by Senior SWE-Bench, of course we see threshold effects. For example, on https://senior-swe-bench.snorkel.ai/tasks/paperless-ngx-perf-workflow-queries, GLM-5.2 scores tasteful at 121 LOC vs. 61 for the reference. If there was one single LOC more, it would be 122, or double, which would cause GLM-5.2 to fail instead of pass. We can also see from the link that the benchmark was run once per condition. As anyone who's used LLMs knows and as we saw in the last post, there's tremendous variance between runs (quite often, there is commonly variance between runs than across different models and effort levels, which we observed in the last post), which already makes a single run not very meaningful when scored with some kind of reasonable continuous score. When noisy metrics like this then have information removed with these threshold effects, the result becomes even less meaningful.

That isn't even a particularly problematic benchmark with respect to the LOC score. plausible-fix-top-pages-comparison is worse because the reference solution is 1 LOC (since addition and deletion each count as 1 LOC, this is scored as 2 LOC). This makes the maximum size of a tasteful solve 3 LOC; if additions and deletions both happen, this would have to be 1 LOC deleted and 2 added or vice versa.

Code quality

If we look at the actual results, they don't make sense. We can see that, on this task, Opus 4.8 scores "tasteful" while Opus 4.7 and Fable 5 don't. If we look at the actual diffs and compare them to the reference solution, we find the following (note that only changes to the actual code count for the LOC criteria; test LOC, comments, etc., do not count).

Reference

  --- a/lib/plausible_web/controllers/api/stats_controller.ex
  +++ b/lib/plausible_web/controllers/api/stats_controller.ex
  @@ -723,7 +723,7 @@ defmodule PlausibleWeb.Api.StatsController do
       else
         json(conn, %{
           results: pages,
  -        meta: Map.merge(meta, Stats.Breakdown.formatted_date_ranges(query)),
  +        meta: Map.new(meta.values) |> Map.merge(Stats.Breakdown.formatted_date_ranges(query)),
           skip_imported_reason: meta[:imports_skip_reason]
         })
       end

Opus 4.8 (pass)

  --- CHANGELOG.md                                                                                                                                                                                         
  +++ CHANGELOG.md                                                                                                                                                                                         
  +- Fixed blank comparison dates in row tooltips on the Top Pages report                                                                                                                                  
                                                  
  --- lib/plausible_web/controllers/api/stats_controller.ex
  +++ lib/plausible_web/controllers/api/stats_controller.ex
  -        meta: Map.merge(meta, Stats.Breakdown.formatted_date_ranges(query)),                      
  +        meta: Map.merge(Map.new(meta), Stats.Breakdown.formatted_date_ranges(query)),
                                                  
  --- test/plausible_web/controllers/api/stats_controller/pages_test.exs
  +++ test/plausible_web/controllers/api/stats_controller/pages_test.exs                     
  +      assert json_response(conn, 200)["meta"] == %{                                                                                                                                                     
  +               "date_range_label" => "2 Jan 2021",                                                
  +               "comparison_date_range_label" => "1 Jan 2021"                                                                                                                                            
  +             }                                                                                    

Opus 4.7 (fail)

  --- lib/plausible_web/controllers/api/stats_controller.ex                                          
  +++ lib/plausible_web/controllers/api/stats_controller.ex                                                                                                                                                
  -        meta: Map.merge(meta, Stats.Breakdown.formatted_date_ranges(query)),
  +        meta:                                                                                                                                                                                           
  +          meta.values                                                                                                                                                                                   
  +          |> Map.new()                                                                                                                                                                                  
  +          |> Map.merge(Stats.Breakdown.formatted_date_ranges(query)),                                                                                                                                   
                                                                                                                                                                                                           
  --- test/plausible_web/controllers/api/stats_controller/pages_test.exs
  +++ test/plausible_web/controllers/api/stats_controller/pages_test.exs                                                                                                                                   
  +      assert json_response(conn, 200)["meta"]["date_range_label"] == "2 Jan 2021"
  +      assert json_response(conn, 200)["meta"]["comparison_date_range_label"] == "1 Jan 2021"   

Fable 5 (fail)

  --- lib/plausible/stats/breakdown.ex                                                               
  +++ lib/plausible/stats/breakdown.ex                                                               
       %{                                                                                            
         results: build_breakdown_result(results, query_with_metrics, metrics),
  -      meta: meta
  +      # `meta` is a `Jason.OrderedObject` - convert it to a plain map so that
  +      # callers can safely `Map.merge/2` extra fields into it. Merging into the
  +      # struct would add keys outside of its `values` field, which the JSON
  +      # encoder for `Jason.OrderedObject` silently ignores.
  +      meta: Map.new(meta.values)
       }

  --- lib/plausible_web/controllers/api/external_stats_controller.ex
  +++ lib/plausible_web/controllers/api/external_stats_controller.ex
  -  defp maybe_add_warning(payload, %Jason.OrderedObject{} = meta) do
  +  defp maybe_add_warning(payload, meta) do

  --- test/plausible_web/controllers/api/stats_controller/pages_test.exs
  +++ test/plausible_web/controllers/api/stats_controller/pages_test.exs
  +      assert json_response(conn, 200)["meta"] == %{
  +               "date_range_label" => "2 Jan 2021",
  +               "comparison_date_range_label" => "1 Jan 2021"
  +             }

I'm not an Elixir programmer, nor am I familiar with this codebase, but just looking at the code, the failing, "non-tasteful" Opus 4.7 solution looks semantically identical to the reference solution. The only difference is that the pipeline was expanded onto multiple lines for readability. Without knowing Elixir, it strikes me as absurd to fail this based on "tastefulness".

I've used other languages where you commonly use a pipe operator like this (such as F# or R with tidyverse) and I don't believe I've ever run into anyone who would reject the Opus 4.7 change for being "untasteful" (unless there was a style guide which had strict rules about what should be expanded into multiple lines and what shouldn't, but if that were the case, an autoformatter should deal with this and the formatting of the solution is irrelevant).

The Fable 5 solution should arguably be rejected for expanding the scope of the change too much but, whether or not it should be rejected for other reasons, it seems wrong to additionally reject it as "untasteful" due to the length.

Grader variance

LLM variance also applies to the grading itself. Of course it must be the case that if we feed the results of one single run to an LLM grader multiple times, we'll get different scores for the same reason we often get wildly different results when we ask an LLM to solve the same problem multiple times. I tried having my friendly neighborhood coding agent re-run grading 10 times for each condition that GPT-5.6 Sol and Opus 4.8 were tested under (codex tells me grading was run using Sonnet 4.6, so it re-ran with that). The expected LLM-graded tastefulness result flips from the official result 23% of the time when using the same model and effort level (in terms of sub-results, relative taste flips in 32% of cases, practice alignment flips in 5% of cases, and task rubric flips in 3% of cases). If we instead look at the fraction of the time the official result differed from the typical/median result, there's a 21% difference overall (27% for relative taste, 3% for practice alignment, and 2% for task rubric). The overall flip rate is lower than the individual flip rate because, in some cases, a result flipped from tasteful to untasteful in a sub-score when the overall score was already untasteful.

Just to be clear, this is not run-to-run variance. This is the variance from using LLM grading on a single run, which, across the publicly available GPT-5.6 Sol and Opus 4.8 benchmarks, appears to give an incorrect result about 20% of the time (if we assume what's being measured is correct and reasonable to measure in the first place and tha the most likely Sonnet score is the correct score).

Of course we get different results if we grade with different models as well. If we re-grade with GPT-5.6 Sol instead of Sonnet 4.6, the number of solutions that are judged to be tasteful is cut by more than half for both models. Is that more or less accurate? Who knows?

Overall validity

Sometimes, you can look at a benchmark and say that, while some individual results are wrong, in aggregate, the noise cancels out and the overall results make sense. I don't think that's the case here. I've seen a lot of people passing Senior SWE-Bench around, seemingly because it purports to give realistic problems and score them in a reasonable way. We already noted that, prima facie, the results don't seem plausible, and, that looking at the methodology supports the prima facie thought that the result is not meaningful³.

The presentation of results also leaves something to be desired. On a Slack I'm on, someone linked to this, which shows a preview snippet with the following:

• Claude Fable 5: 29.1%
• Claude Opus 4.8: 25.0%
• GPT-5.6 Sol: 24.4%

They gave an approving comment, saying this was more realistic than other benchmarks (referring to one of the many benchmarks that put GPT-5.5 ahead of Opus 4.8). If you actually look at the results, it's clear that the difference between 25.0% and 24.4% is pretty much meaningless, but the results are presented as if these are meaningful differences. Although the page makes it clear that GPT-5.6 Sol is, as measured, much cheaper than Opus 4.8, most discussions I've seen that refer to Senior SWE-Bench elide this and mention only the headline result. It also seems odd that the headline result uses max for Fable, Opus, and Sonnet, but xhigh for GPT-5.6, GPT-5.5, and GPT-5.4.

31. Cold weather tire performance

Although people commonly say that all-season tires become hard (for some reason, the phrasing that they become as hard as "hockey pucks" is common) at 7C / 45F and have poor grip, there's no benchmark! This has been a common theme in this series: people repeating a claim that has no apparent basis in a measurement⁴.

Luckily, as we discussed in this post on platforms and monetization, Jonathan Benson has been able to monetize in-depth explorations on tires, resulting in a never-before seen level of detail in public tire benchmarks. He tested how well different kinds of tires perform at different temperatures and in different conditions. I'm sure tire manufacturers have all sorts of tests like this but, AFAIK, this hadn't been done publicly in a comprehensive way before (hmm, this doesn't seem so different from public benchmarks of coding agents).

In Benson's testing, he finds that, in dry conditions, summer tires have the best grip down to 0C / 32 F (he didn't test colder conditions), followed by all-seasons, with winter being worse than both summer tires and all-seasons by a fairly large margin. In wet conditions, he only tested down to 2C since, at 0C, you have icy conditions and not just wet conditions. The ranking is a bit different since all-season tires wildly outperformed summer tires at 2C in the wet, but summer tires still outperformed winter tires.

Note that, in the video, what Benson calls a winter tire is a UHP winter tire, which I very rarely see people using in the US or Canada (although it's what I use for a winter tire since that makes sense for the local conditions where I live). What he calls a "nordic" tire is what most people use for a winter tire even locally here and everywhere else I've lived, all of which are locations where that kind of tire doesn't really make sense unless you're spending a lot of time driving into the mountains (and even then, it's probably still not the right choice for most people where I've lived) or you spend a lot of time driving on ice. But even if you look at the UHP winter tire results compared to all-seasons, it's still true that all-seasons are better in dry or wet conditions above 0C, although the magnitude of the difference is much smaller than it is relative to the "nordic" winter tires that most people in the US use (I think the terminology he's using might be more common in Europe?).

Of course different tires will perform differently and we'd see some variation in results with different tires, and of course there are many conditions where it's better to have winter tires than all-season tires or summer tires, but the idea that all-season tires become too hard to grip and you have to have winter tires for cold alone is clearly false.

Who cares about tires?

BTW, if you're wondering why you should care about tires at all, on average, motor vehicle accidents are a fairly major cause of death and, if you look at the impact of velocity on accident severity, it's pretty significant, so it stands to reason that having tires that let you brake more rapidly or corner a little better and maybe avoid or deflect the accident a bit, it's reasonable to think this would have a substantial impact on accident severity. I don't think this is the kind of thing there's really good data for (it would be very hard to run the randomized trial and observational data is going to be highly confounded, in general). But, as part of an analysis I did last year, I tried to find the relationship between HIC and velocity in actual crash test data. Surprisingly to me, I couldn't find a paper that had done this (I did find some papers that could serve as exercises for this series, though), but a straightforward analysis put the relationship as roughly to the fourth power. I should really write that up into a post that's like this other post on crash testing, but specifically about the HIC and concussion risk of various vehicles! Anyway, I try to drive a car with the right tires for the locale because it seems like that's plausibly one of the higher impact interventions I could do for my own safety per dollar and/or effort. But I've never gotten close to a situation where my really good tires have made a difference and someone who's going to try to find the right tires for safety reasons may be less likely to get into an accident in the first place, so this may just be a silly hobby that doesn't matter at all.

More problems in benchmarking and evals

If you liked this post. this is part of a series of exercises on benchmarking, evals, and experimental design (1, 2, 3, 4, 5, 6)⁵.

Thanks to Peter Geoghegan, Aaron Levin, Luke Burton, Em Chu, Jamie Brandon, Yossi Kreinin, Jeshua Smith, and Ikhwan Lee, for comments/corrections/discussion.

Appendix: more on disk performance

Here are some follow-up comments by Peter Geoghegan who, unlike me, actually knows something about disk performance:

I've seen significant variation in performance across more or less comparable SSDs for certain access patterns. This is likely due to FTL/firmware level differences. Evidently some SSDs are much better than others at reading backwards sequentially, independent of OS read ahead (with direct IO). Here's a blog post about it from the person I'm working with on IO prefetching for index scans in Postgres: https://vondra.me/posts/fun-and-weirdness-with-ssds.

I'm fairly sure that these things are still opaque to the OS/filesystem. This admittedly-dated LWN.net article provides some justification for this: https://lwn.net/Articles/353411, "The message to file systems developers is "Just trust us" and "Don't worry your pretty little systems programmers' heads about it" whenever we ask for more information on SSD implementation".

I asked Linux hacker Matthew Wilcox about this in 2023. He said that it was about the same, and that if I wanted to account for performance variation for microbenchmarking purposes the best way was still to be very defensive about provisioning, running TRIM regularly, etc.

At one point (I think around 2015), I wrote some code with the intention of turning it into some exercises or a tutorial on CPU performance. It was sort of like the napkin math repo, but much narrower. The idea was that you could have questions like:

1. You have CPU X. If you want to know how fast this loop is, what parameters do you need to know?
2. Given these parameters, how fast should the loop be?

I had the code I wanted for various things but, for some reason, the code I wrote didn't elicit a difference between a DRAM open page access and a closed page access and then I got distracted with other things and didn't end up writing it up. Pre-LLM, doing this kind of thing was fairly time consuming, because to get it right, you have to know enough about what the mechanisms that are in play are and then take some care in writing the code and checking what it does. And then, because I screwed something up and make enough time to debug it, I never ended up writing up the exercises because I didn't want to write it up when there was some kind of mystery that implied that my code had at least one issue.

Anyway, disk is way more complicated and getting good numbers would take a lot more care. With LLMs, I think this would now be doable without it taking a ton of time, but some care would still be necessary.

P.S. The friend of mine mentioned in (29) is Jamie Brandon, who's actively interviewing and looking for work. He's done a fair amount of work on databases (query engines) and streaming systems. His best-known writing is probably Against SQL, but he's also written quite a few other posts I like, such as this analysis of streaming systems consistency bugs. He's mainly looking for a Vancouver-local job or a remote job. If you'd like to talk to him, you can reach him at jamie@scattered-thoughts.net.

This is an archive of Dan Weinreb's comments on Symbolics and Lisp machines.

Rebuttal to Stallman’s Story About The Formation of Symbolics and LMI

Richard Stallman has been telling a story about the origins of the Lisp machine companies, and the effects on the M.I.T. Artificial Intelligence Lab, for many years. He has published it in a book, and in a widely-referenced paper, which you can find at http://www.gnu.org/gnu/rms-lisp.html.

His account is highly biased, and in many places just plain wrong. Here’s my own perspective on what really happened.

Richard Greenblatt’s proposal for a Lisp machine company had two premises. First, there should be no outside investment. This would have been totally unrealistic: a company manufacturing computer hardware needs capital. Second, Greenblatt himself would be the CEO. The other members of the Lisp machine project were extremely dubious of Greenblatt’s ability to run a company. So Greenblatt and the others went their separate ways and set up two companies.

Stallman’s characterization of this as “backstabbing”, and that Symbolics decided not “not have scruples”, is pure hogwash. There was no backstabbing whatsoever. Symbolics was extremely scrupulous. Stallman’s characterization of Symbolics as “looking for ways to destroy” LMI is pure fantasy.

Stallman claims that Symbolics “hired away all the hackers” and that “the AI lab was now helpless” and “nobody had envisioned that the AI lab’s hacker group would be wiped out, but it was” and that Symbolics “wiped out MIT”. First of all, had there been only one Lisp machine company as Stallman would have preferred, exactly the same people would have left the AI lab. Secondly, Symbolics only hired four full-time and one part-time person from the AI lab (see below).

Stallman goes on to say: “So Symbolics came up with a plan. They said to the lab, ‘We will continue making our changes to the system available for you to use, but you can’t put it into the MIT Lisp machine system. Instead, we’ll give you access to Symbolics’ Lisp machine system, and you can run it, but that’s all you can do.’” In other words, software that was developed at Symbolics was not given away for free to LMI. Is that so surprising? Anyway, that wasn’t Symbolics’s “plan”; it was part of the MIT licensing agreement, the very same one that LMI signed. LMI’s changes were all proprietary to LMI, too.

Next, he says: “After a while, I came to the conclusion that it would be best if I didn’t even look at their code. When they made a beta announcement that gave the release notes, I would see what the features were and then implement them. By the time they had a real release, I did too.” First of all, he really was looking at the Symbolics code; we caught him doing it several times. But secondly, even if he hadn’t, it’s a whole lot easier to copy what someone else has already designed than to design it yourself. What he copied were incremental improvements: a new editor command here, a new Lisp utility there. This was a very small fraction of the software development being done at Symbolics.

His characterization of this as “punishing” Symbolics is silly. What he did never made any difference to Symbolics. In real life, Symbolics was rarely competing with LMI for sales. LMI’s existence had very little to do with Symbolics’s bottom line.

And while I’m setting the record straight, the original (TECO-based) Emacs was created and designed by Guy L. Steele Jr. and David Moon. After they had it working, and it had become established as the standard text editor at the AI lab, Stallman took over its maintenance.

Here is the list of Symbolics founders. Note that Bruce Edwards and I had worked at the MIT AI Lab previously, but had already left to go to other jobs before Symbolics started. Henry Baker was not one of the “hackers” of which Stallman speaks.

• Robert Adams (original CEO, California)
• Russell Noftsker (CEO thereafter)
• Minoru Tonai (CFO, California)
• John Kulp (from MIT Plasma Physics Lab)
• Tom Knight (from MIT AI Lab)
• Jack Holloway (from MIT AI Lab)
• David Moon (half-time as MIT AI Lab)
• Dan Weinreb (from Lawrence Livermore Labs)
• Howard Cannon (from MIT AI Lab)
• Mike McMahon (from MIT AI Lab)
• Jim Kulp (from IIASA, Vienna)
• Bruce Edwards (from IIASA, Vienna)
• Bernie Greenberg (from Honeywell CISL)
• Clark Baker (from MIT LCS)
• Chris Terman (from MIT LCS)
• John Blankenbaker (hardware engineer, California)
• Bob Williams (hardware engineer, California)
• Bob South (hardware engineer, California)
• Henry Baker (from MIT)
• Dave Dyer (from USC ISI)

Why Did Symbolics Fail?

In a comment on a previous blog entry, I was asked why Symbolics failed. The following is oversimplified but should be good enough. My old friends are very welcome to post comments with corrections or additions, and of course everyone is invited to post comments.

First, remember that at the time Symbolics started around 1980, serious computer users used timesharing systems. The very idea of a whole computer for one person was audacious, almost heretical. Every computer company (think Prime, Data General, DEC) did their own hardware and their own software suite. There were no PCs’, no Mac’s, no workstations. At the MIT Artificial Intelligence Lab, fifteen researchers shared a computer with a .001 GHz CPU and .002 GB of main memory.

Symbolics sold to two kinds of customers, which I’ll call primary and secondary. The primary customers used Lisp machines as software development environments. The original target market was the MIT AI Lab itself, followed by similar institutions: universities, corporate research labs, and so on. The secondary customers used Lisp machines to run applications that had been written by some other party.

We had great success amongst primary customers. I think we could have found a lot more of them if our marketing had been better. For example, did you know that Symbolics had a world-class software development environment for Fortran, C, Ada, and other popular languages, with amazing semantics-understanding in the editor, a powerful debugger, the ability for the languages to call each other, and so on? We put a lot of work into those, but they were never publicized or advertised.

But we knew that the only way to really succeed was to develop the secondary market. ICAD made an advanced constraint-based computer-aided design system that ran only on Symbolics machines. Sadly, they were the only company that ever did. Why?

The world changed out from under us very quickly. The new “workstation” category of computer appeared: the Suns and Apollos and so on. New technology for implementing Lisp was invented that allowed good Lisp implementations to run on conventional hardware; not quite as good as ours, but good enough for most purposes. So the real value-added of our special Lisp architecture was suddenly diminished. A large body of useful Unix software came to exist and was portable amongst the Unix workstations: no longer did each vendor have to develop a whole software suite. And the workstation vendors got to piggyback on the ever-faster, ever-cheaper CPU’s being made by Intel and Motorola and IBM, with whom it was hard for Symbolics to keep up. We at Symbolics were slow to acknowledge this. We believed our own “dogma” even as it became less true. It was embedded in our corporate culture. If you disputed it, your co-workers felt that you “just didn’t get it” and weren’t a member of the clan, so to speak. This stifled objective analysis. (This is a very easy problem to fall into — don’t let it happen to you!)

The secondary market often had reasons that they needed to use workstation (and, later, PC) hardware. Often they needed to interact with other software that didn’t run under Symbolics. Or they wanted to share the cost of the hardware with other applications that didn’t run on Symbolics. Symbolics machines came to be seen as “special-purpose hardware” as compared to “general-purpose” Unix workstations (and later Windows PCs). They cost a lot, but could not be used for the wider and wider range of available Unix software. Very few vendors wanted to make a product that could only run on “special-purpose hardware”. (Thanks, ICAD; we love you!)

Also, a lot of Symbolics sales were based on the promise of rule-based expert systems, of which the early examples were written in Lisp. Rule-based expert systems are a fine thing, and are widely used today (but often not in Lisp). But they were tremendously over-hyped by certain academics and by their industry, resulting in a huge backlash around 1988. “Artificial Intelligence” fell out of favor; the “AI Winter” had arrived.

(Symbolics did launch its own effort to produce a Lisp for the PC, called CLOE, and also partnered with other Lisp companies, particularly Gold Hill, so that customers could develop on a Symbolics and deploy on a conventional machine. We were not totally stupid. The bottom line is that interest in Lisp just declined too much.)

Meanwhile, back at Symbolics, there were huge internal management conflicts, leading to the resignation of much of top management, who were replaced by the board of directors with new CEO’s who did not do a good job, and did not have the vision to see what was happening. Symbolics signed long-term leases on big new offices and a new factory, anticipating growth that did not come, and were unable to sublease the properties due to office-space gluts, which drained a great deal of money. There were rounds of layoffs. More and more of us realized what was going on, and that Symbolics was not reacting. Having created an object-oriented database system for Lisp called Statice, I left in 1988 with several co-workers to form Object Design, Inc., to make an object-oriented database system for the brand-new mainstream object-oriented language, C++. (The company was very successful and currently exists as the ObjectStore division of Progress Software (www.objectstore.com). I’m looking forward to the 20th-year reunion party next summer.)

Symbolics did try to deal with the situation, first by making Lisp machines that were plug-in boards that could be connected to conventional computers. One problem is that they kept betting on the wrong horses. The MacIvory was a Symbolics Ivory chip (yes, we made our own CPU chips) that plugged into the NuBus (oops, long-since gone) on a Macintosh (oops, not the leading platform). Later, they finally gave up on competing with the big chip makers, and made a plug-in board using a fast chip from a major manufacturer: the DEC Alpha architecture (oops, killed by HP/Compaq, should have used the Intel). By this time it was all too little, too late.

The person who commented on the previous blog entry referred by to an MIT Masters thesis by one Eve Philips (see http://www.sts.tu-harburg.de/~r.f.moeller/symbolics-info/ai-business.pdf) called “If It Works, It’s Not AI: A Commercial Look at Artificial Intelligence Startups”. This is the first I’ve heard of it, but evidently she got help from Tom Knight, who is one of the other Symbolics co-founders and knows as much or more about Symbolics history than I. Let’s see what she says.

Hey, this looks great. Well worth reading! She definitely knows what she’s talking about, and it’s fun to read. It brings back a lot of old memories for me. If you ever want to start a company, you can learn a lot from reading “war stories” like the ones herein.

Here are some comments, as I read along. Much of the paper is about the AI software vendors, but their fate had a strong effect on Symbolics.

Oh, of course, the fact that DARPA cut funding in the late 80’s is very important. Many of the Symbolics primary-market customers had been ultimately funded by DARPA research grants.

Yes, there were some exciting successes with rule-based expert systems. Inference’s “Authorizer’s Assistant” for American Express, to help the people who talk to you on the phone to make sure you’re not using an AmEx card fraudulently, ran on Symbolics machines. I learn here that it was credited with a 45-67% internal rate of return on investment, which is very impressive.

The paper has an anachronism: “Few large software firms providing languages (namely Microsoft) provide any kind of Lisp support.” Microsoft’s dominance was years away when these events happened. For example, remember that the first viable Windows O/S, release 3.1, came out in in 1990. But her overall point is valid.

She says “There was a large amount of hubris, not completely unwarranted, by the AI community that Lisp would change the way computer systems everywhere ran.” That is absolutely true. It’s not as wrong as it sounds: many ideas from Lisp have become mainstream, particularly managed (garbage-collected) storage, and Lisp gets some of the credit for the acceptance of object-oriented programming. I have no question that Lisp was a huge influence on Java, and thence on C#. Note that the Microsoft Common Language Runtime technology is currently under the direction of the awesome Patrick Dussud, who was the major Lisp wizard from the third MIT-Lisp-machine company, Texas Instruments.

But back then we really believed in Lisp. We felt only scorn for anyone trying to write an expert system in C; that was part of our corporate culture. We really did think Lisp would “change the world” analogously to the way “sixties-era” people thought the world could be changed by “peace, love, and joy”. Sorry, it’s not that easy.

Which reminds me, I cannot recommend highly enough the book “Patterns of Software: Tales from the Software Community” by Richard Gabriel (http://www.dreamsongs.com/Files/PatternsOfSoftware.pdf) regarding the process by which technology moves from the lab to the market. Gabriel is one of the five main Common Lisp designers (along with Guy Steele, Scott Fahlman, David Moon, and myself), but the key points here go way beyond Lisp. This is the culmination of the series of papers by Gabriel starting with his original “Worse is Better”. Here the ideas are far more developed. His insights are unique and extremely persuasive.

OK, back to Eve Philips: at chapter 5 she describes “The AI Hardware Industry”, starting with the MIT Lisp machine. Does she get it right? Well, she says “14 AI lab hackers joined them”; see my previous post about this figure, but in context this is a very minor issue. The rest of the story is right on. (She even mentions the real-estate problems I pointed out above!) She amply demonstrates the weaknesses of Symbolics management and marketing, too. This is an excellent piece of work.

Symbolics was tremendously fun. We had a lot of success for a while, and went public. My colleagues were some of the skilled and likable technical people you could ever hope to work with. I learned a lot from them. I wouldn’t have missed it for the world.

After I left, I thought I’d never see Lisp again. But now I find myself at ITA Software, where we’re writing a huge, complex transaction-processing system (a new airline reservation system, initially for Air Canada), whose core is in Common Lisp. We almost certainly have the largest team of Common Lisp programmers in the world. Our development environment is OK, but I really wish I had a Lisp machine again.

More about Why Symbolics Failed

I just came across “Symbolics, Inc: A failure of heterogeneous engineering” by Alvin Graylin, Kari Anne Hoir Kjolaas, Jonathan Loflin, and Jimmie D. Walker III (it doesn’t say with whom they are affiliated, and there is no date), at http://www.sts.tu-harburg.de/~r.f.moeller/symbolics-info/Symbolics.pdf

This is an excellent paper, and if you are interested in what happened to Symbolics, it’s a must-read.

The paper’s thesis is based on a concept called “heterogeneous engineering”, but it’s hard to see what they mean by that other than “running a company well”. They have fancy ways of saying that you can’t just do technology, you have to do marketing and sales and finance and so on, which is rather obvious. They are quite right about the wide diversity of feelings about the long-term vision of Symbolics, and I should have mentioned that in my essay as being one of the biggest problems with Symbolics. The random directions of R&D, often not co-ordinated with the rest of the company, are well-described here (they had good sources, including lots of characteristically, harshly honest email from Dave Moon). The separation between the software part of the company in Cambridge, MA and the hardware part of the company in Woodland Hills (later Chatsworth) CA was also a real problem. They say “Once funds were available, Symbolics was spending money like a lottery winner with new-found riches” and that’s absolutely correct. Feature creep was indeed extremely rampant. The paper also has financial figures for Symbolics, which are quite interesting and revealing, showing a steady rise through 1986, followed by falling revenues and negative earnings from 1987 to 1989.

Here are some points I dispute. They say “During the years of growth Symbolics had been searching for a CEO”, leading up to the hiring of Brian Sear. I am pretty sure that only happened when the trouble started. I disagree with the statement by Brian Sear that we didn’t take care of our current customers; we really did work hard at that, and I think that’s one of the reasons so many former Symbolics customers are so nostalgic. I don’t think Russell is right that “many of the Symbolics machines were purchased by researchers funded through the Star Wars program”, a point which they repeat many times. However, many were funded through DARPA, and if you just substitute that for all the claims about “Star Wars”, then what they say is right. The claim that “the proliferation of LISP machines may have exceeded the proliferation of LISP programmers” is hyperbole. It’s not true that nobody thought about a broader market than the researchers; rather, we intended to sell to value-added resellers (VAR’s) and original equipment manufacturers (OEM’s). The phrase “VARs and OEMs” was practically a mantra. Unfortunately, we only managed to do it once (ICAD). While they are right that Sun machines “could be used for many other applications”, the interesting point is the reason for that: why did Sun’s have many applications available? The rise of Unix as a portable platform, which was a new concept at the time, had a lot to do with it, as well as Sun’s prices. They don’t consider why Apollo failed.

There’s plenty more. To the authors, wherever you are: thank you very much!

This is an archive of some posts in a forum thread titled "Beware of Bioware" in a now defunct forum, with comments from that forum as well as blog comments from a now defunct blog that archived that made the first attempt to archive this content. The original posts were deleted shortly after being posted, replaced with "big scary company vs. li'l ol' me."

Although the comments below seem to be about Bioware's main studio in Edmonton, I knew someone at Bioware Austin during the time period under discussion, which is how I learned about the term "sympathy crunch", where you're required to be at the office because other teams are "crunching". I'd never heard of this concept before, so I looked it up and found the following thread around 2008 or so.

Searching for "sympathy crunch" today, in 2024, doesn't return many hits. One of the few hits is a 2011 blog post by a former director at BioWare titled "Loving the Crunch", which has this to say about sympathy crunches:

If you find yourself working sympathy crunch, in that even though you have no bugs of your own to take care of, don’t be pissed off about it. Play test the game you made! And enjoy it for what it is, something you contributed to. And if that’s not enough to make you happy then be satisfied that every bug you send to one of your co-workers will make them more miserable. (Though do try and be constructive.)

Another one of the few hits is a 2013 recruiting marketing blog post on Bioware blog, where a developer notes that "We are clearly moving away from the concept of 'sympathy crunch'. In the 2008 thread below, there's a heated debate over the promise by leadership that sympathy crunch had been abolished was kept or not. Even if you ignore the comments from the person I knew at Bioware, these later comments from Bioware employees, especially the recruiting marketing post in 2013, seem to indicate that sympathy crunch was not abolished until well after 2008.

Milez5858

EA gets a lot of the grief for their employment history.

For anyone considering work at Bioware, beware of them as well.

They use seriously cult like tactics to keep their employees towing the company line, but don't be fooled. The second you don't tow that line you'll be walked out the doors.

They love out of country workers because they don't understand the Canadian labour laws. They continually fire people with out warning. This is illegal in Canada. You must warn people of performance problems and give them a certain amount of warnings before you are allowed to fire someone.

They are smarter about it than EA by offering food and free ice cream and other on site amenities, but it all adds up to a lot of extra hours with no extra pay.

BTW you could say my post is somewhat personal, but I've not worked for Bioware. I have several friends that do. Three have been walked out the door in the last year for refusing to work more than the 40 hours they are paid for and wanting to spend time with their wives and kids.

The friends I have remaining there are from out of country and feel as though they are somewhat trapped. They are unhappy but will only admit it behind very closed doors because they have it in their head they will get black listed or something.

I'm an outside observer. I get paid more than these poor kids, and I only work about 35 hours a week. I've always put MY life ahead of my employers, but work very hard and dedicated at my job. When I see what in my opinion amounts to cult like mind control over these young men who are enamoured by the legend of Ray and Greg, the founders of bioware, I'm almost sickened.

I used to think it would be cool to work in the gaming industry, and now I'm just happy as hell I'm not in it.

I will certainly be pointing them to this site as a resource and hope, that like any other entertainment industry, they get organized in some fashion. It's absolutely dehumanizing what this industry does to people.

Hell is happy?

And, didn't EA buy BioWare?

Just asking, not complaining. Welcome aboard!

Anguirel

Yes, Bioware and Pandemic were bought by EA. However, it sounds like this started well before that acquisition. It actually sounds more like what amounts to a Cult of Personality (such as you see at Blizzard, Maxis, id, or Ion Storm) where a single person or a few people have such a huge reputation that they can get a more-or-less unlimited supply of reasonably good new hires -- and thus, someone (possibly someone in between said person and the average worker) takes advantage and pushes the employees much harder than they should.

In some cases the cults that build up around certain individuals insulates them from bad working conditions (I've heard Maxis enjoyed that happy fate while Will Wright was there, keeping the people inside in much better conditions than the remainder of EA), but in many cases it results in an attitude of "if you don't like it, we can get any number of people to replace you." Which is what EA certainly had for a long time, and several other studios still have, though the people who work at them tend to be quieter about it (and I don't think any other studios ever got to EA's legendary status of continuous crunch).

Yes, these things were happening well ahead of the EA purchase of Bioware.

You are exactly accurate about the Cult of Personality thing. People think that Ray and Greg are looking out for them. Bioware Pandemic just sold for nearly a billion dollars. People are marked for assination for far smaller stakes. Can anyone really believe that the owners are in there saying... "ya know.. I can't accept your billion dollars unless I know the employees are really well taken care of". It defies logic.

I suspect it will just get worse. Now people that have been forced to leave the company are also being told the the MUST sell their stocks back to the company.

I don't know enough about it to say if it's legal or not, but it sure sounds fishy to me. Again I've recommended to people that they check with a lawyer first, but nobody wants any more hastle than they already have. Unfortunately it's this attitude that keeps the gaming industry from getting organized.

I would love to be able to say this sort of putrid intimidation is anomalous, but that would just be the utterest of untruths plaguing the industry. Maybe we should extract this ubiquitous haughtiness from the development process, I'm crazy enough to believe this can happen without the U-word.

The truth is life at Bioware is not as bad and as bad as implied in this article. But mostly not as bad.

The original article states that Bioware uses cult tactics. I dont know what cult tactics are so I cant give a simple answer but I know that Bioware uses traditional tactics to make for good morale. They give you the free breakfast. They bring you dinner if you are working overtime. They give out Oilers tickets or tickets to theatre or gokarts and the like. They let you wander away from your desk for an hour to go to the lunch room and take a nap on the sofa or play video games. Or they let you leave to run errands or go out for an hour for coffee. They also have company meetings where they highlight the development of the various projects ongoing. On this last one some think its a great way to keep up on other projects while some think its just a way to keep employees excited about everything. Is any of this a cult tactic?

Bioware is notoriously loyal. And the managers are notoriously wimpy and avoid confrontation. There isnt a way to emphasise this enough. In fact people joke that they havent done good work in months and yet they receive a strong review and a raise or more stock options. Getting fired as a fulltime employee from Bioware is a shocking rare event that there has been company meetings or emails sent out to explain the firing. Employees are given so many chances to get it right when they do get a bad review. This is all different for contract employees. A contract employee who sucks wont be fired but they will have their contract not renewed. A good contract employee is always offered an opening for fulltime (since contract employees do get overtime and making them fulltime saves money) or if there is none has their contract renewed.

I dont know much about HR so I dont know about the hiring tactics but I can agree that a lot of employees come from around the world or outside of the Edmonton area. It was always assumed that they couldnt find good talent around Edmonton. I cant comment much more than that because I dont know. I know there are lots of recruiting drives all over.

Hours are definitely a problem and I can agree whole hearted:

Some think it gets better each project cycle but its just transposed. In the early days the staff might work 30 to 40 hour weeks for a year or two and then come to the end and realize there was too much to be done. They spend the last few months working at least double the hours. In later projects things were more controlled by project managers and producers and it turned into what some call death crunch or death marches. Employees start working 50 hour weeks a year or two before ship. It isnt much extra hours and noone complains much but there are problems if an employee wants to make plans and never knows if she has to work or not. Managers are good about making sure employees can take time off and get lots of extra time off as compensation for the work but employees are still asked a lot of them.

When the time comes closer to release the employees have their hours scaled up more and more. It might start as 9-9 on Tuesday and Thursday, and then become 9-9 Monday until Thursday. Then it's Saturday 10-4. Then it's 9-9 Friday nights too. Then it's 9-5 Saturday. And in desperate times they even say maybe 12-4 on Sunday.

Morale gets low when employees think the game is awful and they cant get it done right. Thats when management tells the staff that they have decided to not ship the game until it is done and that they are extending the release date. This is good for the title but still hurts morale when employees think of having to work so much longer when they were working so hard to make a date. For example to use the most recent title Mass Effect employees were told the game would ship in Christmas of 2006. Then it was pushes to February of 2007 and then later spring and then June. But we know the game didnt get shipped until November. That does wear on employees.

Each time it gets pushed back the management cuts hours for a few weeks or give out breaks of a few extra days off or a four days weekend to recharge employees. Plus people say "in the old days we worked 90 hours or 100 or more. Now its only 50 or 60 or maybe in rare times sometimes 70 so this is great." which is meant to make you remember that you are making a game and should be happy to hang out at Bioware for only 50 or 60 hours a week to make “the best games ever”.

After game is shipped people take long breaks weeks at a time. Then they slowly ease back into it. They get maybe 20 or 30 hours of work assigned per week. This can go on for months before employee returns to regular 40 hour weeks. And that happens for many months or a year before the project pushes for release and the cycle starts again.

This is not an indictment of Bioware. All companies in video gaming do this. It's unfair to point at Bioware as any exception but a good one to me.

People leave all the time for these reasons. More have left in the last year. Maybe two years. Maybe three. Im not sure. But Bioware hires so many people and the ones who leave are generally not as good as the ones who are hired so it works out. Many people in Bioware wish more people would leave. Maybe with less dead weight since no one gets fired ever there could be a stronger staff who works more efficiently.

When EA Spouse was out everyone at Bioware got curious about it. But then the reports about what EA Spouse's husband was working and the situations he was put into and everyone at Bioware realised that they had nothing anywhere as close to as bad as what that was. Bioware employees enjoy comfort and support by managers and long projects but not 100 hour weeks. And some employees do manage to hold on to 9-5 for very long stretches if they can get their work done to highest standards.

But still people hoped that the industry in general would improve. Many people at Bioware would be thrilled to have nothing else change other than to never have to work more than 40 or 45 hours. But also many people at Bioware are workaholics who would never work less than 50 or 60 and they always create a dangerous precedent and control the pace unfairly.

Everyone at Bioware is aware that EA owns them now but no one is more thoughtful about it. Nothing has changed. Life is the same in every way except for more money. Its easy to forget that Bioware was ever bought by EA because the culture is unchanged and no one from EA is coming in and yelling about how things have to be changed. Thats kind of amazing considering Bioware doesnt make really big selling titles and probably deserves someone like EA coming in and saying this is how to do it. Bioware titles eventually after a year or two sell a million or two m but they never have that 5 m in the first month kind of release that the big titles get and that Bioware sorely wants.

If you want to work video games you are going to work lots of hours no matter where you go but Bioware is a great place to do it because they do treat you well. Many people leave Bioware and write back to say they regret it. Some come back. Some also do find a better life elsewhere but say that Bioware life is good too and that they miss many facets of it. I think more people leave Bioware to get away from Deadmonton then any other reason!!

Bioware censoring that article if they did isnt surprising to me because they are very controlling of their image. They only want positive talk about them and want to protect fragile egos and morale of the employee staff. Censoring bad publicity doesnt make the bad publicity true. Bioware just doesnt want that out there.

I've worked my share of crunches (over almost 400 hours in three months during summer) on various projects. My takeaway from that is:

1) Don't be an ass about it. If you need to crunch, admit what the reason is and create a sensible plan for the crunch.

People will take their free time any way they can. Crunches that last over two weeks are too much without breaks in-between and lead to more errors than actual work being done.

2) Realize that full day's job has about average 5-6 hours of actual work that benefits the company. With crunch, you can have people in the office for 12+ hours a day, but the additional hours don't really pay off that well in comparison.

3) Pretty much every developer I know is very savvy with the industry and how it operates. Most of them put their family and life above work and wouldn't hesitate to resign in a minute if the crunch or the company seems unfair or badly managed. Again, don't be an ass about the crunch.

4) I don't want to spend years and make a shit game. It's a waste of my life and time. I'll crunch for you if you plan it with a brain in the head. If you don't, I'll do something more relevant with my life.

What anonymous posts about Bioware sounds very much like normal circumstances and I'd be willing to work in a company like that. I want to wander away from my desk to play a demo or whatever and I like people trusting me that yes, I will do my tasks by the deadline. In fact, I think that's how every game company should operate. I'm glad I haven't experienced it any other way yet during the years.

While those kinds of hours may be typical or expected, they are in no way excusable. Companies that ask people to work 60 hours weeks for long periods of time in the middle of a project are either a) incompetent project managers or b) guilty of taking advantage of their teams.

Just because it's the video game industry, many people think that it is just par for the course. I call shenanigans, and so did Erin Hoffman (EA Spouse). Thank you, Erin, for getting this kind of crap out of the closet.

Not every company is like that. I work at a fantastic game company right now that is creating a AAA game for the Wii. We've hit some tough times at points, but our crunch times are 50 hour weeks, and we almost never do them back-to-back.

The idea that you have to suck up and deal sometimes in games? Yes, absolutely. We're way too young as an industry with our production practices and there is a ton of money at stake. The idea that you should be forced to do long stretches of 60 or more hour weeks out of love for a project? As a responsible company owner, you need to turn around and either put some more resources onto the problem, or start cutting scope. Because at that point, you're abusing your team for the mistakes you have made.

Anonymous

WOW, you folks are lucky to think that 60 hour weeks are some kind of exception in modern corporate America. I'm a gamer, not someone who works in the games industry, but I do work in film production in Hollywood, and these hours are truly par for the course out here. I'm talking about EVERY DAY, in by 9 am and you don't leave before 7:30 pm, and you're expected to take home scripts or novels to read and write up for the following day. This is not high paid, either, average salary for a "creative executive" is in the 50K range and you're working 65 hour weeks, not including any reading or additional work that's required outside of the office.

I'm not saying this is excusable, just that this seems to be the trend in America today, and it's afflicting a lot of industries, from banking to lawyering to consulting to video games and film. And the sad truth is, most of the "work" people are doing during their 10 or 12 hour work day could be finished in 5 hours if employees weren't such believers in presentee-ism, or the idea that the amount of hours you sit at a desk = your productivity as a worker.

Anyway, I just wanted to chime in to say these abuses are not symptomatic of the games industry but American white collar work in general, so... beware! The fact is, in competitive industries like these, there are so many willing workers who will step in and suffer these kinds of abuses that we have little power to organize or protect ourselves. Good luck out there.

Anonymous

I worked at Bio for a few years and I can verify that what the OP said is true. Greg and Ray have spent years cultivating a perception in the gaming industry that they are somehow better then other companies. They aren't. I am not saying they are monsters, because in person they are both pretty cool guys. However, when it comes to business they are pretty ruthless. I think it's mostly Ray. They continually promise that things will get better and they don't. Almost every project at Bio has had extended crunch because the project directors always plan way more than they are able to deliver. So, the employees suffer and the directors get a pat on the back and bigger and more shares. The latest example is Mass Effect. There was a 9 month crunch on that game. Some people came close to nervous breakdowns. They implemented sympathetic crunch which they also promised they had abolished. That's where the whole team has to be on site just in case something goes wrong even if they don't have anything to do. What it's really about though is the politics of making sure that the programmers don't get pissed that the artist got off early or whoever. I think it's just going to get worse under EA. Eventually people will realize that BioWare is just like every other crunchy game dev out there.

Anonymous

(FYI, I posted before, but with the amount of anonymous posters I'll clarify I'm the one who spoke about a 400 hour summer crunch)

I've never understood or had to withstand a sympathetic crunch - Even though our projects had crunches, it was more about sharing workload or just realizing that yes, the coders do have more work ahead for them.

I recently talked to an U.S friend of mine who was astounded by my 4 week summer vacation and 1 week winter vacation. She couldn't really imagine it since she had never had one. Most she had was max 1 week off during a year. Add to that the 10+ hour workdays and I can't understand how you cope with that.

I work in northern europe, do 8 hour days 90% of the time and at my current place I can show the total crunch hours with 10 fingers.

When you're young, 400 hour crunches and sleeping in a sleeping bag might not be a big deal, but nearing 30, you'll get more interested about your rights and such. The 400 hours for me was a good eye opener on how not to do things. It was valuable, but never again. It took me more than a year to recover the friends and social aspects of my life to recover from that.

Anonymous

I think more people leave Bioware to get away from Deadmonton then any other reason!!

Hey! Nuts to you!

(Edmontonian here)

I'm acquainted with some people in Bioware. Their loyalty to the company is astonishing - if, as previous posters have said, there is a cultivated sense that Bioware's better than other game companies then it's absolutely taken root. They joke that it feels like almost living in a self-sustained arcology.

I remember one of them dismissing EA's Bioware takeover as no big deal, business as usual, why would anything change blah blah blah. I'm sure it was supposed to sound reassuring but it came off as naively dismissive in light of EA's infamous track record.

This is the first time I've actually seen numbers of their crunch time which is disappointing if true. It smacks of poor management and I guess I had some of that fairly-tale view of the company. I hope for Bioware's sake it doesn't get any worse.

Anonymous

One anonymous (or, from this page, I'm the anonymous [who defended Bioware earlier] to another I will respond to this comment -- They implemented sympathetic crunch which they also promised they had abolished.

My response is that they didn't implement that (??). People were on call of course but they didn't tell every one to be there because some people had to work. That's incorrect. If a manager thought their team had deliverables to make for sprints then they told their team to be there. If people were behind they had to be there. If people could help the team they had to be there. But that was almost always up to individual managers and if an employee had to be there just because then that is the fault of an individual manager and that individual manager should have been discussed with Casey or the project manager.

Not disagreeing with the rest of your post which pretty much said the same as mine. But this one point was inaccurate.

Anonymous

Anon in response to your argument about the sympathetic crunch; Of course it's the manager's fault, but do you really think anyone is going to buck Casey and not suffer for it? They never come right out and say that people have to be there for political reasons, they couch it in all kind of ways. All I know is that I spent more than a few nights at work until 2:00 or 3:00AM because something might go wrong even though I lived less than 30 minutes away and told them I could be called at any time. I also know that I was taken to task for always asking to leave when I was done because of the perception it created amongst people that were forced to stay.

This is an archive of an old Google Buzz conversation on MIT vs. Stanford and Silicon Valley vs. Boston

There's no reason why the Boston area shouldn't be as much a hotbed of startups as Silicon Valley is. By contrast, there are lots of reasons why NYC is no good for startups. Nevertheless, Paul Graham gave up on the Boston area, so there must be something that hinders startup formation in the area.

Kevin: This has nothing to do with money, or talents, or what it. All it matters is "entrepreneur density".

Boston may have the money, the talent, the intelligence, but does it have an entrepreneurial spirit and enough of a density?

Marya: From http://www.xconomy.com/boston/2009/01/22/paul-graham-and-y-combinator-to-leave-cambridge-stay-in-silicon-valley-year-round/ "Graham says the reasons are mostly personal, having to do with the impending birth of his child and the desire not to try and be a bi-coastal parent" But then immediately after, we see he says: "Boston just doesn’t have the startup culture that the Valley does. It has more startup culture than anywhere else, but the gap between number 1 and number 2 is huge; nothing makes that clearer than alternating between them." Here's an interview: http://www.xconomy.com/boston/2009/03/10/paul-graham-on-why-boston-should-worry-about-its-future-as-a-tech-hub-says-region-focuses-on-ideas-not-startups-while-investors-lack-confidence/ Funny, because Graham seemed partial to the Boston area, earlier: http://www.paulgraham.com/cities.html http://www.paulgraham.com/siliconvalley.html

Rebecca: I think he's partial because he likes the intellectual side of Boston, enough to make him sad that it doesn't match SV for startup culture. I know the feeling. I guess I have seen things picking up here recently, enough to make me a little wistful that I have given my intellectual side priority over any entrepreneurial urges I might have, for the time being.

Scoble: I disagree that Boston is #2. Seattle and Tel Aviv are better and even Boulder is better, in my view.

Piaw: Seattle does have a large number of Amazon and Microsoft millionaires funding startups. They just don't get much press. I wasn't aware that Boulder is a hot-bed of startup activity.

Rebecca: On the comment "there is no reason Boston shouldn't be a hotbed of startups..." Culture matters. MIT's culture is more intellectual than entrepreneurial, and Harvard even more so. I'll tell you a story: I was hanging out in the MIT computer club in the early nineties, when the web was just starting, and someone suggested that one could claim domain names to make money reselling them. Everyone in the room agreed that was the dumbest idea they had ever heard. It was crazy. Everything was available back then, you know. And everyone in that room kindof knew they were leaving money on the ground. And yet we were part of this club that culturally needed to feel ourselves above wanting to make money that way. Or later, in the late nineties I was hanging around Philip Greenspun, who was writing a book on database backed web development. He was really getting picked on by professors for doing stuff that wasn't academic enough, that wasn't generating new ideas. He only barely graduated because he was seen as too entrepreneurial, too commercial, not original enough. Would that have happened at Stanford? I read an interview with Rajiv Motwani where he said he dug up extra disk drives whenever the Google founders asked for them, while they were still grad students. I don't think that wouldn't happen at MIT: a professor wouldn't give a grad student lots of stuff just to build something on their own that they were going to commercialize eventually. They probably would encounter complaints they weren't doing enough "real science". There was much resentment of Greenspun for the bandwidth he "stole" from MIT while starting his venture, for instance, and people weren't shy about telling him. I'm not sure I like this about MIT.

Piaw: One my friends once turned down a full time offer at Netscape (after his internship) to return to graduate school. He said at that time, "I didn't go to graduate school to get rich." Years later he said, "I succeeded... at not getting rich."

Dan: As the friend in question (I interned at Netscape in '96 and '97), I'm reasonably sure I wouldn't have gotten very rich by dropping out of grad school. Instead, by sticking with academia, I've managed to do reasonably well for myself with consulting on the side, and it's not like academics are paid peanuts, either.

Now, if I'd blown off academia altogether and joined Netscape in '93, which I have to say was a strong temptation, things would have worked out very differently.

Piaw: Well, there's always going to be another hot startup. :-) That's what Reed Hastings told me in 1995.

Rebecca: A venture capitalist with Silicon Valley habits (a very singular and strange beast around here) recently set up camp at MIT, and I tried to give him a little "Toto, you're not in Kansas anymore" speech. That is to say, I was trying to tell him that the habits one got from making money from Stanford students wouldn't work at MIT. It isn't that one couldn't make money investing in MIT students -- if one was patient enough, maybe one could make more, maybe a lot more. But it would only work if one understood how utterly different MIT culture is, and did something different out of an understanding of what one was buying. I didn't do a very good job talking to him, though; maybe I should try again by stepping back and talking more generally about the essential difference of MIT culture. You know, if I did that, maybe the Boston mayor's office might want to hear this too. Hmmm... you've given me an idea.

Marya: Apropos, Philip G just posted about his experience attending a conference on angel investing in Boston: http://blogs.law.harvard.edu/philg/2010/06/01/boston-angel-investors/ He's in cranky old man mode, as usual. I imagine him shaking his cane at the conference presenters from the rocking chair on his front porch. Fun quotes: 'Asked if it wouldn’t make more sense to apply capital in rapidly developing countries such as Brazil and China, the speakers responded that being an angel was more about having fun than getting a good return on investment. (Not sure whose idea of “fun” included sitting in board meetings with frustrated entrepreneurs, but personally I would rather be flying a helicopter or going to the beach.)... 'Nobody had thought about the question of whether Boston in fact needs more angel investors or venture capital. Nobody could point to an example of a good startup that had been unable to obtain funding. However, there were examples of startups, notably Facebook, that had moved to California because of superior access to capital and other resources out there... 'Nobody at the conference could answer a macro question: With the US private GDP shrinking, why do we need capital at all?'

Piaw: The GDP question is easily answered. Not all sectors are shrinking. For instance, Silicon Valley is growing dramatically right now. I wouldn't be able to help people negotiate 30% increases in compensation otherwise (well, more like 50% increases, depending on how you compute). The number of pre-IPO companies that are extremely profitable is also surprisingly high.

And personally, I think that investing in places like China and Brazil is asking for trouble unless you are well attuned to the local culture, so whoever answered the question with "it's fun" is being an idiot.

The fact that Facebook was asked by Accel to move to Palo Alto should definitely be something Boston area VCs should berate themselves about. But that "forced move" was very good for Facebook. They acquired Jeff Rothschild, Marc Kwiatkowski, Steve Grimm, Paul Bucheit, Sanjeev Singh, and many others by being in Palo Alto that would not have moved to Boston for Facebook no matter what. It's not clear to me that staying in Boston was an optimal move for Facebook no matter what. At least, not before things got dramatically better in Boston for startups.

Marya: The GDP question is easily answered. Not all sectors are shrinking. For instance, Silicon Valley is growing dramatically right now

I'm guessing medical technology and biotech are still growing. What else?

Someone pointed this out in the comments, and Philip addressed it; he argues that angel investors are unlikely to get a good return on their investment (partial quote): "...we definitely need some sources of capital... But every part of the U.S. financial system, from venture capital right up through investment banks, is sized for an expanding private economy. That means it is oversized for the economy that we have. Which means that the returns to additional capital should be very small...."

He doesn't provide any supporting evidence, though.

Piaw: Social networks and social gaming is growing dramatically and fast.

Rebecca: Thanks, Marya, for pointing out Philip's blog post. I think the telling quote from it is this: "What evidence is there that the Boston area has ever been a sustainable place for startups to flourish? When the skills necessary to build a computer were extremely rare, minicomputer makers were successful. As soon as the skills ... became more widespread, nearly all of the new companies started up in California, Texas, Seattle, etc. When building a functional Internet application required working at the state of the art, the Boston area was home to a lot of pioneering Internet companies, e.g., Lycos. As soon as it became possible for an average programmer to ... work effectively, Boston faded to insignificance." Philip is saying Boston can only compete when it can leverage skills that only it has. That's because its ability to handle business and commercialization are so comparatively terrible that when the technological skill becomes commoditized, other cities will do much better.

But it does often get cutting-edge technical insight and skills first -- and then completely drops the ball on developing them. I find this frustrating. Now that I think about it, it seems like Boston's leaders are frustrated by this too. But I think they're making a mistake trying to remake Boston in Silicon Valley's image. If we tried to be you, at best we would be a pathetic shadow of you. We could only be successful by being ourselves, but getting better at it.

There is a fundamental problem: the people at the cutting edge aren't interested in practical things, or they wouldn't be bothering with the cutting edge. Though it might seem strange to say now, the guy who set up the hundredth web server was quite an impractical intellectual. Who needs a web server when there are only 99 others (and no browsers yet, remember)? We were laughing at him, and he was protesting the worth of this endeavor merely out of a deep intellectual faith that this was the future, no matter how silly it seemed. Over and over I have seen the lonely obsessions of impractical intellectuals become practical in two or three years, become lucrative in five or eight, and become massive industries in seven to twelve years.

So if the nascent idea that will become a huge industry in a dozen years shows up first in Boston, why can't we take advantage of it? The problem is that the people who hone their skill at nascent ideas that won't be truly lucrative for half a decade at least, are by definition impractical, too impractical to know how to take advantage of being first. But maybe Boston could become a winner if it could figure out how to pair these people up with practical types who could take advantage of the early warning about the shape of the future, and leverage the competitive advantage of access to skills no-one else has. It would take a very particular kind of practicality, different from the standard SV thing. Maybe I'm wrong, though; maybe the market just doesn't reward being first, especially if it means being on the bleeding edge of practicality. What do you think?

Piaw: Being 5 or 10 years ahead of your time is terrible. What you want to be is just 18 months or even 12 months ahead of your time, so you have just enough time to build product before the market explodes. My book covers this part as well. :-)

Marya: Rebecca, I don't know the Boston area well enough to form an opinion. I've been here two years, but I'm certainly not in the thick of things (if there is a "thick" to speak of, I haven't seen it). My guess would be that Boston doesn't have the population to be a huge center of anything, but that's a stab in the dark.

Even so, this old survey (2004) says that Boston is #2 in biotech, close behind San Diego: http://www.forbes.com/2004/06/07/cz_kd_0607biotechclusters.html So why is Boston so successful in biotech if the people here broadly lack an interest in business, or are "impractical"? (Here's a snippet from the article: "...When the most successful San Diego biotech company, IDEC Pharmaceuticals, merged with Biogen last year to become Biogen Idec (nasdaq: BIIB - news - people ), it officially moved its headquarters to Biogen's hometown of Cambridge, Mass." Take that, San Diego!)

When you talk about a certain type of person being "impractical", I don't think that's really the issue. Such people can be very practical when it comes to pursuing their own particular kind of ambition. But their interests may not lie in the commercialization of an idea. Some extremely intelligent, highly skilled people just don't care about money and commerce, and may even despise them.

Even with all that, I find it hard to believe that the intelligentsia of New England are so much more cerebral than their cousins in Silicon Valley. There's certainly a puritan ethic in New England, but I don't think that drives the business culture.

Rebecca: Marya, thanks for pointing out to me I wasn't being clear (I'm kindof practicing explaining something on you, that I might try to say more formally later, hence the spam of your comment field. I hope you don't mind.) You question " why is Boston so successful in biotech if the people here broadly lack an interest in business?" made me realize I'm not talking about people broadly -- there are plenty of business people in Boston, as everywhere. I'm talking about a particular kind of person, or even more specifically, a particular kind of relationship. Remember I contrasted the reports of Rajeev Motwani's treatment of the Google guys with the MIT CS lab's treatment of Philip? In general, I am saying that a university town like Palo Alto or Cambridge will be a magnet for ultra-ambitious young people who look for help realizing their ambitions, and a group of adults who are looking to attract such young people and enable those ambition, and there is a characteristic relationship between them with (perhaps unspoken) terms and expectations. The idea I'm really dancing around is that these terms & expectations are very different at MIT than (I've heard) they are at Stanford. Though there may not be very many people total directly involved in this relationship, it will still determine a great deal of what the city can and can't accomplish, because it is a combination of the energy of very ambitious young people and the mentorship of experienced adults that makes big things possible.

My impression is that the most ambitious people at Stanford dream of starting the next big internet company, and if they show enough energy and talent, they will impress professors who will then open their Rolodex and tell their network of VC's "this kid will make you tons of money if you support his work." The VC's who know that this professor has been right many times before will trust this judgement. So kids with this kind of dream go to Stanford and work to impress their professors in a particular kind of way, because it puts them on a fast track to a particular kind of success.

The ambitious students most cultivated by professors in Boston have a different kind of dream: they might dream of cracking strong AI, or discovering the essential properties of programming languages that will enable fault-tolerant or parallel programming, or really understanding the calculus of lambda calculus, or revolutionizing personal genomics, or building the foundations of Bladerunner-style synthetic biology. If professors are sufficiently impressed with their student's energy and talent, they will open their Rolodex of program managers at DARPA (and NSF and NIH), and tell them "what this kid is doing isn't practical or lucrative now, nor will it be for many years to come, but nonetheless it is critical for the future economic and military competitiveness of the US that this work is supported." The program managers' who know that this professor has been right many times before will trust this judgment. In this way, the kid is put on a fast track to success -- but it is a very different kind of success than the Stanford kid was looking for, and a different kind of kid who will fight to get onto this track. The meaning of success is very different, much more intellectual and much less practical, at least in the short term.

That's what I mean when I say "Boston" is less interested in business, more impractical, less entrepreneurial. It isn't that there aren't plenty of people here who have these qualities. But the "ecosystem" that gives ultra-ambitious young people the chance to do something singular which could be done no-where else -- an ecosystem which that it does have, but in a very different kind of way -- doesn't foster skill at commercialization or an interest in the immediate practical application of technology.

Maybe there is nothing wrong with that: Boston's ecosystem just fosters a different kind of achievement. However, I can see it is frustrating to the mayor of Boston, because the young people whose ambitions are enabled by Boston's ecosystem may be doing work crucial to the economic and military competitiveness of the US in the long term, but they might not help the economy of Boston very much! What often happens in the "long term" is that the work supported by grants in Boston develops to the point it becomes practical and lucrative, and then it gets commercialized in California, Seattle, New York, etc... The program managers at DARPA who funded the work are perfectly happy with this outcome, but I can imagine that the mayor of Boston is not! The kid also might not be 100% happy with this deal, because the success which he is offered isn't much like SV success -- its a fantastic amount of work, rather hermit-like and self-abnegating, which mostly ends up making it possible for other people far away to get very, very rich using the results of his labors. At best he sees only a minuscule slice of the wealth he enabled.

What one might want instead is that the professors in Boston have two sections in their Rolodex. The first section has the names of all the relevant program managers at DARPA, and the professor flips to this section first. The second section has the names of suitable cofounders, and friendly investors, and after the student has slaved away for five to seven years making a technology practical, the professor flips to the second section and sets the student up a second time to be the chief scientist or something like that at an appropriate startup.

And its not like this doesn't happen. It does happen. But it doesn't happen as much as it could, and I think the reason why it doesn't may be that it just takes a lot of work to maintain a really good Rolodex. These professors are busy and they just don't have enough energy to be the linchpin of a really top-quality ecosystem in two different ways at the same time.

If the mayor of Boston is upset that Boston is economically getting the short end of the stick in this whole deal (which I think it is), a practical thing he could do is give these professors some help in beefing up the second section of their Rolodex, or perhaps try to build another network of mentors which was in the appropriate way Rolodex-enabled. If he took the later route, he should understand that this second network shouldn't try to be a clone of the similar thing at Stanford (because at best it would only be a pale shadow) but instead be particularly tailored to incorporating the DARPA-project graduates that are unique to Boston's ecosystem. That way he could make Boston a center of entrepreneurship in a way that was uniquely its own and not merely a wannabe version of something else -- which it would inevitably do badly. That's what I meant when I said Boston should be itself better, rather than trying to be a poor pale copy of Silicon Valley.

Piaw: I like that line of thought Rebecca. Here's the counter-example: Facebook. Facebook clearly was interested in monetizing something that was very developed, and in fact, had been tried and failed many times because the timing wasn't right. Yet Facebook had to go to Palo Alto to get funding. So the business culture has to change sufficiently that the people with money are willing to risk it on very high risk ventures like the Facebook that was around 4 years ago.

Having invested my own money in startups, I find that it's definitely something very challenging. It takes a lot to convince yourself that this risk is worth taking, even if it's a relatively small portion of your portfolio. To get enough people to build critical mass, you have to have enough success in prior ventures to gain the kind of confidence that lets you fund Facebook where it was 4 years ago. I don't think I would have been able to fund Google or Facebook at the seed stage, and I've lived in the valley and worked at startups my entire career, so if anyone would be comfortable with risk, it should be me.

Dan: Rebecca: a side note on "opening a rolodex for DARPA". It doesn't really work quite like that. It's more like "hey, kid, you should go to grad school" and you write letters of recommendation to get the kid into a top school. You, of course, steer the kid to a research group where you feel he or she will do awesome work, by whatever biased idea of awesomeness.

My own professorial take: if one of my undergrads says "I want to go to grad school", then I do as above. If he or she says "I want to go work for a cool startup", then I bust out the VC contacts in my rolodex.

Rebecca: Dan: I know. I was oversimplifying for dramatic effect, just because qualifying it would have made my story longer, and it was already pushing the limits of the reasonable length for a comment. Of course the SV version of the story isn't that simple either.

I have seen it happen that sufficiently brilliant undergraduates (and even high school students -- some amazing prodigies show up at MIT) can get direct support. But realize also I'm really talking about grad students -- after all, my comparison is with the relationship between the Google guys and Rajeev Motwani, which happened when they were graduate students. The exercise was to compare the opportunities they encountered with the opportunities similarly brilliant, energetic and ultra-ambitious students at MIT would have access to, and talk about how it would be similar and different. Maybe I shouldn't have called such people "kids," but it simplified and shortened my story, which was pushing its length limit anyway. Thanks for the feedback; I'm testing out this story on you, and its useful to know what ways of saying things work and what doesn't.

Rebecca: Piaw: I understand that investing in startups by individual is very scary. I know some Boston angels (personally more than professionally) and I hear stories about how cautious their angel groups are. I should explain some context: the Boston city government recently announced a big initiative to support startups in Boston, and renovate some land opened up by the Big Dig next to some decaying seaport buildings to create a new Innovation District. I was thinking about what they could do to make that kind of initiative a success rather than a painful embarrassment (which it could easily become). So I was thinking about the investment priorities of city governments, more than individual investors like you.

Cities invest in all sorts of crazy things, like Olympic stadiums, for instance, that lose money horrifyingly ... but when you remember that the city collects 6% hotel tax on every extra visitor, and benefits from extra publicity, and collects extra property tax when new people move to the city, it suddenly doesn't look so bad anymore. Boston is losing out because there is a gap in the funding of technology between when DARPA stops funding something, because it is developed to the point where it is commercializable, and when the cautious Boston angels will start funding something -- and other states step into the gap and get rich off of the product of Massachusetts' tax dollars. That can't make the local government too happy.

Maybe the Boston city or state government might have an incentive to do something to plug that hole. They might be more tolerant of losing money directly because even a modestly lucrative venture, or one very, very slow to generate big returns, which nonetheless successfully drew talent to the city would make them money in hotel & property tax, publicity etc. etc. -- or just not losing the huge investment they have already made in their universities! I briefly worked for someone who was funded by Boston Community Capital, an organization which, I think, divided its energies between developing low income housing and and funding selected startups that were deemed socially redeeming for Boston. When half your portfolio is low-income housing, you might have a different outlook on risk and return! I was hugely impressed by what great investors they were -- generous, helpful & patient. Patience is necessary for us because the young prodigies in Boston go into fields whose time horizon is so long -- my friends are working on synthetic biology, but it will be a long, long time before you can buy a Bladerunner-style snake!

Again, thanks for the feedback. You are helping me understand what I am not making clear.

Marya: Rebecca, you said The idea I'm really dancing around is that these terms & expectations are very different at MIT than (I've heard) they are at Stanford

I read your initial comments as being about general business conditions for startups in Boston. But now I think you're mainly talking about internet startups or at least startups that are based around work in computer science. You're saying MIT's computer science department in particular does a poor job of pointing students in an entrepreneurial direction, because they are too oriented towards academic topics.

Both MIT and Stanford have top computer science and business school rankings. Maybe the problem is that Stanford's business school is more inclined to "mine" the computer science department than MIT's?

Doug: Rebecca, your description of MIT vs. Stanford sounds right to me (though I don't know Stanford well). What's interesting is that I remember UC Berkeley as being very similar to how you describe MIT: the brightest/most ambitious students at Cal ended up working on BSD or Postgres or The Gimp or Gnutella, rather than going commercial. Well, I haven't kept up with Berkeley since the mid-90s, but have there been any significant startups there since Berkeley Softworks?

Piaw: Doug: Inktomi. It was very significant for its time.

Dan: John Ousterhout built a company around Tcl. Eric Allman built a company around sendmail. Mike Stonebreaker did Ingres, but that was old news by the time the Internet boom started. Margo Seltzer built a company around Berkeley DB. None of them were Berkeley undergrads, though Seltzer was a grad student. Insik Rhee did a bunch of Internet-ish startup companies, but none of them had the visibility of something like Google or Yahoo.

Rebecca: Dan: I was thinking more about what you said about not involving undergraduates, but instead telling them to go to grad school. Sometimes MIT is in the nice sedate academic mode which steers undergrads to the appropriate research group when they are ready to work on their PhD. But sometimes it isn't. Let me tell you more about the story of the scene in the computer club concerning installation of the first web server. It was about the 100th web server anywhere, and its maintainer accosted me with an absurd chart "proving" the exponential growth of the web -- i.e. a graph going exponentially from 0 to 100ish, which he extrapolated forward in time to over a million -- you know the standard completely bogus argument -- except this one was exceptionally audacious in its absurdity. Yet he argued for it with such intensity and conviction, as if he was saying that this graph should convince me to drop everything and work on nothing but building the Internet, because it was the only thing that mattered!

I fended him off with the biggest stick I could find: I was determined to get my money's worth for my education, do my psets, get good grades (I cared back then), and there is no way I would let that be hurt by this insane Internet obsession. But it continued like that. The Internet crowd only grew with time, and they got more insistent that they were working on the only thing that mattered and I should drop everything and join them. That I was an undergraduate did not matter a bit to anyone. Undergrads were involved, grad students were involved, everyone was involved. It wasn't just a research project; eventually so many different research projects blended together that it became a mass obsession of an entire community, a total "Be Involved or Be Square" kind of thing. I'd love to say that I did get involved. But I didn't; I simply sat in the office on the couch and did psets, proving theorems and solving the Schrodinger's equation, and fended them off with the biggest stick I could find. I was determined to get a Real Education, to get my money's worth at MIT, you know.

My point is that when the MIT ecosystem really does its thing, it is capable of tackling projects that are much bigger than ordinary research projects, because it can get a critical mass of research projects working together, involving enough grad students and also sucking in undergrads and everyone else, so that the community ends up with an emotional energy and cohesion that goes way, way beyond the normal energy of a grad student trying to finish a PhD.

There's something else too, though I cannot report on this with that much certainty, because was too young to see it all at the time. You might ask: if MIT had this kind of emotional energy focused on something in the 90's, then what is it doing in a similar way now? And the answer I'd have to say, painfully, is that it is frustrated and miserable about being an empty shell of what it once was.

Why? Because in 2000 Bush got elected and he killed the version of DARPA with which so many professors had had such a long relationship. I didn't I understand this in the 90's -- like a kid I took the things that were happening around me for granted without seeing the funding that made them possible -- but now I see that that the kind of emotional energy expended by the Internet crowd at MIT in the 90's costs a lot of money, and needs an intelligent force behind it, and that scale of money and planning can only come from the military, not from NSF.

More recently I've watched professors who clearly feel it is their birthright to be able to mobilize lots of student to do really large-scale projects, but then they try to find money for it out of NSF, and they spend all their time killing themselves writing grant proposals, never getting enough money to make themselves happy, and complaining about the cowardice of academia, and wishing they could still work with their old friends at DARPA. They aren't happy because they are merely doing big successful research projects, but a mere research project isn't enough... when MIT is really MIT it can do more. It is an empty shell of itself when it is merely a collection of merely successful but not cohesive NSF funded research projects. As I was saying, the Boston "ecosystem" has in itself the ability to do something singular, but it is singular in an entirely different way than SV's thing.

This may seem obscure, a tale of funding woes at a distant university, but perhaps it is something you should be aware of, because maybe it affects your life. The reason you should care is that when MIT was fully funded and really itself, it was building the foundations of the things that are now making you rich.

One might think of the relationship between technology and wealth like a story about potential energy: when you talk about finding a "product/market" fit, its like pushing a big stone up a hill, until you get the "fit" at the top of the hill, and then the stone rolls down and the energy you put into it spins out and generates lots of money. In SV you focus on pushing stones up short hills -- like Piaw said, no more than 12-18 months of pushing before the "fit" happens.

But MIT in its golden age could tackle much, much bigger hills -- the whole community could focus itself on ten years of nothing but pushing a really big stone up a really big hill. The potential energy that the obsessed Internet Crowd in the 90's was pushing into the system has been playing out in your life ever since. They got a really big stone over a really big hill and sent it down onto you, and then you pushed it over little bumps on the way down, and made lots of money doing it, and you thought the potential energy you were profiting from came entirely from yourselves. Some of it was, certainly, but not all. Some of it was from us. If we aren't working on pushing up another such stone, if we can't send something else over a huge hill to crash into you, then the future might not be like the past for you. Be worried.

So you might ask, how did this story end? If I'm claiming that there was intense emotional energy being poured into developing the Internet at MIT in the 90's, why didn't those same people fan out and create the Internet industry in Boston? If we were once such winners, how did we turn into such losers? What happened to this energetic, cohesive group?

I can tell you about this, because after years of fending off the emotional gravitation pull of this obsession, towards the end I began to relent. First I said "No way!" and then I said "No!" and then I said "Maybe Later," and then I said "OK, Definitely Later"... and then when I finally got around to Later, and (perhaps the standard story of my life) Later turned out to be Too Late. By 2000 I was ready to join the crowd and remake myself as an Internet Person in the MIT style. So I ended up becoming seriously involved just at the time it fell apart. Because 2000ish, almost the beginning of the Internet Era for you, was the end for us.

This weekend I was thinking of how to tell this story, and I was composing it in my head in a comic style, thinking to tell a story of myself as "Parable of Boston Loser" to talk about all my absurd mistakes as a microcosm of the difficulties of a whole city. I can pick on myself, can't I; no one will get upset at that? The short story is that in 2000ish the Internet crowd had achieved their product/market fit, DARPA popped the champagne -- you won guys! Congratulations! Now go forth and commercialize! -- and pushed us out of the nest into the big world to tackle the standard tasks of commercializing a technology -- the tasks that you guys can do in your sleep. I was there, right of the middle of things, during that transition. I thought to tell you a comic story about the absurdity of my efforts in that direction, and make you laugh at me.

But when I was trying to figure out how to explain what was making it so terribly hard for me, to my great surprise I was suddenly crying really hard. All Saturday night I was thinking about it and crying. I had repressed the memory, decided I didn't care that much -- but really it was too terrible to face. All the things you can do without thinking, for us hurt terribly. The declaration of victory, the "achievement of product/market fit", the thing you long for more than anything, I -- and I think many of the people I knew -- experienced as a massive trauma. This is maybe why I've reacted so vehemently and spammed your comment field, because I have big repressed personal trauma about all this. I realized I had a much more earnest story to tell than I had previously planned.

For instance, I was reflecting on my previous comment about what cities spend money on, and thinking that I sounded like the biggest jerk ever. Was I seriously suggesting that the city take money that they would have spent on housing for poor black babies and instead spend it on overeducated white kids with plenty of other prodigiously lucrative economic opportunities? Where do I get off suggesting something like that? If I really mean it I have a big, big burden of proof.

So I'll try to combine my more earnest story with at least a sketch of how I'd tackle this burden of proof (and try to keep it short, to keep the spam factor to a minimum. The javascript is getting slow, so I'll cut this here and continue.)

Ruchira: Interlude (hope Rebecca continues soon!): Rebecca says "that scale of money and planning can only come from the military, not from NSF." Indeed, it may be useful to check out this NY Times infographic of the federal budget: http://www.nytimes.com/interactive/2010/02/01/us/budget.html

I'll cite below some of the 2011 figures from this graphic that were proposed at that time; although these may have changed, the relative magnitudes of one sector versus another are not very different. I've mostly listed sectors in decreasing order of budget size for research, except I listed "General science & technology" sector (which includes NSF) before "Health" sector (which includes NIH) since Rebecca had contrasted the military with NSF.

The "Research, development, test, and evaluation" segment of the "National Defense" sector is $76.77B. I guess DARPA, ONR, etc. fit there.

The "General science & technology" sector is down near the lower right. The "National Science Foundation programs" segment gets $7.36B. There's also another $0.1B for "National Science Foundation and other". The "Science, exploration, and NASA supporting activities" segment gets $12.78B. (I don't know to what extent satellite technology that is relevant to the national defense is also involved here, or in the $4.89B "Space operations" segment, or in the $0.18B "NASA Inspector General, education, and other" segment.) The "Department of Energy science programs" segment gets $5.12B. The "Department of Homeland Security science and technology programs" segment gets $1.02B.

In the "Health" sector, the "National Institutes of Health" segment gets $32.09B. The "Disease control, research, and training" segment gets $6.13B (presumably this includes the CDC). There's also "Other health research and training" at $0.14B and "Diabetes research and other" at $0.095B.

In the "Natural resources and environment sector", the "National Oceanic and Atmospheric Administration" gets $5.66B. "Regulatory, enforcement, and research programs" gets $3.86B (is this the entire EPA?).

In the "Community and regional development" sector, the "National Infrastructure Innovation and Finance fund" (new this year) gets $4B.

In the "Agriculture" sector, which presumably includes USDA-funded research, "Research and education programs" gets $1.97B, "Research and statistical analysis" gets $0.25B, and "Integrated research, education, and extension programs" gets $0.025B.

In the "Transportation" sector, "Aeronautical research and technology" gets $1.15B, which by the way would be a large (130%) relative increase. (Didn't MIT find a way of increasing jet fuel efficiency by 75% recently?)

In the "Commerce and housing credit" sector, "Science and technology" gets $0.94B. I find this rather mysterious.

In the "Education, training, employment" sector, "Research and general education aids: Other" gets $1.14B. The "Institute for Education Sciences" gets $0.74B.

In the "Energy" sector, "Nuclear energy R&D" gets $0.82B and "Research and development" gets $0.024B (presumably this is the portion outside the DoE).

In the "Veterans' benefits and services" sector, "Medical and prosthetic research" gets $0.59B.

In the "Income Security" sector there's a tiny segment "Children's research and technical assistance" $0.052B. Not sure what that means.

Rebecca: I'll start with a non-sequitur which I hope to use to get at the hear of the difference between MIT and Stanford: recently I was at a Marine publicity event and I asked the recruiter what differentiates the Army from the Marines? Since they both train soldiers to fight, why don't they do it together? He answered vehemently that they must be separate because of one simple attribute in which they are utterly opposed: how they think about the effect they want to have on the life their recruits have after they retire from the service. He characterized the Army as an organization which had two goals: first, to train good soldiers, and second, to give them skills that would get them a good start in the life they would have after they left. If you want to be a Senator, you might get your start in the Army, get connections, get job skills, have "honorable service" on your resume, and generally use it to start your climb up the ladder. The Army aspires to create a legacy of winners who began their career in the Army.

By contrast the Marines, he said, have only one goal: they want to create the very best soldiers, the elite, the soldiers they can trust in the most difficult and dangerous situations to keep the Army guys behind them alive. This elite training, he said, comes with a price. The price you pay is that the training you get does not prepare you for anything at all in the civilian world. You can be the best of the best in the Marines, and then come home and discover that you have no salable civilian job skills, that you are nearly unemployable, that you have to start all over again at the bottom of the ladder. And starting over is a lot harder than starting the first time. It can be a huge trauma. It is legendary that Marines do not come back to civilian life and turn into winners: instead they often self-destruct -- the "transition to civilian life" can be violently hard for them.

He said this calmly and without apology. Did I say he was a recruiter? He said vehemently: "I will not try to recruit you! I want to you to understand everything about how painful a price you will pay to be a Marine. I will tell you straight out it probably isn't for you! The only reason you could possibly want it is because you want more than anything to be a soldier, and not just to be a soldier, but to be in the elite, the best of the best." He was saying: we don't help our alumni get started, we set them up to self-destruct, and we will not apologize for it -- it is merely the price you pay for training the elite!

This story gets to the heart of what I am trying to say is the essential difference between Stanford and MIT. Stanford is like the Army: for its best students, it has two goals -- to make them engineers, and to make them winners after they leave. And MIT is like the Marines: it has only one goal -- to make its very best student into the engineering elite, the people about whom they can truthfully tell program managers at DARPA: you can utterly trust these engineers with the future of America's economic and military competitiveness. There is a strange property to the training you get to enter into that elite, much like the strange property the non-recruiter attributed to the training of the Marines: even though it is extremely rigorous training, once you leave you can find yourself utterly without any salable skills whatever.

The skills you need to acquire to build the infrastructure ten years ahead of the market's demand for it may have zero intersection with the skills in demand in the commercial world. Not only are you not prepared to be a winner, you may not even be prepared to be basically employable. You leave and start again at the bottom. Worse than the bottom: you may have been trained with habits commercial entities find objectionable (like a visceral unwillingness to push pointers quickly, or a regrettable tendency to fight with the boss before the interview process is even over.) This can be fantastically traumatic. Much as ex-Marines suffer a difficult "transition to civilian life," the chosen children of MIT suffer a traumatic "transition to commercial life." And the leaders at MIT do not apologize for this: as the Marine said, it is just the price you pay for training the elite.

This is the general grounds which I might use to appeal to the city officials in Boston. There's more to explain, but the shape of the idea would be roughly this: much a cities often pay for programs to help ex-Marines transition to civilian life, on the principal that they represent valuable human capital that ought not to be allowed to self-destruct, it might pay off for the city to understand the peculiar predicament of graduates of MIT's intense DARPA projects, and provide them with help with the "transition to commercial life." There's something in it for them! Even though people who know nothing but how to think about the infrastructure of the next decade aren't generically commercially valuable, if you put them in proximity to normal business people, their perspective would rub off in a useful way. That's the way that Boston could have catalyzed an Internet industry of its own -- not by expecting MIT students to commercialize their work, which (with the possible exception of Philip) they were constitutionally incapable of, but by giving people who wanted to commercialize something but didn't know what a chance to learn from the accumulated (nearly ten years!) of experience and expertise of the Internet Crowd.

On that note, I wanted to say -- funny you should mention Facebook. You think of Mark Zuckerberg as the social networking visionary in Boston, and Boston could have won if they had paid to keep him. I think that strange -- Zuckerberg is fundamentally one of you, not one of us. It was right he should leave. But I'll ask you a question you've probably never thought about. Suppose the Internet had not broken into the public consciousness at the time it did; suppose the world had willfully ignored it for a few more years, so the transition from a DARPA-funded research project to a commercial proposition would have happened a few years later. There was an Internet Crowd at MIT constantly asking DARPA to let them build the "next thing," where "next" is defined as "what the market will discover it wants ten years from now." So if this crowd had gotten a few more years of government support, what would they have built?

I'm pretty sure it would have been a social networking infrastructure, not like Facebook, really, but more like the Diaspora proposal. I'm not sure, but I remember in '98/'99 that's what all the emotional energy was pointing toward. It wasn't technically possible to build yet, but the instant it was that's what people wanted. I think it strange that everyone is talking about social networking and how it should be designed now; it feels to me like deja vu all over again, and echo from a decade ago. If the city or state had picked up these people after DARPA dropped them, and given them just a little more time, a bit more government support -- say by a Mass ARPA -- they could have made Boston the home, not of the big social networking company, but of the open social networking infrastructure and and all the expertise and little industries such a thing would have thrown off. And it would have started years and years ago! That's how Boston could have become a leader by being itself better, rather than trying to be you badly.

Dan: I think you're perhaps overstating the impact of DARPA. DARPA, by and large, funds two kinds of university activities. First, it funds professors, which pays for post-docs, grad students, and sometimes full-time research staff. Second, DARPA also funds groups that have relatively little to do with academia, such as the BSD effort at Berkeley (although I don't know for a fact that they had DARPA money, they didn't do "publish or perish" academic research; they produced Berkeley Unix).

Undergrads at a place like MIT got an impressive immersion in computer science, with a rigor and verve that wasn't available most other places (although Berkeley basically cloned 6.001, and others did as well). They call it "drinking from a firehose" for a reason. MIT, Berkeley, and other big schools of the late 80's and early 90's had more CS students than they knew what to do with, so they cranked up the difficulty of the major and produced very strong students, while others left for easier pursuits.

The key inflection point is how popular culture at the university, and how the faculty, treat their "rock star" students. What are the expectations? At MIT, it's that you go to grad school, get a PhD, become a researcher. At Stanford, it's that you run off and get rich.

The decline in DARPA funding (or, more precisely, the micromanagement and short-term thinking) in recent years can perhaps be attributed to the leadership of Tony Tether. He's now gone, and the "new DARPA" is very much planning to come back in a big way. We'll see how it goes.

One last point: I don't buy the Army vs. Marines analogy. MIT vs. Stanford train students similarly, in terms of their preparation to go out and make money, and large numbers of MIT people are quite successfully out there making money. MIT had no lack of companies spin out of research there, notably including Akamai. The differences we're talking about here are not night vs. day, they're not Army vs. Marines. They're more subtle but still significant.

Rebecca: Yes, I've been hearing about the "unTethered Darpa." I should have mentioned that, but left it out to stay (vaguely) short. And yes, I am overstating to make it possible to make a simple statement of what I might be asking for that would be couched in terms a city or state government official might be able to relate to. Maybe that's irresponsible; that's why I'm testing it on you first, to give you a chance to yell at me and tell me if you think that's so.

They are casting about for a narrative of why Boston ceded its role as leaders of the Internet industry to SV, that would point them to something to do about it. So I was talking specifically about the sense in which Boston was once a leader in internet technology and the weaknesses that might have caused it to lose its lead. Paul Graham says that Boston has the weakness in developing industries that it is "too good" at other things, so I wanted to tell a dramatized story specifically about what the other things were and why that would lead to fatal weakness -- how being "too strong" in a particular way can also make you weak.

I certainly am overstating, but perhaps I am because I am trying to exert force against another prediliction I find pernicious: the tendency to be eternally vague about the internal emotional logic that makes things happen in the world. If people build a competent, cohesive, energetic community, and then it suddenly fizzles, fails to achieve its potential, and disbands, it might be important to know what weakness caused this surprising outcome so you know how to ask for the help that would keep it from happening the next time.

And to tell the truth, I'm not sure I entirely trust your objection. I've wondered why so often I hear such weak, vague narratives about the internal emotional logic that causes things to happen in the world. Vague narratives make you helpless to solve problems! I don't cling to the right to overstate things, but I do cling to the right to sleuth out the emotional logic of cause and effect that drives the world around me. I feel sometimes that I am fighting some force that wants to thwart me in that goal -- and I suspect that that force sometimes originates, not always in rationality, but in in a male tendency to not want to admit to weakness just for the sake of "seeming strong." A facade of strength can exact a high price in the currency of the real competence of the world, since often the most important action that actually makes the world better is the action of asking for help. I was really impressed with that Marine for being willing to admit to the price he paid, to the trauma he faced. That guy didn't need to fake strength! So maybe I am holding out the image of him as an example. We have government officials who are actively going out of their way to offer to help us; we have a community that accomplishes many of its greatest achievements because of government support; we shouldn't squander an opportunity to ask for what might help us. And this narrative might be wrong; that's why I'm testing it first. I'm open to criticism. But I don't want to pass by an opportunity, an opening to ask for help from someone who is offering it, merely because I'm too timid to say anything for the fear of overstatement.

Dan: Certainly, Boston's biggest strength is the huge number of universities in and around the area. Nowhere else in the country comes close. And, unsurprisingly, there are a large number of high-tech companies in and around Boston. Another MIT spin-out I forgot to mention above is iRobot, the Roomba people, which also does a variety of military robots.

To the extent that Boston "lost" the Internet revolution to Silicon Valley, consider the founding of Netscape. A few guys from Illinois and one from Kansas. They could well have gone anywhere. (Simplifying the story, but) they hooked up with a an angel investor (Jim Clark) and he draged them out to the valley where they promptly hired a bunch of ex-SGI talent and hit the road running. Could they have gone to Boston? Sure. But they didn't.

What seems to be happening is that different cities are developing their own specialties and that's where people go. Dallas, for example, has carved out a niche in telecom, and all the big players (Nortel, Alcatel, Cisco, etc.) do telecom work there. In Houston, needless to say, it's all about oilfield engineering. It's not that there's any particular Houston tax advantage or city/state funding that brings these companies here. Rather, the whole industry (or, at least the white collar part of it) is in Houston, and many of the big refineries are close nearby (but far enough away that you don't smell them).

Greater Boston, historically, was where the minicomputer companies were, notably DEC and Data General. Their whole world got nuked by workstations and PCs. DEC is now a vanishing part of HP and DG is now a vanishing part of EMC. The question is what sort of thing the greater Boston area will become a magnet for, in the future, and how you can use whatever leverage you've got to help make it happen. Certainly, there's no lack of smart talent graduating from Boston-area universities. The question is whether you can incentivize them to stay put.

I'd suggest that you could make headway, that way, by getting cheap office space in and around Cambridge (an "incubator") plus building a local pot of VC money. I don't think you can decide, in advance, what you want the city's specialty to be. You pretty much just have to hope that it evolves organically. And, once you see a trend emerging, you might want to take financial steps to reinforce it.

Thomas: BBN (which does DARPA funded research) has long been considered a halfway house between MIT and the real world.

Piaw: It looks like there's another conversation about this thread over at Hacker News: http://news.ycombinator.com/item?id=1416348 I love conversation fragmentation.

Doug: Conversation fragmentation can be annoying, but do you really want all those Hacker News readers posting on this thread?

Piaw: Why not? Then I don't have to track things in two places.

Ruchira: hga over at Hacker News says: "Self-selection by applicants is so strong (MIT survived for a dozen year without a professional as the Director), whatever gloss the Office is now putting on the Institute, it's able to change things only so much. E.g. MIT remains the a place where you don't graduate without taking (or placing out of) a year of the calculus and classical physics (taught at MIT speed), for all majors."

Well, the requirements for all majors at Caltech are: two years of calculus, two years of physics (including quantum physics), a year of chemistry, and a year of biology (the biology requirement was added after I went there); freshman chemistry lab and another introductory lab; and a total of four years of humanities and social sciences classes. The main incubator I know of near Caltech is the Idealab. Certainly JPL (the Jet Propulsion Laboratory) as well as Hollywood CGI and animation have drawn from the ranks of Caltech grads. The size of the Caltech freshman class is also much smaller than those at Stanford or MIT.

I don't know enough to gauge the relative success of Caltech grads at transitioning to local industry, versus Stanford or MIT, does anyone else?

Rebecca: The comments are teaching me what I didn't make clear, and this is one of the worst ones. When I talked about the "transition to the commercial world" I didn't mainly mean grads transitioning to industry. I was thinking more about the transition that a project goes through when it achieves product/market fit.

This might not be something that you think of as such a big deal, because when companies embark on projects, they usually start with a fairly specific plan of the market they mean to tackle and what they mean to do if and when the market does adopt their product. There is no difficult transition because they were planning for it all along. After all, that's the whole point of a company! But a ten year research project has no such plan. The web server enthusiast did not know when the market would adopt his "product" -- remember, browsers were still primitive then -- nor did he really know what it would look like when they did. Some projects are even longer term than that: a programming language professor said that the expected time from the conception of a new programming language idea to its widespread adoption is thirty years. That's a good chunk of a lifetime.

When you've spent a good bit of your life involved with something as a research project that no-one besides your small crowd cares about, when people do notice, when commercial opportunities show up, when money starts pouring out of the sky, its a huge shock! You haven't planned for it at all. Have you heard Philip's story of how he got his first contract for what became ArsDigita? I couldn't find the story exactly, but it was something like this: he had posted some of the code for his forum software online, and HP called him up and asked him to install and configure it for them. He said "No! I'm busy! Go away!" They said "we'll pay you $100,000." He's in shock: “You'll give me $100000 for 2 weeks of work?”

He wasn't exactly planning for money to start raining down out of the sky. When he started doing internet applications, he said, people had told him he was crazy, there was no future in it. I remember when I first started seeing URL's in ads on the side of buses, and I was just bowled over -- all the time my friends had been doing web stuff, I had never really believed they would ever be adopted. URL's are just so geeky, after all! I mean, seriously, if some wild-eyed nerd told you that in five years people would print "http://",on the side of a bus, what would you think? I paid attention to what they were doing because they thought it was cool, I thought it was cool, and the fact that I had no real faith anyone else ever would made no difference. So when the world actually did, it was entering a new world that none of us were prepared for, that nobody had planned for, that we had not given any thought to developing skills to be able to deal with. I guess this is a little hard to convey, because it wouldn't happen in a company. You wouldn't ever do something just because you thought it was cool, without any faith that anyone would ever agree with you, and then get completely caught by surprise, completely bowled over, when the rest of the world goes crazy about what you thought was your esoteric geeky obsession.

Piaw: I think we were all bowled over by how quickly people started exchanging e-mail addresses, and then web-sites, etc. I was stunned. But it took a really long time for real profits to show up! It took 20 or so search engine companies to start up and fail before someone succeeded!

Rebecca: Of course; you are bringing up what was in fact the big problem. The question was: in what mode is it reasonable to ask the local government for help? And if you are in the situation where $100,000 checks are raining on you out of the sky without you seeming to make the slightest effort to even solicit them, then it seems like only the biggest jerk on the planet would claim to the government that they were Needy and Deserving. Black babies without roofs on their heads are needy and deserving; rich white obnoxious nerds with money raining down on them are not. But remember though Philip doesn't seem to be expending much effort in his story, he also said in the late 90's that he had been building web apps for ten years. Who else on the planet in 1999 could show someone a ten year long resume of web app development?

As Piaw said, it isn't like picking up the potential wealth really was just a matter of holding out your hand as money rained from the sky. Quite the contrary. It wasn't easy; in fact it was singularly difficult. Sure, Philip talked like it was easy, until you think about how hard it would have been to amass the resume he had in 1999.

When the local government talks about how it wants to attract innovators to Boston, to turn the city into a Hub of Innovation, my knee-jerk reaction is -- and what are we, chopped liver? But then I realize that when they say they want to attract innovators, what they really mean is not that they want innovators, but that they want people who can innovate for a reasonable, manageable amount of time, preferably short, and then turn around, quick as quicksilver, and scoop up all the return on investment in that innovation before anyone else can get at it -- and give a big cut in taxes to the city and state! Those are the kind of innovators who are attractive! Those are the kind who properly make your Boston the kind of Hub of Innovation the Mayor of Boston wants it to be. Innovators like those in Tech Square or Stata, not so much. We definitely qualify for the Chopped Liver department.

And this hurts. It hurts to think that the Mayor of Boston might be treating us with more respect now if we had been better in ~2000 at turning around, quick as quicksilver, and remaking ourselves into people who could scoop up all, or some, or even a tiny fraction of the return on investment of the innovation at which we were then, in a technical sense, well ahead of anyone else. But remaking yourself is not easy! Especially when you realize that the state from which we were remaking ourselves was sort of like the Marines -- a somewhat ascetic state, one that gave you the nerd equivalent of military rations, a tent, maybe a shower every two weeks, and no training in any immediately salable skills whatsoever -- but also one that also gave you a community, an identity, a purpose, a sense of who you were that you never expected to change. But all of a sudden we "won," and all of a sudden there was a tremendous pressure to change. It was like being thrown in the deep end of the pool without swim lessons, and yes we sank, we sank like a stone with barely a dog paddle before making a beeline for the bottom. So we get no respect now. But was this a reasonable thing to expect? What does the mayor of Boston really want? Yes, the sense in which Boston is a Hub of Innovation (for it already is one, it is silly for it to try to become what it already is!) is problematic and not exactly what a Mayor would wish for. I understand his frustration. But I think he would do better to work with his city for what it is, in all its problematic incompetence and glory, than to try to remake it in the image of something else it is not.

Rebecca: On the subject of Problematic Innovators, I was thinking back to the scene in the computer lab where everyone agreed that hoarding domain names was the dumbest idea they had ever heard of. I'm arguing that scooping up return on the investment in innovation was hard, but registering a domain name is the easiest thing in the world. I think they were free back then, even. If I remember right, they started out free, and then Procter & Gamble registered en-mass every name that had even the vaguest entomological relation with the idea of "soap," at which point the administrators of the system said "Oops!" and instituted registration fees to discourage that kind of behavior -- which, of course, would have done little to deter P&G. They really do want to utterly own the concept of soap. (I find it amusing that P&G was the first at bat in the domain name scramble -- they are not exactly the world's image of a cutting-edge tech-savvy company -- but when it comes to the problem of marketing soap, they quietly dominate.)

How can I can explain that we were not able to expend even the utterly minimal effort in capturing the return on investment in innovation of registering a free domain name, so as to keep the resulting tax revenues in Massachusetts?

Thinking back on it, I don't think it was either incapacity, or lack of foresight, or a will to fail in our duty as Boston and Massachusetts taxpayers. It was something else: it was almost a "semper fidelis"-like group spirit that made it seem dishonorable to hoard a domain name that someone else might want, just to profit from it later. Now one might ask, why should you refrain from hoarding it sooner just so that someone else could grab it and hoard it later? That kind of honor doesn't accomplish anything for anyone!

But you have to realize, this was right at the beginning, when the domain name system was brand new and it wasn't at all clear it would be adopted. These were the people who were trying to convince the world to accept this system they had designed and whose adoption they fervently desired. In that situation, honor did make a difference. It wouldn't look good to ask the world to accept a naming system with all the good names already taken. You actually noticed back then when something (like "soap") got taken -- the question wasn't what was available, the question was what was taken, and by whom. You'd think it wouldn't hurt too much to take one cool name: recently I heard that someone got a $38 million offer for "cool.com." That's a lot of money! -- would it have hurt that much to offer the world a system with all the names available except, you know, one cool one? But there was a group spirit that was quite worried that once you started down that slope, who knew where it would lead?

There were other aspects of infrastructure, deeper down, harder to talk about, where this group ethos was even more critical. You can game an infrastructure to make it easier to personally profit from it -- but it hurts the infrastructure itself to do that. So there was a vehement group discipline that maintained a will to fight any such urge to diminish the value of the infrastructure for individual profit.

This partly explains why we were not able, when the time came, to turn around, quick as quicksilver, and scoop up the big profits. To do that would have meant changing, not only what we were good at, but what we thought was right.

When I think back, I wonder, why people weren't more scared? When we chose not to register "cool.com" or similar names, why didn't we think, life is hard, the future is uncertain, and money does really make a difference in what you can do? I think this group ethic was only possible because there was a certain confidence -- the group felt itself party to a deal: in return for being who we are, the government would take care of us, forever. Not until the time when the product achieved sufficient product/market fit that it became appropriate to expect return on investment. Forever.

This story might give a different perspective on why it hurts when the Mayor of Boston announces that he wants to make the city a Hub of Innovation. The innovators he already has are chopped liver? Well, its understandable that he isn't too pleased with the innovators in this story, because they aren't exactly a tax base. But that is the diametric opposition of the deal with the government we thought we had.

This is an archive of an old Google Buzz conversation (circa 2010?) on a variety of topics, including whether or not it's inevetible that a closed platform will dominate social.

Piaw: Social networks will be dominated primarily by network effects. That means in the long run, Facebook will dominate all the others.

Rebecca: ... which is also why no one company should dominate it. "The Social Graph" and its associated apps should be like the internet, distributed and not confined to one company's servers. I wish the narrative surrounding this battle was centered around this idea, and not around the whole Silicon Valley "who is the most genius innovator" self-aggrandizing unreality field. Thank god Tim Berners Lee wasn't from Silicon Valley, or we wouldn't have the Internet the way we know it in the first place.

I suppose I shouldn't be being so snarky, revealing how much I hate your narratives sometimes. But I think for once this isn't, as it usually is, merely harmlessly cute and endearing - you all collectively screwing up something actually important, and I'm annoyed.

Piaw: The way network effects work, one company will control it. It's inevitable.

Rebecca: No it is not inevitable! What is inevitable is either that one company controls it or that no company controls it. If you guys had been writing the narrative of the invention of the internet you would have been arguing that it was inevitable that the entire internet live on one companies servers, brokered by hidden proprietary protocols. And obviously that's just nuts.

Piaw: I see, the social graph would be collectively owned. That makes sense, but I don't see why Facebook would have an incentive to make that happen.

Rebecca: Of course not! That's why I'm biting my fingernails hoping for some other company to be the white knight and ride up and save the day, liberating the social graph (or more precisely, the APIs of the apps that live on top of them) from any hope of control by a single company. Of course, there isn't a huge incentive for any other company to do it either --- the other companies are likely to just gaze enviously at Facebook and wish they got there first. Tim Berners Lee may have done great stuff for the world, but he didn't get rich or return massive value to shareholders, so the narrative of the value he created isn't included in the standard corporate hype machine or incentives.

Google is the only company with the right position, somewhat appropriate incentives, and possibly the right internal culture to be the "Tim Berners Lee" of the new social internet. That's what I was hoping for, and I'm am more than a bit bummed they don't seem to be stepping up to the plate in an effective way in this case, especially since they are doing such a fabulous job in an analogous role with Android.

Rebecca: There is a worldview lurking behind these comments, which perhaps I should try to explain. I'm been nervous about this because it contains some strange ideas, but I'm wondering what you think.

Here's a very strange assertion: Mark Zuckerberg is not a capitalist, and therefore should not be judged by capitalist logic. Before you dismiss me as nuts, stop and think for a minute. What is the essential property that makes someone a capitalist?

For instance, when Nike goes to Indonesia and sets up sweatshops there, and if communists, unhappy with low pay & terrible conditions, threaten to rebel, they are told "this is capitalism, and however noxious it is, capitalism will make us rich, so shut up and hold your peace!" What are they really saying? Nike brings poor people sewing machines and distribution networks so they can make and sell things they could not make and sell otherwise, so they become more productive and therefore richer. The productive capacity is scarce, and Nike is bringing to Indonesia a piece of this scarce resource (and taking it away from other people, like American workers.) So Indonesia gets richer, even if sweatshop workers suffer for a while.

So is Mark Zuckerberg bringing to American workers a piece of scarce productive capacity, and therefore making American workers richer? It is true he is creating for people productive capacity they did not have before --- the possibility of writing social apps, like social games. This is "innovation" and it does make us richer.

But it is not wealth that follows the rules of capitalist logic. In particular, this kind of wealth of productive capacity, unlike the wealth created by setting up sewing machines, does not have the kind of inherent scarcity that fundamentally drives capitalist logic. Nike can set up its sewing machines for Americans, or Indonesians, but not for everyone at once. But Tim Berners Lee is not forced to make such choices -- he can design protocols that allow everyone everywhere to produce new things, and he need not restrict how they choose to do it.

But -- here's the key point -- though there is no natural scarcity, there may well be "artificial" scarcity. Microsoft can obfuscate Windows API's, and bind IE to Windows. Facebook can close the social graph, and force all apps to live on its servers. "Capitalists" like these can then extract rents from this artificial scarcity. They can use the emotional appeal of capitalist rhetoric to justify their rent-seeking. People are very conditioned to believe that when local companies get rich American workers in general will also get rich -- it works for Indonesia so why won't it work for us? And Facebook and Microsoft employees are getting richer. QED.

But they aren't getting richer in the same way that sweatshop employees are getting richer. The sweatshop employees are becoming more productive than they would otherwise be, in spite of the noxious behavior of the capitalists. But if Zuckerberg or Gates behaves noxiously, by creating a walled garden, this may make his employees richer, in the sense of giving them more money, but "more money" is not the same as "more wealth." More wealth means more productive capacity for workers, not more payout to individual employees. In a manufacturing economy those are linked, so people forget they are not the same.

And in fact, shenanigans like these reduce rather than increase the productive capacity available to everyone, by creating an artificial scarcity of a kind of productive tool that need not be scarce at all, just for the purpose of extracting rents from them. No real wealth comes from this extraction. In aggregate it makes us poorer rather than richer.

Here's where the kind of stunt that Google pulled with Android, that broke the iPhone's lock, even if it made Google no money, should be seen as the real generator of wealth, even if it is unclear whether it made any money for Google's shareholders. Wealth means I can build something I couldn't build before -- if I want I can install a Scheme or Haskell interpreter on an Android phone, which I am forbidden to put on the iPhone. It means a lot to me! Google's support of Firefox & Chrome, which sped the adoption of open web standards and HTML5, also meant a huge amount to me. I'm an American worker, and I am made richer by Google, in the sense of having more productive capacity available to me, even if Google wasn't that great for my personal wealth in the sense of directly increasing my salary.

Rebecca: (That idea turned out to be sortof shockingly long comment by itself, and on review the last two paragraphs of the original comment were a slightly different thought, so I'm breaking them into a different section.)

I'm upset that Google is getting a lot of anti-trust type flak, when I think the framework of anti-trust is just the wrong way to think. This battle isn't analogous to Roosevelt's big trust busting battles; it is much more like the much earlier battles at the beginning of the industrial revolution of the Yankee merchants against the old agricultural, aristocratic interests, which would have squelched industrialization. And Google is the company that has been most consistently on the side of really creating wealth, by not artificially limiting the productivity they make available for developers everywhere. Other companies, like Microsoft or Facebook, though they are "new economy," though they are "innovative," though they seem to generate a lot of "wealth" in the form of lots of money, really are much more like the old aristocrats rather than the scrappy new Yankees. In many ways they are slowing down the real revolution, not speeding it up.

I've been reluctant to talk too much about these ideas, because I'm anxious about being called a raving commie. But I'm upset that Google is the target of misguided anti-trust logic, and it might be sufficiently weakened that it can't continue to be the bulwark of defense against the real "new economy" abuses that it has been for the last half-decade. That defense has meant a lot to independent developers, and I would hate to see it go away.

Phil: +100, Rebecca. It is striking how little traction the rhetoric of software freedom has here in Silicon Valley relative to pretty much everywhere else in the world.

Rebecca: Thanks - I worry whether my ultra-long comments are spam and its good to hear if someone appreciates them. I have difficulty making my ideas short, but I'm using this Buzz conversation to practice.

I'm am not entirely happy with the way the "software freedom" crowd is pitching their message. I had an office down the hall from Richard Stallman for a while, and I was often harangued by him. However, I thought his message was too narrow and radicalized. But on the other hand, when I thought about it hard, I also realized that in many ways it was not radical enough...

Why are we talking about freedom? To motivate this, I sometimes tell a little story about the past. When I was young my father read to me "20,000 Leagues Under the Sea," advertising it as a great classic of futuristic science fiction. Unfortunately, I was unimpressed. It didn't seem "futuristic" at all: it seemed like an archaic fantasy. Why? Certainly it was impressive that an author in 1869 correctly predicted that people would ride in submarines under the sea. But it didn't seem like an image of the future, or even the past, at all. Why not? Because the person riding around on the submarine under the sea was a Victorian gentleman surrounded by appropriately deferential Victorian servants.

Futurists consistently get their stories wrong in a particular way: when they say that technology changes the world, they tell stories of fabulous gadgets that will enable people to do new and exciting things. They completely miss that this is not really what "change" -- serious, massive, wrenching, social change - really is. When technology truly enables dreams of change, it doesn't mean it enables aristocrats to dream about riding around under the sea. What it means is that enables the aristocrat's butler to dream of not being a butler any more --- a dream of freedom not through violence or revolution, but through economic independence. A dream of technological change -- really significant technological change -- is not a dream of spiffy gadgets, it is a dream of freedom, of social & economic liberation enabled by technology.

Lets go back to our Indonesian sweatshop worker. Even though in many ways the sweatshop job liberates her --- from backbreaking work on a farm, a garbage dump, or in brothels -- she is also quite enslaved. Why? She can sew, let us say, high-end basketball sneakers, which Nike sells for $150 apiece -- many, many times her monthly or even yearly wage. Why is she getting a small cut of the profit from her labors? Because she is dependent on the productive capacity that Nike is providing to her, so bad as the deal is, it is the best she can get.

This is where new technology comes in. People talk about the information revolution as if it is about computers, or software, but I would really say it is about society figuring out (slowly) how to automate organization. We have learned to effectively automate manufacturing, but not all of the work of a modern economy is manufacturing. What is the service Nike provides that makes this woman dependent on such a painful deal? Some part of this service is the manufacturing capacity they provide -- the sewing machine -- but sewing machines are hardly expensive or unobtainable, even for poor people. The much bigger deal is the organizational services Nike offers: all the branding, logistics, supply-chain management and retail services that go into getting a sneaker sewn in Indonesia into the hands of an eager consumer in America. One might argue that Nike is performing these services inefficiently, so even if our seamstress is effective and efficient, Nike must take an unreasonably large cut of the profits from the sale of the sneaker to support the rest of this inefficient, expensive, completely un-automated effort.

That's where technological change comes in. Slowly, it is making it possible for all these organizational services to be made more automated, streamlined and efficient. This is really the business Google is in. It is said that Google is an "advertising" business, but to call what Google does "advertising" is to paper over the true story of the profound economic shift of which they are merely providing the opening volley.

Consider the maker of custom conference tables who recently blogged in the New York Times about Adwords (http://boss.blogs.nytimes.com/2010/12/03/adwords-and-me-exploring-the-mystery/). He said he paid Google $75,124.77 last year. What does that money represent -- what need is Google filling which is worth more than seventy thousand a year to this guy? You might say that they are capturing an advertising budget of a company, until you consider that without Google this company wouldn't exist at all. Before Google, did you regularly stumble across small businesses making custom conference tables? This is a new phenomenon! The right way to see it is that this seventy thousand isn't really a normal advertising budget -- instead, think of it as a chunk of the revenue of the generic conference table manufacturer that this person no longer has to work for. Because Google is providing for him the branding, customer management services, etc, etc that this old company used to be doing much less efficiently and creatively, this blogger has a chance to go into business for himself. He is paying Google seventy thousand a year for this privilege, but this is probably much less than the cut that was skimmed off the profits of his labors by his old management (not to mention issues of control and stifled creativity he is escaping). Google isn't selling "advertising": Google is selling freedom. Google is selling to the workers of the world the chance to rid themselves of their chains -- nonviolently and without any revolutionary rhetoric -- but even without the rhetoric this service is still about economic liberation and social change.

I feel strange when I hear Eric Schmidt talk about Google's plans for the future of their advertising business, because he seems to be telling Wall Street of a grand future where Google will capture a significant portion of Nike's advertising budget (with display ads and such). This seems like both an overambitious fantasy; and also strangely not nearly ambitious enough. For I think the real development of Google's business -- not today, not tomorrow, not next year, not even next decade, but eventually and inexorably (assuming Google survives the vicissitudes of fate and cultural decay) -- isn't that Google captures Nike's advertising budget. It is that Google captures a significant portion of Nike's entire revenue, paid to them by the workers who no longer have to work for Nike anymore, because Google or a successor in Google's tradition provides them with a much more efficient and flexible alternative vendor for the services Nike's management currently provides.

Rebecca: (Once again I looked at my comment and realized it was even more horrifyingly long. My thoughts seem short in my head, but even when I try to write them down as fast and effectively as I can, they aren't short anymore! Again, I saw the comment has two parts: first, explaining the basic idea of the "freedom" we are talking about, and second, tying it back into the context of our original discussion. So to try to be vaguely reasonable I am cutting it in two.)

I suppose Eric Schmidt will never stand in front of Wall Street and say that. When it is really true that "We will bury you!" nobody ever stands up and bangs a shoe on the table while saying it. The architects of the old "new economy" didn't say such things either: the Yankee merchants never said to their aristocratic political rivals that they intended to eventually completely dismantle their social order. In 1780 there was no discussion that foretold the destructive violence of Sherman's march to the sea. I'm not sure they knew it themselves, and if they had been told that that was a possible result of their labors they might not have wanted to hear it. The new class wanted change, they wanted opportunity, they wanted freedom, but they did not want blood! That they would be cornered into seeking it anyway would have been as horrifying to them as to anyone else. Real change is not something anyone wants to crow about --- it is too terrifying.

But it is nonetheless important to face, because in the short term this transformation is hardly inevitable or necessarily smooth. If our equivalent of Sherman's march to the sea might be in our future, we might want to think about how to manage or avoid it before it is too late.

One major difficulty, as I explained in the last comment, is that while the "automation of information," if developed properly, has the potential to break fundamental laws of the scarcity of productive capacity, and thereby free "the workers of the world", nonetheless that potential can be captured, and turned into "artificial" scarcity, which doesn't set workers free, it further enslaves them. There is also a big incentive to do this, because it is the easiest way to make massive amounts of money quickly for a person in the right place at the right time.

I see Microsoft as a company that has made a definite choice of corporate strategy to make money on "artificial scarcity." I see Google as a company that has made a similar definite choice to make money "selling freedom", specifically avoiding the tricks that create artificial scarcity, even when it doesn't help or even hurts their immediate business prospects.

And Facebook? Where is Sheryl Sandburg (apparently the architect of business development at Facebook) on this crucial question? A hundred years from now, when all your "genius" and "innovation," all the gadgets you build that so delight aristocrats, and are so celebrated by "futurists", will be all but forgotten, the choices you make on this question will be remembered. This matters.

Ms. Sandburg seems to be similarly clear on her philosophy: she simply wants as much diversity of revenue streams for Facebook as she can possibly get. It is hard to imagine an more un-ideological antithesis of Richard Stallman. Freedom or scarcity, she doesn't care: if its a way to make money, she wants it. As many different ones as possible! She wants it all! Its hard for me to get too worked up about this, especially since for other reasons I am rooting for Ms. Sandburg's success. Even so, I would prefer if it were Google in control of this technological advance, because Google's preference on this question is so much more clear and unequivocal.

I don't care who is the "genius innovator" and who is the "big loser", whether this or that company has taken up the mantle of progress or not, who is going to get rich, which company will attract all the superstars, or all the other questions that seem to you such critical matters, but I do care that your work makes progress towards realizing the potential of your technology to empower the workers of the world, rather than slowing it down or blocking it. Since Google has made clear the most unequivocal preference in the right direction on this question, that means I want Google to win. This is too important to be trusted to the control of someone ambivalent about their values, no matter how much basic sympathy I have for the pragmatic attitude. Baris Baser: +100! Liberate the social graph! I wish I could share the narrative taking place here on my buzz post, but I'll just plug it in.

Rob: Google SO dropped the ball with Orkut - they let Facebook run off with the Crown Jewels. Helder Suzuki: I believe that Facebook's dominance will eventually be challenged just like credit card companies are being today. But I think it's gonna come much quickier for Facebook.

There are lots of differences, but I like this comparison because credit card companies used great network effect to dominate and shield the market from competition. If you look at them (visa, amex, mastercard), all they have today is basically brand. Today we just know that "credit card" payment (and the margins) will be so much different in the near future.

Likewise I don't think that social graph will protect Facebook's "market" in the long run. Just like today it's incredibly easier to set a POS network compared to a few years ago, social graph is gonna be something trivial in the years to come.

Rebecca: Yay! People are reading my obscenely long and intellectual comments. Thanks guys!

Piaw: I disagree with Helder, even though I agree with Rebecca that it's better for Google to own the social graph. The magic trick that Facebook pulled off was getting the typical user to provide and upload all his/her personal information. It's incredibly hard to do that: Amazon couldn't do it, and neither could Google. I don't think it's one of those things that's technically difficult, but the social engineering required to do that demands critical mass. That's why I think that Facebook is (still) under-valued.

Rob: @Piaw - it was an accident of history I think. When Facebook started, they required a student ID to join. This made a culture of "real names" that stuck, and that no one else has been able to replicate.

Piaw: @Rob: The accident of history that's difficult to replicate is what makes Facebook such a good authentication mechanism. I would be willing to not moderate my blog, for instance, if I could make all commenters disclose their true identity. The lowest qualify arguments I've seen on Quora, for instance, were those in which one party was anonymous. Elliotte Rusty Harold: This is annoying I want to reshare Rebecca's comments. not the original post, but I can't seem to do that. :-)

Rebecca: In another conversation, someone linked a particular point in a Buzz commentary to Hacker News (http://news.ycombinator.com/item?id=1416348). I'm not sure how they did it. It was a little strange, though, because then people saw it out of context. These comments were tailored for a context.

Where do you want to share it? I'm not sure I'm ready to deal with too big an audience; there is a purpose to practicing writing and getting reactions in an obscure corner of the internet. After all, I am saying things that might be offensive or objectionable in Silicon Valley, and are, in any case, awfully forward -- it is useful to me to talk to a select group of my friends to get feedback from them on how well it does or doesn't fly. Its not like I mind being public, but I also don't mind obscurity for now.

Rebecca: Speaking of which, Piaw, I was biting my fingernails a little wondering how you would react to my way of talking about "software freedom." I've sort of thought of becoming a software freedom advocate in the tradition of Stallman or ESR, but more intellectual, with more historical perspective, and (hopefully) with less of an edge of polemical insanity. However, adding in an intellectual and historical perspective also added in the difficulty of colliding with real intellectuals and historians, which makes the whole thing fraught, so for that reason among others I've been dragging my feet.

This discussion made me dredge up this whole project, partly because I really wanted to know your reactions to it. However, you only reacted to the Facebook comments, not the more general software freedom polemic. What did you think about that?

Piaw: I mostly didn't react to the free software polemic because I agree with what you're saying. I agree that something like Adwords and Google makes possible businesses that didn't exist before. Facebook, for instance, recently showed me an ad for a Suzanne Vega concert that I definitely would not have known about but would have wanted to go if not for a schedule conflict. I want to be able to "like" that ad so that I can get Facebook to show me more ads like those!

Do I agree that the world would be a better place for Facebook's social graph to be an open system? Yes and No. In the sense of Facebook having less control, I think it would be a good thing. But do I think I want anybody to have access to it? No. People are already trained to click "OK" to whatever data access any applet wants in Facebook, and I don't need to be inundated with spam in Facebook --- one of the big reasons Facebook has so much less spam is because my friends are more embarrassed about spamming me than the average marketing person, and when they do spam me it's usually with something that I'm interested in, which makes it not spam.

But yes, I do wish my Buzz comments (and yours too) all propagated to Facebook/Friendfeed/etc. and the world was one big open community with trusted/authenticated users and it would be all spam free (or at least, I get to block anonymous commenters who are unauthenticated). Am I holding my breath for that? No.

I am grateful that Facebook has made a part of the internet (albeit a walled garden part) fully authenticated and therefore much more useful. I think most people don't understand how important that is, and how powerful that is, and that this bit is what makes Facebook worth whatever valuation Wall Street puts on it.

Baris: Piaw, a more fundamental question lurks within this discussion. Ultimately, will people gravitate toward others with similar interests and wait for resources to grow there (Facebook,) or go where the resources are mature, healthy, and growing fast, and wait for everyone else to arrive (Google?)

Will people ultimately go to Google where amazing technology currently exists and will probably magnify, given the current trend (self driving cars, facial recognition, voice recognition, realtime language translation, impeccable geographic data, mobile OS with a bright future, unparalleled parallel computing, etc..) or join their friends first at the current largest social network, Facebook, and wait for the technology to arrive there?

A hypothetical way of looking at this: Will people move to a very big city and wait for it to be an amazing city, or move to an already amazing city and wait for everyone else to follow suit? Or are people ok with a bunch of amazing small cities?

Piaw: Baris, I don't think you've got the analogy fully correct. The proper analogy is this: Would you prefer to live in a small neighborhood where you sometimes have to go a long way to get what you want/are interested in but is relatively crime free, or would you like to live in a big city where it's easy to get what you want but you get tons of spam and occasionally someone comes in and breaks into your house?

The world obviously has both types of people, which is why suburbs and big cities both exist.

Baris: "tons of spam and occasionally someone comes in and breaks into your house?" I think this is a bit too draconian/general though... going with this analogy, I think becomes a bit more subjective, i.e. really depends on who you are in that city, where you live, what you own, how carefree you live your life, and so forth.

Piaw: Right. And Facebook has successfully designed a web-site around this ego-centricity. You can be the star of your tiny town by selectively picking your friends, or you can be the hub of a giant city and accept everyone as a friend. If the latter, then you gave up your privacy when your "friend" posts compromising pictures of you that gets you in trouble with your employer.

Nick: Google is the only company with the right position, somewhat appropriate incentives, and possibly the right internal culture to be the "Tim Berners Lee" of the new social internet.

I'd agree that Google hasn't done well at social, but surely are better than that!

Rebecca: Oh, you aren't impressed with Tim Berner Lee's work? Was it the original HTML standard you didn't like, or the more recent W3C stuff? I would admit there is stuff to complain about about both of them.

Nick: It seems to me that TBL got lucky. His original work on the WWW was good, but I think it is difficult to argue he was responsible for its success - certainly no more than someone like Marc Andreessen, who has a pattern of success that repeated after his initial success with Mosaic.

Rebecca: @Piaw (a little ways back) So you found my free software polemic so unobjectionable as to be barely worth comment? Wasn't it a little intellectually radical, with all that "not a capitalist" and "change in the nature of scarcity" stuff? When I told Lessig parts of basic story (not in Google context, because it was many years ago), and asked him for advice about how to talk to economists, he warned me that the words I was using contain so many warning bells of crackpot intellectual radicalism that economists would immediately write me off for using them without any further consideration.

It never ceases to amaze me how engineers will swallow shockingly strange ideas without a peep. I suppose in the company of Stallman and ESR, I am a raging intellectual conservative and pragmatist, and since engineers have accepted their style as at least a valid way to have a discussion (even if they don't agree with their politics), I seem tame by comparison. Of course talking to historians or economists is a different matter, because they don't already accept that this is a valid way to have a discussion.

Actually, it is immensely useful to me to have this discussion thread to us to show people who might think I'm a crackpot, because it is evidence for the claim that in my own world nobody bats an eyelash at this way of talking.

Incidentally, I started thinking about this subject because of Krugman. In the late nineties I was a rabid Krugman fan in a style that is now popular -- "Krugman is always right" -- but was a bit strange back then when he was just another MIT economics professor hardly anyone had ever heard of. However, when he talked about technology (http://pkarchive.org/column/61100.html), I thought he was wrong, which upset me terribly because I also was almost religiously convinced he was always right. In another essay (http://pkarchive.org/personal/howiwork.html) he said it was very important to him to "Listen to the Gentiles" i.e "Pay attention to what intelligent people are saying, even if they do not have your customs or speak your analytical language." But he also said "I have no sympathy for those people who criticize the unrealistic simplifications of model-builders, and imagine that they achieve greater sophistication by avoiding stating their assumptions clearly." So it seemed clear to me that he would be willing to hear me explain why he was wrong, as long as I would be willing to state my assumption clearly.

Before I knew exactly what I was intending to say, my plan had been to figure out my assumptions well enough to meet his standards, and then ask him to help me do the rest of the work to cast it all into a real economic model. Back then he was just an MIT professor I'd taken a class from, not a famous NYTimes columnist, Nobel-prize winning celebratory, so this plan seemed natural. Profs at MIT don't object if their students point out mistakes, as long as the students are responsible about it. It took me a while to struggle through the process of figuring out what my assumptions were (assumptions? I have assumptions?). When I did I was somewhat horrified to realize that following through with my plan meant accosting him to demand he write a new Wealth of Nations for me! (He'd also left for Princeton by then and started to become famous, so my plan was logistically more difficult than I'd planned.) I had not originally realized what it was that I would be asking for, or that the whole thing would be so daunting.

I asked Lessig for advice what to do (Lessig being the only person I knew who lived in both worlds) and Lessig read me the riot act about the rules of intellectual respectability. So it seemed it would be up to me to write the new Wealth of Nations, or at least enough of it to prove the respectability of the ideas contained therein. I was trying to be a computer science student, not an economist, so that degree of effort hardly fit into my plans. I tried to ask for help at the Lab for Computer Science (now CSAIL) by giving a talk in a Dangerous Ideas seminar series, but of the professors I talked to, only David Clark was sympathetic about the need for such a thing. However, he also said very clearly that resources to support grad students to work with economists were limited and really confined to only the kind of very specific net-neutrality stuff he was pushing in concert with his protocol work, not the kind of general worldview I was thinking about. So I was amazed to find that this kind of thing falls into the cracks between different parts of academic culture.

I'm still not sure what to do, but I am more and more inclined to ignore Lessig's (implicit) advice to be apologetic and defensive about my lack of intellectual respectability. That would entail a degree of effort I can't afford, since I am still focused on proving myself as a computer scientist, not an intellectual in the humanities. (Having this discussion thread to point to is quite useful on that score.) I could just drop it (I did for a while), but I'm getting more and more upset that technology is moving much faster than the intellectual and social progress that is required to handle it. People seem to think that powerful technology is a good thing in itself, but that is not true: it is only technology in the presence of strong institutions to control its power that provide net benefits to society -- without such controls it can be fantastically destructive. From that point of view a "new economy" is not good news -- what "new" means is that all the old institutions are now out of date and their controls are no longer working. And academic culture is culturally dislocated in ways that ensure that no one anywhere is really dealing with this problem. Pretty picture, isn't it?

Nick: @Rebecca: I don't understand your argument. Why is Google selling advertising anymore about freedom than Facebook selling advertising?

It's true that Facebook doesn't make their social graph and/or demographic data available to third parties, but Google doesn't make a person's search history available to third parties either. Why is one so much worse than the other?

Piaw: Rebecca I think that having more data be more open is ideal. However, but I view it as a purely academic discussion for the same reason I view writing "Independent Cycle Touring" in TeX to be an academic discussion. Sure it could happen, but the likelihood of it happening is so slim to none that I don't find the discussion to be of interest.

Now, I do agree that technology and its adoption does grow faster than our wisdom and controls for them. However, I don't think that information technology is the big offender. Humanity's big long term problems has more to do with fossil fuels as an energy source, and that's pretty darn old technology. You can fix all the privacy problems in the world, but if we get a runaway greenhouse planet by 2100 it is all moot. Because of that you don't find me getting worked up about privacy or the open-ness of Facebook's social graph. If Facebook does become personally objectionable to me, then I will close my account. Otherwise, I will keep leveraging the work their engineers do.

Elliotte: Rebecca, going back and rereading your comments I'm not sure your analysis is right, but I'm not sure it's wrong either. Of course, I am not an economist. From my non-economist perspective it seems worth further thought, but I also suspect that economists have already thought much of this. The first thing I'd do is chat up a few economists and see if they say something like, "Oh, that's Devereaux's Theory of Productive Capacity" or some such thing.

I guess I didn't see anything particularly radical and certainly nothing objectionable in what you wrote. You're certainly not the first to notice that software economics has a different relationship to scarcity than physical goods.Nor would I see that as incompatible with capitalism. It's only really incompatible with a particular religious view of capitalism that economists connected to the real world don't believe in anyway. The theological ideologues of the Austrian School and the nattering nabobs of television news will call you a commie (or more likely these days a socialist) but you can ignore them. Their claimed convictions are really just a bad parody of economics that bares only the slightest resemblance to the real world.

You hear a lot from these fantasy world theorists because they have been well funded over the last 40 years or so by corporations and the extremely wealthy with the explicit goal of justifying wealth. Academically this is most notable at the University of Chicago, and it's even more obvious in the pseudo-economics spouted on television news. At the extreme, these paid hucksters expouse the laissez-faire theological conviction that markets are perfectly efficient and rational and that therefore whatever the markets do must be correct; but the latest economic crises have caused most folks to realize that this emperor has no clothes. Economists doing science and not theology pay no attention to this priesthood. I wish the same could be said for the popular media.

Helder: I don't think I agree with the scarcity point that Rebecca made.

Generally, if a company is making money from something it's because their are producing some kind of wealth, otherwise they won't sustain economically. It doesn't have to be productive wealth like in factories, it could be cultural (e.g. a TV Show), or something else.

Even if you think of artificial scarcity, that's only possible for a company to make when they already have a big momentum (e.g. windows or facebook dominance). Artificial scarcity sucks when you look just at it, but it's more like a "local" optimzation based on an already dominant market position.

Perhaps Facebook, Microsoft and other co. wouldn't thrive in the first place if they weren't "allowed" to make the most of their closed system. The world is a better place with a closed Facebook and proprietary Windows API than no with no Facebook or Windows at all.

TV producers try to do their best to create the right scarcity when releasing their shows and movies to maximize profit. If they were to adopt some kind of free and open philosophy that they would release their content for download on day 1, they would simply go broke and destroy wealth in the long run.

Rebecca: Thanks guys, for the great comments! I appreciate the opportunity to answer these objections, because this is a subtle issue and I can certainly see that the reasoning behind my position is far from obvious. I won't be able to do it today because I need to be out all day, and its probably just as well that I have a little time to think of how to make the reply as clear and short as possible.

Rebecca: OK, I have about four different kinds of objections to answer, and I don't want to keep this as short as I can, so I think I will arrange it carefully so I can use the ideas in one answer to help me explain the next one. That means I'll answer in the order: Elliot, Piaw then Nick & Helder.

It actually took me much of a week to write and edit an answer I liked and believed was condensed as I could make it. And despite my efforts it is still quite long. However, your reaction to my first version has impressed on me that there are some key points I need to take the space to clarify:

1. I shouldn't have tried to talk about a system that "isn't capitalism" in too short an essay, because that is just too easily misunderstood. I take a good bit of space in the arguments below matching Elliots' disavowal of the religious view of capitalism with an explicit disavowal of the religious view of the end of capitalism.

2. Piaw also asked a good question "why is this important?" It isn't obvious; its only something you can see once it sinks into you how dramatically decades of exponential technological growth can change the world. Since this subject is pretty crazy-making and hard to see with any perspective, I try to use an image from the past to help us predict how people from the future will see us differently than we see ourselves. I want to impress on you why future generations are likely to make very different judgements about what is and isn't important.

3. Finally, I said rather casually that I wanted to talk about software freedom in the standard tradition, only with more intellectual and historical perpective. As I write this, though, I'm realizing the historical perspective actually changes the substance of the position, in a way I need to make clear.

And last of all I wanted to step back again and put this all in the context of what I am trying to accomplish in general, with some commentary on your reactions to the assertion that I am being intellectually radical.

These replies are split into sections so you can choose the one you like if the whole thing is too long. But the long answer to Piaw contains the idea which is key to the rest of it.

Rebecca: so, first, @Elliot -- "I'm not the first to notice that software has a different relationship with scarcity than physical goods" But my take on the difference is not the usual: I am not repeating the infinitely-copyable thing everyone goes on about, but instead focusing on the scarcity (or increasing lack thereof) of productive capacity. That way of talking challenges more directly the fundamental assumptions of economic theory, and is therefore more intellectually radical: in a formal way, it challenges the justification for capitalism. But you didn't buy my "incompatible with capitalism" argument either, which I'm glad of, because it gives me the chance to mention that just as much as you want to disown the religious view of what capitalism is, I'd like to specifically disown the religious view of the end of capitalism.

Marx talked about an "end of capitalism" as some magic system where it becomes possible for workers to seize the means of production (the factories) and make the economy work without ownership of capital. He also was predicting that capitalism must eventually end, because after all, feudalism had ended. But if you put those two assertions together, and solved the logical syllogism, you would get the assertion that feudalism ended because the serfs seized the means of production (the farms) and made an economy work without the ownership of land. That isn't true! I grew up in Iowa. There are landowners there who own more acreage than most fabled medieval kings. Nobody challenges their ownership, and yet nobody would call that system feudalism. Why not? Because their fields are harvested by machines, not serfs. Feudalism ended not because the landowning class changed their landowning ways. It was because the land-working class, the serfs, left for better jobs in factories; and the landowners don't care anymore, because they eventually replaced the serfs with machines. The end of feudalism was not the end of the ownership of land, it was the end of a social position and set of perogatives that went along with that ownership. If your vassals are machines, you can't lord over them.

Similarly, in a non-religious view of the end of capitalism, it will come about not because the capitalist class, the class that owns factories, will ever disappear or change their ways, but because the proletariat will go away -- they will leave for better jobs doing something else, and the factory owners will replace them with machines. And in fact you can see that that is already happening. Are you proletariat? Am I? If I create an STL model and have it printed by Shapeways, I am manufacturing something, but I am not proletariat. Shapeways is certainly raising capital to buy their printers, which strictly speaking makes them "capitalists," but in a social sense they are not capitalists, because their relationship with me has a different power structure from the one Marx objected to so violently. I am not a "prole" being lorded over by them. It isn't the big dramatic revolution Marx envisioned; it is almost so subtle you can miss it entirely. What if capitalism ended and nobody noticed?

Rebecca: Next @Piaw -- Piaw said he didn't think information technology was the biggest offender in the realm of technology that grows faster than our controls of it; for instance he thought global warming was a more pressing immediate problem.

I definitely agree that the immediate problems created by information technology and the associated social change are, right now, small by comparison to global warming. It would be nice if we could tackle the most immediate and pressing problems first, and leave the others until they get big enough to worry about. But the problems of a new economy have the unique feature of being pressing not because they are necessarily immediate or large (right now), but because if they are left undealt-with they can destroy the political system's ability to effectively handle these or any other problems.

I'm a believer in understanding the present through the lens of the past: since we have so much more perspective about things that happened many, many years ago, we can interpret the present and predict our future by understanding how things that are happening to us now are analogous to things that happened long ago. Towards that end, I'd like to point out an analogy with a fictional image of people who, very early on in the previous "new economy," tried to push new ideas of freedom and met with the objection that they were making too big a deal over problems that were too unimportant. (That this image is fictional is part of my point -- bear with me.) My image comes from a dramatic schene in the musical 1776 (whose synopsis can found at http://en.wikipedia.org/wiki/1776_%28musical%29, scene seven), in which an "obnoxious and disliked" John Adams almost throws away the vote of Edward Rutledge and the rest of the southern delegation over the insistence that a condemnation of slavery be included in the Declaration of Independence. He drops this insistence only when he is persuaded to change his mind by Franklin's arguments that the fight with the British is more important than any argument on the subject -- "we must hang together or we will hang separately."

In fact, nothing like that ever happened: as the historical notes on the Wikipedia page say, everyone at the time was so totally in agreement that the issue was too unimportant to be bothered to fight about it, let alone have the big showdown depicted in the musical, with Rutledge dramatically but improbably singing a spookily beautiful song in defense of the triangle trade: "Molasses to Rum to Slaves." The scene was inserted to satisfy the sensibilities of modern audiences that whether or not such a showdown happened, it should have happened.

Why are our sensibilities so much different than reality? Why are we imposing on the past the idea that the fight ought to have been important to them, even though it wasn't, that John Adams ought to have made himself obnoxious and disliked in his intransigent insistence on America's founding values of freedom, even though he didn't and he wasn't, that Franklin ought to have argued with great reluctance that the fight with the British was more important, even though he never made that argument (because it went without saying), and that Edward Rutledge ought to have been a spooky, equally intransigent apologist for slavery, even though he wasn't either (later he freed his own slaves). We are imposing this false narrative because we are looking backwards through a lens where we know something about the future the real actors had no idea about. This is important to understand because we may be in a similar position with respect to future generations -- they will think we should have had a fight we in fact have no inclination to have, because they will know something we don't know about our own future. The central argument I want to make to Piaw hinges on an understanding of this thing that later generations are likely to know about our future that we currently have difficulty imagining.

So forgive me if I belabor this point: it is key to my answer both to Piaw's question and also to Nick & Helder's objection. Its going to take a little bit of space to set up the scenery, because it is non-trivial for me to pull my audience back into a historical mentality very different than our own. But I want to go through this exercise in order to pull out of it a general understanding of how and why political ways of thinking shift in the face of dramatic technological change -- which we can use to predict how our own future and the changing shape of our politics.

What is it that the real people behind this story didn't know that we know now? Start with John Adams: to understand why the real John Adams wouldn't have been very obnoxious about pushing his idea of freedom on slaveowners in 1776, realize that his idea of freedom, if restated in economic rather than moral terms, would have been the assertion that "it should be an absolute right of all citizens of the United States to leave the farm where they were born and seek a better job in a factory." But making a big deal about such a right in 1776 would have been absurd. There weren't very many factories, and they were sufficiently inefficient that the jobs they provided were unappealing at best. For example, at the time Jefferson wrote in total seriousness about the moral superiority of agrarian over industrial life: such a sentiment seemed reasonable in 1776, because, not to put too fine a point on it, factory life was horrible. Because of this, the politicians in 1776, like Adams or Hamilton, who were deeply enamored of industrialization, pushed their obsession with an apologetic air, as if they were only talking about their own personal predilections, which they took great pains to make clear they were not going to impose on anyone else. The real John Adams was not nearly as obnoxious as our imaginary version of him: we imagine him differently only because we wish he had been different.

We wish him different than he really was because there was one important fact that the people of 1776 may have understood intellectually, but whose full social significance they did not even begin to wrap their minds around: the factories were getting better exponentially, while the farms would always stay the same. Moore's Law-like growth rates in technology are not a new phenomenon. Improvements in the production of cotton textiles in the early nineteenth century stunned observers like the improvements in chips or memory impress us today -- and after cotton-spinning had its run, other advances stepped into the limelight each in turn, as the article at www.theatlantic.com/magazine/archive/1999/10/beyond-the-information-revolution/4658/ tries to impress on us. We forget that dramatic exponential improvements in technology are not a new phenomenon. We also forget that if exponential growth runs for decades, it changes things... and it changes things more than anybody at the beginning of such a run dares to imagine.

This brings us to the other characters in our story who made choices we now wish they had made differently (and they also later regretted). Edward Rutledge and Thomas Jefferson didn't exactly defend slavery; they were quite open about being uncomfortable with it, but they didn't consider this discomfort important enough to do much about. That position would also have made sense in 1776: landowners had owned slaves since antiquity, but slavery in ancient times was not fantastically onerous compared to the other options available to the lower classes at the time -- there are famous stories of enterprising Greek and Roman slaves who earned their freedom and rose to high positions in society. Rutledge and Jefferson probably thought they were offering their slaves a similar deal, and that all in all, it wasn't half bad.

They were wrong. American slavery turned out to be something unique, entirely different than the slavery of antiquity. My American history teacher presented this as a "paradox," that the country that was founded on an ideal of freedom also was home to the most brutal system of slavery the world has ever seen. But I think this "paradox" is quite understandable: it is two parts of the same phenomenon. Ask the question: why could ancient slaveowners afford to be relatively benign? Because they were also relatively secure in their position -- their slaves knew as well as they did that the lower classes didn't have many other better options. Sally Hemmings, Jefferson's lover, considered running away when she was in France with him, but Jefferson successfully convinced her that she would get a better deal staying with him. He didn't have to take her home in chains: she left the possibility of freedom in France and came back of her own free will (if slightly wistfully).

But as time passed and the factory jobs in the North proceeded in their Moore's Law trajectory, eventually the alternatives available to the lower classes began to look better than in any time before in human history. The slaves Harriet Tubman smuggled to Canada arrived to find options exponentially better than those Hemmings could have hoped for if she had left Jefferson. As a result, for the first time in human history, slaves had to be kept in chains.

In the more abstract terms I was using before, slavery was relatively benign when the scarcity of opportunity that bound slaves to their masters was real, but as other opportunities became available, this "real scarcity" became "artificial," something that had to be enforced with chains -- and laws. That is where the slaveowners transformed into something uniquely brutal: to preserve their way of life they needed not only to put their slaves in chains, they also needed to take over the political and legal apparatus of society to keep those chains legal. There came into existence the one-issue politician -- the politician whose motive to enter political life was not to understand or solve the problems facing the nation, to listen to other points of view or forge compromises, or any of the other natural things that a normal politician does, but merely to fight for one issue only: to write into law the "artificial scarcity" that was necessary to preserve the way of life of his constituents, and play whatever brutal political tricks were necessary to keep those laws on the books. Political violence was not off the table - a recent editorial "When Congress Was Armed And Dangerous" (www.nytimes.com/2011/01/12/opinion/12freeman.htm) reminds us that that the incitements to violence of today's politics are tame compared to the violence of the politics of the 1830's, 40's and 50's. The early 1860's were the culmination of the decades-long disaster we wish the Founding Fathers had foreseen and averted. We wish they had had the argument about slavery while there was still time for it to be a mere argument -- before the elite it supported poisoned the political system to provide for its defense.

They, in their old age, wished it too: forty-five years after Jefferson declined to make slavery an important issue in the debate over the Declaration of Independence, he was awakened by the "firebell in the night" in the form of the Missouri compromise. News of this fight caused him to wake up to the real situation, and he wrote to a friend "we have the wolf by the ears, and we can neither hold him, nor safely let him go. Justice is in one scale, and self-preservation in the other.... I regret that I am now to die in the belief that the useless sacrifice of themselves by the generation of '76, to acquire self government and happiness to their country, is to be thrown away by the unwise and unworthy passions of their sons, and that my only consolation is to be that I live not to weep over it."

So, forty-five years after he declined to engage with an "unimportant," "academic" question, he said of the consequences of that decision that his "only consolation is to be that I live not to weep over it." He had not counted on the "unwise and unworthy passions" of his sons -- for his own part, he would have been happy to let slavery lapse when economic conditions no longer gave it moral justification. However, the next generation had different ideas -- they wanted to do anything it took to preserve their prerogatives. By that point the choices he had were defined by the company he kept: since he was a Virginian, he would have had to go to war for Virginia, and fight against everything he believed in. He would have wanted to go back to the time when he could have made a choice that was his own, but that time was past and gone, and no matter how "unwise and unworthy" were the passions which were now controlling him, he had no choice but to be swept along by them.

This is my argument about why we should pay attention to "unimportant" and "academic" questions. In 1776 it was equally well "academic" to consider looking ahead through seventy five years of exponential growth to project the economic conditions of 1860, and use that projection to motivate a serious consideration of abstract principles that were faintly absurd in the conditions of the time, and would only become burning issues decades and decades later. Yet we wish they had done just that, and in their old age they also fervently wished that they had too. This seems strange: why plan for 1860 in 1776? Why plan for 2085 in 2010? Why not just cross that bridge when we come to it? Let the next generation worry about their own problems; why should we think for them? we have our own burning issues to worry about! The projected problems of 2085 are abstract, academic, and unimportant to us. Why not leave them alone and worry about our present burning concerns?

The difficulty is that if we don't leave them alone, if we don't project the battle over our values absurdly into the future and start dealing with the shape of our conflict as it will look when transformed by many decades of time and technological change, we may well lose the political freedom of action to solve these problems non-violently -- or to handle any others either. We will have "a wolf by the ears." We wish the leaders of 1776 had envisioned and taken seriously the problems of 1860, because in 1776 they were still reasonable people who could talk to each other and effectively work out a compromise. By 1860 that option was no longer available. The problem is that when these kinds of problems eventually stop being "academic," when they stop being the dreams of intellectuals and become burning issues for millions of real people, the fire burns too hot. Too many powerful people choose to "take a wolf by the ears". This wolf may well consume the entire political and legal system and make it impossible to handle that problem or any other, until the only option left to restore the body politic is civil war. Once that happens everyone will fervently wish they could go back to the time when the battles were "merely academic".

I worked out this story around 2003, because starting in 1998 I had wanted to have a name to give to a nameless anxiety (in between, I thrashed around for quite a while figuring out which historical image I believed in the most). When I was sure, I considered going to Krugman to use this story to fuel a temper tantrum about how he absolutely had to stop ignoring the geeks who tried to talk to him about "freedom." But I was inhibited: I was afraid the whole argument would come across as intellectually suspect and emotionally manipulative. Besides, the immediate danger this story predicted -- that politics would devolve into 1830's style one-issue paralysis -- seemed a bit preposterous in 2003. Krugman wasn't happy about the 2002 election, but it wasn't that bad. But now I feel some remorse in the other direction: it has gotten worse faster than I ever dreamed it would. I didn't predict what has been happening exactly. I was very focussed on tech, so I didn't expect the politicians in the service of the powerful people with "a wolf by the ears" to be funded by the oldest old economy powers imaginable -- banking and oil. That result isn't incompatible with this argument: that very traditional capitalism should gain an unprecedented brutality just when the new economy is promising new freedoms, is, this line of reasoning predicts, exactly what you should expect. I'm afraid now that Krugman will be mad at me for not bothering him in 2003, because he would have wanted the extra political freedom of action more than he would have resented the very improper intellectual argument.

Rebecca: Now that I've laid the groundwork, it is much easier for me to answer Nick and Helder. Both of you are essentially telling me that I'm being unreasonable and obnoxious. I will break dramatically with Stallman by completely conceding this objection across the board. I am being unreasonably obnoxious. However, there is a general method to this madness: as I explained in the image above, I am essentially pushing values that will make sense in a few decades, and pulling them back to the current time, admittedly somewhat inappropriately. The main reason I think it is important to do this is not because I think the values I am promoting should necessarily apply in an absolute way right now (as Stallman would say) but instead because it is a lot easier to start this fight now than to deal with it later. The reason to fight now is exactly because the opponents are still reasonable, whereas they might not be later. Unlike Stallman, I want to emphasize my respect (and gratitude) for reasonable objections to my position. My opponents are unlikely to shoot me, which is not a priviledge to be taken for granted, and one I want to take advantage of while I have it.

To address the specifics of your objections: Helder complained that companies needed the tactics I called "exploitation of artificial scarcity" to recoup their original investment -- if that wasn't allowed, the service wouldn't exist at all, which would be worse. Nick objected that 80 or 90% of Facebook's planned revenue was from essentially similar sources as Google's, so why should I complain just because of the other 10 or 20%? That was what I was complaining about -- that a portion of their revenue comes from closing their platform and taxing developers -- but that is only a small part of Ms. Sandberg's diversified revenue plans, and I admit that the rest is fairly logically indistinguishable from Google's strategy. In both cases it can easily be argued I am taking an extremely unreasonable hard line.

Let's delve into a dissection of how unreasonable I'm being. In both cases the unreasonableness comes from a problem with my general argument: I said that Mark Zuckerberg is not a capitalist, that is to say, he is not raising capital to buy physical objects that make his workers more productive -- but that is not entirely true. Facebook's data centers are expensive, and they are necessary to allow his employees to do their work.

The best story on this subject might also be the exception to prove the rule. The most "capitalist" story about a tech mogul's start is the account of how Larry & Sergey began by maxing out their credit cards to buy a terabyte of disk (http://books.google.com/books?id=UVz06fnwJvUC&pg=PA6#v=onepage&q&f=false) This story could have been written by Horatio Alger -- it so exactly follows the script of a standard capitalist's start. But for all that, L&S did not make all the standard capitalist noise. I was a fan of Google very early, and may even have pulled data from their original terabyte, and I never heard about how they needed to put restrictions on me to recoup their investment. A year or so later when I talked to Googlers at their recruiting events, I thought they were almost bizarrely chipper about their total lack of revenue strategy. Yet they got rich anyway. And now that same terabyte costs less than $100.

That last is the key point: it is not that the investments aren't significant and need to be recouped. It is that their size is shrinking exponentially. In the previous section, I emphasized the enormous transformative effect of decades of exponential improvement in technology, and the importance of extrapolating one's values forward through those decades, even if that means making assertions that currently seem absurd. The investments that need to be recouped are real and significant, but they are also shrinking, at an exponential rate. So the economic basis for the assertion of a right to restrict people's freedom of opportunity in order to recoup investment is temporary at best. And, as I described in the last part, asserting prerogatives on the basis of scarcity which is now real but will soon be artificial is ... dangerous. Even if you honestly think that you will change with changing times, you may find to your sincere horror that when the time comes to make a new choice, you no longer have the option. Your choices will be dictated by the company you keep. I didn't say it earlier, but one of the things that worries me the most about Facebook is that they seem to have gotten in bed with Goldman Sachs. The idea of soon-to-be multibillionare tech moguls taking lessons in political tactics from Lloyd Blankfein doesn't make me happy.

I am glad that you objected, and gave me licence to take the space to explain this more carefully, because actually my point is more subtle and nuanced than my original account -- which I was oversimplifying to save space -- suggested. (Lessig told me I had to write an account that fit in five pages in order to hope to be heard, to which I reacted with some despair. I can't! There is more than five pages worth of complexity to this problem! If I try to reduce beyond a certain point I burn the sauce. You are watching me struggle in public with this problem.)

There is another part of the mythology of "the end of capitalism" that I should take the time to disavow. The mythology talks as if there is one clear historical moment when an angel of annunciation appears and declares that a new social order has arrived. In reality it isn't like that. It may seem like that in history books when a few pages cover the forty-five years between the time Jefferson scratched out his denunciation of slavery in the Declaration of Independence, and when he wrote the "firebell in the night" letter. But in real, lived, life, forty-five years are most of an adult lifetime. When Jefferson wrote "justice is in one scale, self-preservation in the other," could he point to a particular moment in the previous forty-five years when the hand of justice had moved the weight to the other side of the scale? There was no one moment: just undramatic but steady exponential growth in the productivity of the industrial life whose moral inferiority seemed so obvious four decades earlier. He hadn't been paying attention, no clarion call was blown at the moment of transition (if such a moment even existed), so when he heard the alarm that woke him up to how much the world had changed, it was too late.

In a similar way, I think the only clear judgement we can make now is that we are in the middle of a transition. There was some point in time when disk drives were so expensive and the data stored on them so trivial that the right of their owners to recoup their investment clearly outweighed all other concerns. There will be some other point, decades from now, when the disk drives are so cheap and the data on them so crucial to the livelihood of their users and the health of the economy, that the right to "software freedom" will clearly outweigh the rights of the owner of the hardware. There will be some point clearly "too early" to fight for new freedoms, and some point also clearly "too late." In between these two points in time? Merely a long, slow, steady pace of change. In that time the hand of justice may refuse to put the weight on either side of the scale, no matter how much we plead with her for clarity. We may live our whole lives between two eras, where no judgement can be made black or white, where everything is grey.

But people want solid judgement: they want to know what is right and wrong. This greyness is dangerous, for it opens a vacuum of power eagerly filled by the worst sorts, causes a nameless anxiety, and induces political panic. So what can you do? I think it is impossible to make black-and-white judgements about which era's values should apply. But one can say with certainty that it is desirable to preserve the freedom of political action that will make it possible to defend the values of a new era at the point when it becomes unequivocally clear that that fight is appropriate. I'm really not very upset if companies do whatever it takes to recoup their initial investment -- as long as it's temporary. But what guarantee do I have that if Facebook realizes its 50 billion market capitalization, they won't use that money to buy politicians to justify continuing their practices indefinitely? Their association with Goldman doesn't reassure me on that score. I trust Google more to allow, and even participate in, honest political discussion. That is the issue which I'm really worried about. The speed and effectiveness with which companies are already buying the political discourse has taken me by surprise, even though I had reason to predict it. When powerful people "have a wolf by the ears" they can become truly terrifying.

Rebecca: You could have a point that this kind of argument isn't as unorthodox as it once was. After all, plenty of real economists have been talking about the "new economy" -- Peter Drucker in "Beyond the Information Revolution" (linked above), Hal Varian in "Information Rules", Larry Summers in a speech "The New Wealth of Nations", even Krugman in his short essay "The Dynamo and the Microchip", and a bunch of younger economists surveyed in David Brooks's recent editorial "The Protocol Society." But I don't share Brooks's satisfaction in the observation "it is striking how [these "new economy" theorists] are moving away from mathematical modeling and toward fields like sociology and anthropology." There is a sense that my attitude is now more orthodox than the orthodoxy -- though the argument I sketched here is not a mathematical model, it was very much designed and intended to be turned into one, and I am vehemently in agreement with Krugman's attitude that nothing less than math is good enough. Economics is supposed to be a science where mathematical discipline forces intellectual honesty and provides a bulwark of defense against corruption.

I'm in shock that this crop of "new economy talk" is so loose, sloppy and journalistic ... and because it is so intellectually sloppy, it is hard even to tell whether it is corrupt or not. For instance, though I liked the historical observations and the conclusions drawn from them in Drucker's 1999 essay as much as anything I've read, his paean to the revolutionary effects of e-commerce reads so much like dot.com advertising it is almost embarrassing. Though, to be fair, there are some hints at the essay's conclusion of a consciousness that an industrial revolution isn't just about being sprinkled with technological fairy dust magic, but also involves some aspect of painful social upheaval -- even so, his story is so strangely upbeat, especially since, given his clearly deep understanding of historical thinking, he should have known better ... one wonders whom he was trying not to offend. Similarly, can we trust Summer's purported genius or do his millions in pay from various banks, um, influence his thinking? and it goes on... Krugman is about the only one left I'm sure I can trust. People who do this for a living should be doing better than this! Even though I understand Lessig's point about my intellectual radicalism, it's hard for me to want to follow it, because some part of me just wants to challenge these guys to show enough intellectual rigor to prove that I can trust them.

To be fair, I admit part of Brooks's point that there is something "anthropological" about a new economy: it tends to drive everyone mad. Think about the new industrial rich of the nineteenth century -- dressed to the nines like pseudo-aristocrats, top hat, cane, affected accent, and maybe a bought marriage to get themselves a title too -- they were cuckoo like clocks! Deep, wrenching, technologically-driven change does that to people. But just because it is madness doesn't mean it doesn't have method to it amenable to mathematical modeling. Krugman wrote (http://pkarchive.org/personal/incidents.html) that when he was young, Azimov's "Foundation Trilogy" inspired him to dream of growing up to be a "psychohistorian who use[s his] understanding of the mathematics of society to save civilization as the Galactic Empire collapses" but he said "Unfortunately, there's no such thing (yet)." Do you think he could be tempted with the possibility of a real opportunity to be a "psychohistorian?"

I never meant for this to be a fight I pursue on my own. The whole reason I translated it into an economic and historical language is that I wanted to convince the people who do this for a living to take it up for me. I can't afford to fight alone: I don't have the time to spend caught up in political arguments, nor can I afford to make enemies of people I might want to work for. I'm making these arguments here mostly because having a record of a debate with other tech people will help convince intellectuals of my seriousness. I'm having some difficulty getting you to understand, but I think I would have a terribly uphill battle trying to convince intellectuals that I am not "crying wolf" -- they have just heard this kind of argument misused too many times before. I have to admit that I am crying wolf, but the reason I'm doing it is because this time there really is a wolf!

Piaw: Here's the thing, Rebecca: it wasn't possible to have that argument about freedom/slavery in 1776. The changes brought about later made it possible to have that argument much later. The civil war was horrifying, but I really am not sure if it was possible to change the system earlier.

Ruchira: Hi Rebecca,

I haven't yet read this long conversation. But if you're not already familiar with the concepts of rivalrous vs nonrivalrous and excludable vs nonexcludable

http://en.wikipedia.org/wiki/Rivalry_(economics)

these terms might help connect you with what others have thought about the issues you're talking about. See in particular the "Possible solutions" under Public goods:

http://en.wikipedia.org/wiki/Public_good Daniel Stoddart: I've said it before and I'll say it again: I wouldn't be so quick to count Google out of social. Oh, I know it's cool to diss Buzz like Scoble has been doing for a while now, saying that he has more followers on Quora. But that's kind of an apples and oranges comparison.

Ruchira: Rebecca: Okay, now I have read the long conversation. I do think you have an important point but I haven't digested it enough to form an opinion (which would require judging how it interconnects with other important issues). Just a couple of tangential thoughts:

1) If you fear the loss of freedom, watch out for the military-industrial complex. You've elsewhere described some of the benefits from it, but this is precisely why you shouldn't be lulled into a false sense of comfort by these benefits, just as you're thinking others should not be lulled into a false sense of comfort about the issues you're describing. Think about the long-term consequences of untouchable and unaccountable defense spending, and about the interlocking attributes of the status quo that keep it untouchable and unaccountable. They are fundamentally interconnected with information hiding and lack of transparency.

2) There exists a kind of psychohistory: cliodynamics. http://cliodynamics.info/ As far as I know it's not yet sufficiently developed to apply to the future, though.

Ruchira: Rebecca: On that note, I wonder what you think of Noam Scheiber's article "Why Wikileaks Will Kill Big Business and Big Government" http://www.tnr.com/article/politics/80481/game-changer He's certainly thinking about how technology will cause massive changes in how society is organized.

Helder: (note: I didn't read the whole thing with full attention) In the case of some closed systems. the cost of making it open (and lack business justification for that) and a general necessity to protect the business usually outweighs the need of return on investment by far. So it's not all about ROE.

Also, society's technology development and the shrinking size on capital needs for new business (e.g. terabyte cost), don't usually favors closed system business in the long run, it probably only weakens it. You can have a walled garden, but as the outside ground level goes up, the wall gets shorter and shorter. Just look at how the operating system is increasingly less relevant as most action gravitates towards the browser. Another example (perhaps to be seen?) is the credit card industry as I mentioned in my first comment.

Rebecca: Thanks for reading this long, long post and giving me feedback!

Ruchira: Helder: Facebook makes the wall shorter for its developers (I'm sure Zynga think they've grown wealth due to Facebook). This directly caused an outcry over privacy (the walled garden is not walled any more).

Rebecca: Hope you find it food for thought! You might also be interested in David Singh Grewal's Network Power http://amzn.to/h72nNJ It discusses a lot of relevant issues, and doesn't assume a lot of background (since it's targeted at multiple disciplines), so I found it very helpful, as an outsider like you. After that, you might (or might not) become interested in the coordination problem--if you do, Richard Tuck's free riding http://amzn.to/f9goyT may be of interest.

Rebecca: Thanks, Ruchira, for the links.

This is an archive of the Jonathan Shapiro's "Retrospective Thoughts on BitC" that seems to have disappeared from the internet; at the time, BitC was aimed at the same niche as Rust

Jonathan S. Shapiro shap at eros-os.org
Fri Mar 23 15:06:41 PDT 2012

By now it will be obvious to everyone that I have stopped work on BitC. An explanation of why seems long overdue.

One answer is that work on Coyotos stopped when I joined Microsoft, and the work that I am focused on now doesn't really require (or seem to benefit from) BitC. As we all know, there is only so much time to go around in our lives. But that alone wouldn't have stopped me entirely.

A second answer is that BitC isn't going to work in its current form. I had hit a short list of issues that required a complete re-design of the language and type system followed by a ground-up new implementation. Experience with the first implementation suggested that this would take quite a while, and it was simply more than I could afford to take on without external support and funding. Programming language work is not easy to fund.

But the third answer may of greatest interest, which is that I no longer believe that type classes "work" in their current form from the standpoint of language design. That's the only important science lesson here.

In the large, there were four sticking points for the current design:

1. The compilation model.
2. The insufficiency of the current type system w.r.t. by-reference and reference types.
3. The absence of some form of inheritance.
4. The instance coherence problem.

The first two issues are in my opinion solvable, thought the second requires a nearly complete re-implementation of the compiler. The last (instance coherence) does not appear to admit any general solution, and it raises conceptual concerns about the use of type classes for method overload in my mind. It's sufficiently important that I'm going to deal with the first three topics here and take up the last as a separate note.

Inheritance is something that people on the BitC list might (and sometimes have) argue about strongly. So a few brief words on the subject may be relevant.

Prefacing Comments on Objects, Inheritance, and Purity

BitC was initially designed as an [imperative] functional language because of our focus on software verification. Specification of the typing and semantics of functional languages is an area that has a lot of people working on it. We (as a field) kind of know how to do it, and it was an area where our group at Hopkins didn't know very much when we started. Software verification is a known-hard problem, doing it over an imperative language was already a challenge, and this didn't seem like a good place for a group of novice language researchers to buck the current trends in the field. Better, it seemed, to choose our battles. We knew that there were interactions between inheritance and inference, and it appeared that type classes with clever compilation could achieve much of the same operational results. I therefore decided early not to include inheritance in the language.

To me, as a programmer, the removal of inheritance and objects was a very reluctant decision, because it sacrificed any possibility of transcoding the large body of existing C++ code into a safer language. And as it turns out, you can't really remove the underlying semantic challenges from a successful systems language. A systems language requires some mechanism for existential encapsulation. The mechanism which embodies that encapsulation isn't really the issue; once you introduce that sort of encapsulation, you bring into play most of the verification issues that objects with subtyping bring into play, and once you do that, you might as well gain the benefit of objects. The remaining issue, in essence, is the modeling of the Self type, and for a range of reasons it's fairly essential to have a Self type in a systems language once you introduce encapsulation. So you end up pushed in to an object type system at some point in any case. With the benefit of eight years of hindsight, I can now say that this is perfectly obvious!

I'm strongly of the opinion that multiple inheritance is a mess. The argument pro or con about single inheritance still seems to me to be largely a matter of religion. Inheritance and virtual methods certainly aren't the only way to do encapsulation, and they may or may not be the best primitive mechanism. I have always been more interested in getting a large body of software into a safe, high-performance language than I am in innovating in this area of language design. If transcoding current code is any sort of goal, we need something very similar to inheritance.

The last reason we left objects out of BitC initially was purity. I wanted to preserve a powerful, pure subset language - again to ease verification. The object languages that I knew about at the time were heavily stateful, and I couldn't envision how to do a non-imperative object-oriented language. Actually, I'm still not sure I can see how to do that practically for the kinds of applications that are of interest for BitC. But as our faith in the value of verification declined, my personal willingness to remain restricted by purity for the sake of verification decayed quickly.

The other argument for a pure subset language has to do with advancing concurrency, but as I really started to dig in to concurrency support in BitC, I came increasingly to the view that this approach to concurrency isn't a good match for the type of concurrent problems that people are actually trying to solve, and that the needs and uses for non-mutable state in practice are a lot more nuanced than the pure programming approach can address. Pure subprograms clearly play an important role, but they aren't enough.

And I still don't believe in monads. :-)

Compilation Model

One of the objectives for BitC was to obtain acceptable performance under a conventional, static separate compilation scheme. It may be short-sighted on my part, but complex optimizations at run-time make me very nervous from the standpoint of robustness and assurance. I understand that bytecode virtual machines today do very aggressive optimizations with considerable success, but there are a number of concerns with this:

• For a robust language, we want to minimize the size and complexity of the code that is exempted from type checking and [eventual] verification. Run-time code is excepted in this fashion. The garbage collector taken alone is already large enough to justify assurance concerns. Adding a large and complex optimizer to the pile drags the credibility of the assurance story down immeasurably.
• Run-time optimization has very negative consequences for startup times
• especially in the context of transaction processing. Lots of hard data on this from IBM (in DB/2) and others. It is one of the reasons that "Java in the database" never took hold. As the frequency of process and component instantiation in a system rises, startup delays become more and more of a concern. Robust systems don't recycle subsystems.
• Run-time optimization adds a huge amount of space overhead to the run-time environment of the application. While the code of the run-time compiler can be shared, the state of the run-time compiler cannot, and there is quite a lot of that state.
• Run-time optimization - especially when it is done "on demand" - introduces both variance and unpredictability into performance numbers. For some of the applications that are of interest to me, I need "steady state" performance. If the code is getting optimized on the fly such that it improves by even a modest constant factor, real-time scheduling starts to be a very puzzling challenge.
• Code that is produced by a run-time optimizer is difficult to share across address spaces, though this probably isn't solved very well by * other* compilation approaches models either.
• If run-time optimization is present, applications will come to rely on it for performance. That is: for social reasons, "optional" run-time optimization tends to quickly become required.

To be clear, I'm not opposed to continuous compilation. I actually think it's a good idea, and I think that there are some fairly compelling use-cases. I do think that the run-time optimizer should be implemented in a strongly typed, safe language. I also think that it took an awfully long time for the hotspot technology to stabilize, and that needs to be taken as a cautionary tale. It's also likely that many of the problems/concerns that I have enumerated can be solved - but probably not * soon*. For the applications that are most important to me, the concerns about assurance are primary. So from a language design standpoint, I'm delighted to exploit continuous compilation, but I don't want to design a language that requires continuous compilation in order to achieve reasonable baseline performance.

The optimizer complexity issue, of course, can be raised just as seriously for conventional compilers. You are going to optimize somewhere. But my experience with dynamic translation tells me that it's a lot easier to do (and to reason about) one thing at a time. Once we have a high-confidence optimizer in a safe language, then it may make sense to talk about integrating it into the run-time in a high-confidence system. Until then, separation of concerns should be the watch-word of the day.

Now strictly speaking, it should be said that run-time compilation actually isn't necessary for BitC, or for any other bytecode language. Run-time compilation doesn't become necessary until you combine run-time loading with compiler-abstracted representations (see below) and allow types having abstracted representation to appear in the signatures of run-time loaded libraries. Until then it is possible to maintain a proper phase separation between code generation and execution. Read on - I'll explain some of that below.

In any case, I knew going in that strongly abstracted types would raise concerns on this issue, and I initially adopted the following view:

• Things like kernels can be whole-program compiled. This effectively eliminates the run-time optimizer requirement.
• Things like critical system components want to be statically linked anyway, so they can also be dealt with as whole-program compilation problems.
• For everything else, I hoped to adopt a kind of "template expansion" approach to run-time compilation. This wouldn't undertake the full complexity of an optimizer; it would merely extend run-time linking and loading to incorporate span and offset resolution. It's still a lot of code, but it's not horribly complex code, and it's the kind of thing that lends itself to rigorous - or even formal - specification.

It took several years for me to realize that the template expansion idea wasn't going to produce acceptable baseline performance. The problem lies in the interaction between abstract types, operator overloading, and inlining.

Compiler-Abstracted Representations vs. Optimization

Types have representations. This sometimes seems to make certain members of the PL community a bit uncomfortable. A thing to be held at arms length. Very much like a zip-lock bag full of dog poo (insert cartoon here). From the perspective of a systems person, I regret to report that where the bits are placed, how big they are, and their assemblage actually does matter. If you happen to be a dog owner, you'll note that the "bits as dog poo" analogy is holding up well here. It seems to be the lot of us systems people to wade daily through the plumbing of computational systems, so perhaps that shouldn't be a surprise. Ahem.

In any case, the PL community set representation issues aside in order to study type issues first. I don't think that pragmatics was forgotten, but I think it's fair to say that representation issues are not a focus in current, mainstream PL research. There is even a school of thought that views representation as a fairly yucky matter that should be handled in the compiler "by magic", and that imperative operations should be handled that way too. For systems code that approach doesn't work, because a lot of the representations and layouts we need to deal with are dictated to us by the hardware.

In any case, types do have representations, and knowledge of those representations is utterly essential for even the simplest compiler optimizations. So we need to be a bit careful not to abstract types* too * successfully, lest we manage to break the compilation model.

In C, the "+" operator is primitive, and the compiler can always select the appropriate opcode directly. Similarly for other "core" arithmetic operations. Now try a thought experiment: suppose we take every use of such core operations in a program and replace each one with a functionally equivalent procedure call to a runtime-implemented intrinsic. You only have to do this for user operations - addition introduced by the compiler to perform things like address arithmetic is always done on concrete types, so those can still be generated efficiently. But even though it is only done for user operations, this would clearly harm the performance of the program quite a lot. You can recover that performance with a run-time optimizer, but it's complicated.

In C++, the "+" operator can be overloaded. But (1) the bindings for primitive types cannot be replaced, (2) we know, statically, what the bindings and representations are for the other types, and (3) we can control, by means of inlining, which of those operations entail a procedure call at run time. I'm not trying to suggest that we want to be forced to control that manually. The key point is that the compiler has enough visibility into the implementation of the operation that it is possible to inline the primitive operators (and many others) at static compile time.

Why is this possible in C++, but not in BitC?

In C++, the instantiation of an abstract type (a template) occurs in an environment where complete knowledge of the representations involved is visible to the compiler. That information may not all be in scope to the programmer, but the compiler can chase across the scopes, find all of the pieces, assemble them together, and understand their shapes. This is what induces the "explicit instantiation" model of C++. It also causes a lot of "internal" type declarations and implementation code to migrate into header files, which tends to constrain the use of templates and increase the number of header file lines processed for each compilation unit - we measured this at one point on a very early (pre templates) C++ product and found that we processed more than 150 header lines for each "source" line. The ratio has grown since then by at least a factor of ten, and (because of templates) quite likely 20.

It's all rather a pain in the ass, but it's what makes static-compile-time template expansion possible. From the compiler perspective, the types involved (and more importantly, the representations) aren't abstracted at all. In BitC, both of these things are abstracted at static compile time. It isn't until link time that all of the representations are in hand.

Now as I said above, we can imagine extending the linkage model to deal with this. All of that header file information is supplied to deal with * representation* issues, not type checking. Representation, in the end, comes down to sizes, alignments, and offsets. Even if we don't know the concrete values, we do know that all of those are compile-time constants, and that the results we need to compute at compile time are entirely formed by sums and multiples of these constants. We could imagine dealing with these as opaque constants at static compile time, and filling in the blanks at link time. Which is more or less what I had in mind by link-time template expansion. Conceptually: leave all the offsets and sizes "blank", and rely on the linker to fill them in, much in the way that it handles relocation.

The problem with this approach is that it removes key information that is needed for optimization and registerization, and it doesn't support inlining. In BitC, we can and do extend this kind of instantiation all the way down to the primitive operators! And perhaps more importantly, to primitive accessors and mutators. The reason is that we want to be able to write expressions like "a + b" and say "that expression is well-typed provided there is an appropriate resolution for +:('a,'a)->'a". Which is a fine way to type the operation, but it leaves the representation of 'a fully abstracted. Which means that we cannot see when they are primitive types. Which means that we are exactly (or all too often, in any case) left in the position of generating all user-originated "+" operations as procedure calls. Now surprisingly, that's actually not the end of the world. We can imagine inventing some form of "high-level assembler" that our static code generator knows how to translate into machine code. If the static code generator does this, the run-time loader can be handed responsibility for emitting procedure calls, and can substitute intrinsic calls at appropriate points. Which would cause us to lose code sharing, but that might be tolerable on non-embedded targets.

Unfortunately, this kind of high-level assembler has some fairly nasty implications for optimization: First, we no longer have any idea what the * cost* of the "+" operator is for optimization purposes. We don't know how many cycles that particular use of + will take, but more importantly, we don't know how many bytes of code it will emit. And without that information there is a very long list of optimization decisions that we can no longer make at static compile time. Second, we no longer have enough information at static code generation time to perform a long list of basic register and storage optimizations, because we don't know which procedure calls are actually going to use registers.

That creaking and groaning noise that you are hearing is the run-time code generator gaining weight and losing reliability as it grows. While the impact of this mechanism actually wouldn't be as bad as I am sketching - because a lot of user types aren't abstract - the complexity of the mechanism really is as bad as I am proposing. In effect we end up deferring code generation and optimization to link time. That's an idea that goes back (at least) to David Wall's work on link time register optimization in the mid-1980s. It's been explored in many variants since then. It's a compelling idea, but it has pros and cons.

What is going on here is that types in BitC are too successfully abstracted for static compilation. The result is a rather large bag of poo, so perhaps the PL people are on to something.:-)

Two Solutions

• The most obvious solution - adopted by C++ - is to redesign the language so that representation issues are not hidden from the compiler. That's actually a solution that is worth considering. The problem in C++ isn't so much the number of header file lines per source line as it is the fact that the C preprocessor requires us to process those lines de novo for each compilation unit. BitC lacks (intentionally) anything comparable to the C preprocessor.
• The other possibility is to shift to what might be labeled "install time compilation". Ship some form of byte code, and do a static compilation at install time. This gets you back all of the code sharing and optimization that you might reasonably have expected from the classical compilation approach, it opens up some interesting design point options from a systems perspective, and (with care) it can be retrofitted to existing systems. There are platforms today (notably cell phones) where we basically do this already.

The design point that you don't want to cross here is dynamic loading where the loaded interface carries a type with an abstracted representation. At that point you are effectively committing yourself to run-time code generation, though I do have some ideas on how to mitigate that.

Conclusion Concerning Compilation Model

If static, separate compilation is a requirement, it becomes necessary for the compiler to see into the source code across module boundaries whenever an abstract type is used. That is: any procedure having abstract type must have an exposed source-level implementation.

The practical alternative is a high-level intermediate form coupled with install-time or run-time code generation. That is certainly feasible, but it's more that I felt I could undertake.

That's all manageable and doable. Unfortunately, it isn't the path we had taken on, so it basically meant starting over.

Insufficiency of the Type System

At a certain point we had enough of BitC working to start building library code. It may not surprise you that the first thing we set out to do in the library was IO. We found that we couldn't handle typed input within the type system. Why not?

Even if you are prepared to do dynamic allocation within the IO library, there is a level of abstraction at which you need to implement an operation that amounts to "inputStream.read(someObject: ByRef mutable 'a)" There are a couple of variations on this, but the point is that you want the ability at some point to move the incoming bytes into previously allocated storage. So far so good.

Unfortunately, in an effort to limit creeping featurism in the type system, I had declared (unwisely, as it turned out) that the only place we needed to deal with ByRef types was at parameters. Swaroop took this statement a bit more literally than I intended. He noticed that if this is really the only place where ByRef needs to be handled, then you can internally treat "ByRef 'a" as 'a, merely keeping a marker on the parameter's identifier record to indicate that an extra dereference is required at code generation time. Which is actually quite clever, except that it doesn't extend well to signature matching between type classes and their instances. Since the argument type for read is ByRef 'a, InputStream is such a type class.

So now we were faced with a couple of issues. The first was that we needed to make ByRef 'a a first-class type within the compiler so that we could unify it, and the second was that we needed to deal with the implicit coercion issues that this would entail. That is: conversion back and forth between ByRef 'a and 'a at copy boundaries. The coercion part wasn't so bad; ByRef is never inferred, and the type coercions associated with ByRef happen in exactly the same places that const/mutable coercions happen. We already had a cleanly isolated place in the type checker to deal with that.

But even if ByRef isn't inferred, it can propagate through the code by unification. And that causes safety violations! The fact that ByRef was syntactically restricted to appear only at parameters had the (intentional) consequence of ensuring that safety restrictions associated with the lifespan of references into the stack were honored - that was why I had originally imposed the restriction that ByRef could appear only at parameters. Once the ByRef type can unify, the syntactic restriction no longer guarantees the enforcement of the lifespan restriction. To see why, consider what happens in:

  define byrefID(x:ByRef 'a) { return x; }

Something that is supposed to be a downward-only reference ends up getting returned up the stack. Swaroop's solution was clever, in part, because it silently prevented this propagation problem. In some sense, his implementation doesn't really treat ByRef as a type, so it can't propagate. But *because *he didn't treat it as a type, we also couldn't do the necessary matching check between instances and type classes.

It turns out that being able to do this is useful. The essential requirement of an abstract mutable "property" (in the C# sense) is that we have the ability within the language to construct a function that returns the location of the thing to be mutated. That location will often be on the stack, so returning the location is exactly like the example above. The "ByRef only at parameters" restriction is actually very conservative, and we knew that it was preventing certain kinds of things that we eventually wanted to do. We had a vague notion that we would come back and fix that at a later time by introducing region types.

As it turned out, "later" had to be "now", because region types are the right way to re-instate lifetime safety when ByRef types become first class. But adding region types presented two problems (which is why we had hoped to defer them):

• Adding region types meant rewriting the type checker and re-verifying the soundness and completeness of the inference algorithm, and
• It wasn't just a re-write. Regions introduce subtyping. Subtyping and polymorphism don't get along, so we would need to go back and do a lot of study.

Region polymorphism with region subtyping had certainly been done before, but we were looking at subtyping in another case too (below). That was pushing us toward a kinding system and a different type system.

So to fix the ByRef problem, we very nearly needed to re-design both the type system and the compiler from scratch. Given the accumulation of cruft in the compiler, that might have been a good thing in any case, but Swaroop was now full-time at Microsoft, and I didn't have the time or the resources to tackle this by myself.

Conclusion Concerning the Type System

In retrospect, it's hard to imagine a strongly typed imperative language that doesn't type locations in a first-class way. If the language simultaneously supports explicit unboxing, it is effectively forced to deal with location lifespan and escape issues, which makes memory region typing of some form almost unavoidable.

For this reason alone, even if for no other, the type system of an imperative language with unboxing must incorporate some form of subtyping. To ensure termination, this places some constraints on the use of type inference. On the bright side, once you introduce subtyping you are able to do quite a number of useful things in the language that are hard to do without it.

Inheritance and Encapsulation

Our first run-in with inheritance actually showed up in the compiler itself. In spite of our best efforts, the C++ implementation of the BitC compiler had not entirely avoided inheritance, so it didn't have a direct translation into BitC. And even if we changed the code of the compiler, there are a large number of third-party libraries that we would like to be able to transcode. A good many of those rely on [single] inheritance. Without having at least some form of interface (type) inheritance, We can't really even do a good job interfacing to those libraries as foreign objects.

The compiler aside, we also needed a mechanism for encapsulation. I had been playing with "capsules", but it soon became clear that capsules were really a degenerate form of subclassing, and that trying to duck that issue wasn't going to get me anywhere.

I could nearly imagine getting what I needed by adding "ThisType" and inherited interfaces. But the combination of those two features introduces subtyping. In fact, the combination is equivalent (from a type system perspective) to single-inheritance subclassing.

And the more I stared at interfaces, the more I started to ask myself why an interface wasn't just a type class. That brought me up against the instance coherence problem from a new direction, which was already making my head hurt. It also brought me to the realization that Interfaces work, in part, because they are always parameterized over a single type (the ThisType) - once you know that one, the bindings for all of the others are determined by type constructors or by explicit specification.

And introducing SelfType was an even bigger issue than introducing subtypes. It means moving out of System F<: entirely, and into the object type system of Cardelli et al. That wasn't just a matter of re-implementing the type checker to support a variant of the type system we already had. It meant re-formalizing the type system entirely, and learning how to think in a different model.

Doable, but time not within the framework or the compiler that we had built. At this point, I decided that I needed to start over. We had learned a lot from the various parts of the BitC effort, but sometimes you have to take a step back before you can take more steps forward.

Instance Coherence and Operator Overloading

BitC largely borrows its type classes from Haskell. Type classes aren't just a basis for type qualifiers; they provide the mechanism for *ad hoc*polymorphism. A feature which, language purists notwithstanding, real languages actually do need.

The problem is that there can be multiple type class instances for a given type class at a given type. So it is possible to end up with a function like:

define f(x : 'x) {
  ...
  a:int32 + b  // typing fully resolved at static compile time
  return x + x  // typing not resolvable until instantiation
}

Problem: we don't know which instance of "+" to use when 'x instantiates to int32. In order for "+" to be meaningful in a+b, we need a static-compile-time resolution for +:(int32, int32)->int32. And we get that from Arith(int32). So far so good. But if 'x is instantiated to int32, we will get a type class instance supplied by the caller. The problem is that there is no way to guarantee that this is the same instance of Arith(int32) that we saw before.

The solution in Haskell is to impose the ad hoc rule that you can only instantiate a type class once for each unique type tuple in a given application. This is similar to what is done in C++: you can only have one overload of a given global operator at a particular type. If there is more than one overload at that type, you get a link-time failure. This restriction is tolerable in C++ largely because operator overloading is so limited:

1. The set of overloadable operators is small and non-extensible.
2. Most of them can be handled satisfactorily as methods, which makes their resolution unambiguous.
3. Most of the ones that can't be handled as methods are arithmetic operations, and there are practical limits to how much people want to extend those.
4. The remaining highly overloaded global operators are associated with I/O. These could be methods in a suitably polymorphic language.

In languages (like BitC) that enable richer use of operator overloading, it seems unlikely that these properties would suffice.

But in Haskell and BitC, overloading is extended to type properties as well. For example, there is a type class "Ord 'a", which states whether a type 'a admits an ordering. Problem: most types that admit ordering admit more than one! The fact that we know an ordering exists really isn't enough to tell us which ordering to use. And we can't introduce two orderings for 'a in Haskell or BitC without creating an instance coherence problem. And in the end, the instance coherence problem exists because the language design performs method resolution in what amounts to a non-scoped way.

But if nothing else, you can hopefully see that the heavier use of overloading in BitC and Haskell places much higher pressure on the "single instance" rule. Enough so, in my opinion, to make that rule untenable. And coming from the capability world, I have a strong allergy to things that smell like ambient authority.

Now we can get past this issue, up to a point, by imposing an arbitrary restriction on where (which compilation unit) an instance can legally be defined. But as with the "excessively abstract types" issue, we seemed to keep tripping on type class issues. There are other problems as well when multi-variable type classes get into the picture.

At the end of the day, type classes just don't seem to work out very well as a mechanism for overload resolution without some other form of support.

A second problem with type classes is that you can't resolve operators at static compile time. And if instances are explicitly named, references to instances have a way of turning into first-class values. At that point the operator reference can no longer be statically resolved at all, and we have effectively re-invented operator methods!

Conclusion about Type Classes and Overloading:

The type class notion (more precisely: qualified types) is seductive, but absent a reasonable approach for instance coherence and lexical resolution it provides an unsatisfactory basis for operator overloading. There is a disturbingly close relationship between type class instances and object instances that needs further exploration by the PL community. The important distinction may be pragmatic rather than conceptual: type class instances are compile-time constants while object instances are run-time values. This has no major consequences for typing, but it leads to significant differences w.r.t. naming, binding, and [human] conceptualization.

There are unresolved formal issues that remain with multi-parameter type classes. Many of these appear to have natural practical solutions in a polymorphic object type system, but concerns of implementation motivate kinding distinctions between boxed and unboxed types that are fairly unsatisfactory.

Wrapping Up

The current outcome is extremely frustrating. While the blind spots here were real, we were driven by the requirements of the academic research community to spend nearly three years finding a way to do complete inference over mutability. That was an enormous effort, and it delayed our recognition that we were sitting on the wrong kind of underlying type system entirely. While I continue to think that there is some value in mutability inference, I think it's a shame that a fairly insignificant wart in the original inference mechanism managed to prevent larger-scale success in the overall project for what amount to political reasons. If not for that distraction, I think we would probably have learned enough about the I/O and the instance coherency issues to have moved to a different type system while we still had a group to do it with, and we would have a working and useful language today.

The distractions of academia aside, it is fair to ask why we weren't building small "concept test" programs as a sanity check of our design. There are a number answers, none very satisfactory:

• Research languages can adopt simplifications on primitive types (notably integers) that systems languages cannot. That's what pushed us into type classes in the first place, we new that polymorphism over unboxed types hadn't seen a lot of attention in the literature, and we knew that mutability inference had never been done. We had limited manpower, so we chose to focus on those issues first.
• We knew that parametric polymorphism and subtyping didn't get along, so we wanted to avoid that combination. Unfortunately, we avoided subtypes too well for too long, and they turned out to be something unavoidable.
• For the first several years, we were very concerned with software verification, which also drove us strongly away from object-based languages and subtyping. That blinded us.
• Coming to language design as "systems" people, working in a department that lacked deep expertise and interest in type systems, there was an enormous amount of subject matter that we needed to learn. Some of the reasons for our failure are "obvious" to people in the PL community, but others are not. Our desire for a "systems" language drove us to explore the space in a different way and with different priorities than are common in the PL community.

I think we did make some interesting contributions. We now know how to do (that is: to implement) polymorphism over unboxed types with significant code sharing, and we understand how to deal with inferred mutability. Both of those are going to be very useful down the road. We have also learned a great deal about advanced type systems.

In any case, BitC in its current form clearly needs to be set aside and re-worked. I have a fairly clear notion about how I would approach continuing this work, but that's going to have to wait until someone is willing to pay for all this.

This is a transcript of the Kara Swisher / Jack Dorsey interview from 2/12/2019, made by parsing the original Tweets because I wanted to be able to read this linearly. There's a "moment" that tries to track this, but since it doesn't distinguish between sub-threads in any way, you can't tell the difference between end of a thread and a normal reply. This linearization of the interview marks each thread break with a page break and provides some context from upthread where relevant (in grey text).

Kara: Here in my sweatiest @soulcycle outfit for my Twitterview with @jack with @Laur_Katz at the ready @voxmediainc HQ. Also @cheezit acquired. #karajack

Kara: Oh hai @jack. Let’s set me set the table. First, I am uninterested in beard amulets or weird food Mark Zuckerberg served you (though WTF with both for my personal self). Second, I would appreciate really specific answers.

Jack: Got you. Here’s my setup. I work from home Tuesdays. In my kitchen. Tweetdeck. No one here with me, and no one connected to my tweetdeck. Just me focused on your questions!

Kara: Great, let's go

Jack: Ready

Kara: As @ashleyfeinberg wrote: “press him for a clear, unambiguous example of nearly anything, and Dorsey shuts down.” That is not unfair characterization IMHO. Third, I will thread in questions from audience, but to keep this non chaotic, let’s stay in one reply thread.

Jack: Deal

Kara: To be clear with audience, there is not a new event product, a glass house, if you will, where people can see us but not comment. I will ask questions and then respond to @jack answers. So it could be CHAOS.

Jack: To be clear, we’re interested in an experience like this. Nothing built yet. This gives us a sense of what it would be like, and what we’d need to focus on. If there’s something here at all!

Kara: Well an event product WOULD BE NICE. See my why aren't you moving faster trope.

Kara: Overall here is my mood and I think a lot of people when it comes to fixing what is broke about social media and tech: Why aren’t you moving faster? Why aren’t you moving faster? Why aren’t you moving faster?

Jack: A question we ask ourselves all the time. In the past I think we were trying to do too much. We’re better at prioritizing by impact now. Believe the #1 thing we should focus on is someone’s physical safety first. That one statement leads to a lot of ramifications.

Kara: It seems twitter has been stuck in a stagnant phase of considering/thinking about the health of the conversation, which plays into safety, for about 18-24 months. How have you made actual progress? Can you point me to it SPECIFICALLY?

Kara: You know my jam these days is tech responsibility. What grade do you gave Silicon Valley? Yourself?

Jack: Myself? C. We’ve made progress, but it has been scattered and not felt enough. Changing the experience hasn’t been meaningful enough. And we’ve put most of the burden on the victims of abuse (that’s a huge fail).

Kara: Well that is like telling me I am sick and am responsible for fixing it. YOU made the product, YOU run the platform. Saying it is a huge fail is a cop out to many. It is to me

Jack: Putting the burden on victims? Yes. It’s recognizing that we have to be proactive in enforcement and promotion of healthy conversation. This is our first priority in #health. We have to change a lot of the fundamentals of product to fix.

Kara: please be specific. I see a lot of beard-stroking on this (no insult to your Lincoln jam, but it works). WHAT are you changing? SPECIFICALLY.

Jack: First and foremost we’re looking at ways to proactively enforce and promote health. So that reporting/blocking is a last resort. Problem we’re trying to solve is taking that work away.

Kara: Ok name three initiatives.

Jack: Myself? C. We’ve made progress, but it has been scattered and not felt enough. Changing the experience hasn’t been meaningful enough. And we’ve put most of the burden on the victims of abuse (that’s a huge fail).

Kara: Also my son gets a C in coding and that is NO tragedy. You getting one matters a lot.

Jack: Agree it matters a lot. And it’s the most important thing we need to address and fix. I’m stating that it’s a fail of ours to put the majority of burden on victims. That’s how the service works today.

Kara: Ok but I really want to drill down on HOW. How much downside are you willing to tolerate to balance the good that Twitter can provide? Be specific

Jack: This is exactly the balance we have to think deeply about. But in doing so, we have to look at how the product works. And where abuse happens the most: replies, mentions, search, and trends. Those are the shared spaces people take advantage of

Kara: Well, WHERE does abuse happen most

Jack: Within the service? Likely within replies. That’s why we’ve been more aggressive about proactively downranking behind interstitials, for example.

Kara: Why not just be more stringent on kicking off offenders? It seems like you tolerate a lot. If Twitter ran my house, my kids would be eating ramen, playing Red Dead Redemption 2 and wearing filthy socks

Jack: We action all we can against our policies. Most of our system today works reactively to someone reporting it. If they don’t report, we don’t see it. Doesn’t scale. Hence the need to focus on proactive

Kara: But why did you NOT see it? It seems pretty basic to run your platform with some semblance of paying mind to what people are doing on it? Can you give me some insight into why that was not done?

Jack: I think we tried to do too much in the past, and that leads to diluted answers and nothing impactful. There’s a lot we need to address globally. We have to prioritize our resources according to impact. Otherwise we won’t make much progress.

Kara: Got it. But do you think the fact that you all could not conceive of what it is to feel unsafe (women, POC, LGBTQ, other marginalized people) could be one of the issues? (new topic soon)

Jack: I think it’s fair and real. No question. Our org has to be reflective of the people we’re trying to serve. One of the reason we established the Trust and Safety council years ago, to get feedback and check ourselves.

Kara: Yes but i want THREE concrete examples.

Jack: First and foremost we’re looking at ways to proactively enforce and promote health. So that reporting/blocking is a last resort. Problem we’re trying to solve is taking that work away.

Kara: Or maybe, tell me what you think the illness is you are treating? I think you cannot solve a disease without knowing that. Or did you create the virus?

Jack: Good question. This is why we’re focused on understanding what conversational health means. We see a ton of threats to health in digital conversation. We’re focuse first on off-platform ramifications (physical safety). That clarifies priorities of policy and enforcement.

Kara: I am still confused. What the heck is "off-platform ramifications"? You are not going to have a police force, right? Are you 911?

Jack: No, not a police force. I mean we have to consider first and foremost what online activity does to impact physical safety, as a way to prioritize our efforts. I don’t think companies like ours have admitted or focused on that enough.

Kara: So you do see the link between what you do and real life danger to people? Can you say that explicitly? I could not be @finkd to even address the fact that he made something that resulted in real tragedy.

Jack: I see the link, and that’s why we need to put physical safety above all else. That’s what we’re figuring out how to do now. We don’t have all the answers just yet. But that’s the focus. I think it clarifies a lot of the work we need to do. Not all of it of course.

Kara: I grade you all an F on this and that's being kind. I'm not trying to be a jackass, but it's been a very slow roll by all of you in tech to pay attention to this. Why do you think that is? I think it is because many of the people who made Twitter never ever felt unsafe.

Jack: Likely a reason. I’m certain lack of diversity didn’t help with empathy of what people experience on Twitter every day, especially women.

Kara: And so to end this topic, I will try again. Please give me three concrete things you have done to fix this. SPECIFIC.

Jack: 1. We have evolved our polices. 2. We have prioritized proactive enforcement to remove burden from victims 3. We have given more control in product (like mute of accounts without profile pics or associated phone/emails) 4. Much more aggressive on coordinated behavior/gaming

Kara: 1. WHICH? 2. HOW? 3. OK, MUTE BUT THAT WAS A WHILE AGO 4. WHAT MORE? I think people are dying for specifics.

Jack: 1. Misgendering policy as example. 2. Using ML to downrank bad actors behind interstitials 3. Not too long ago, but most of our work going forward will have to be product features. 4. Not sure the question. We put an entire model in place to minimize gaming of system.

Kara: thx. I meant even more specifics on 4. But see the Twitter purge one.

Jack: Just resonded to that. Don’t see the twitter purge one

Kara: I wanted to get off thread with Mark added! Like he needs more of me.

Jack: Does he check this much?

Kara: No, he is busy fixing Facebook. NOT! (he makes you look good)

Kara: I am going to start a NEW thread to make it easy for people to follow (@waltmossberg just texted me that it is a "chaotic hellpit"). Stay in that one. OK?

Jack: Ok. Definitely not easy to follow the conversation. Exactly why we are doing this. Fixing stuff like this will help I believe.

Kara: Yeah, it's Chinatown, Jake.

Jack: First and foremost we’re looking at ways to proactively enforce and promote health. So that reporting/blocking is a last resort. Problem we’re trying to solve is taking that work away.

Jack: Second, we’re constantly evolving our policies to address the issues we see today. We’re rooting them in fundamental human rights (UN) and putting physical safety as our top priority. Privacy next.

Kara: When you say physical safety, I am confused. What do you mean specifically? You are not a police force. In fact, social media companies have built cities without police, fire departments, garbage pickup or street signs. IMHO What do you think of that metaphor?

Jack: I mean off platform, offline ramifications. What people do offline with what they see online. Doxxing is a good example which threatens physical safety. So does coordinate harassment campaigns.

Kara: So how do you stop THAT? I mean regular police forces cannot stop that. It seems your job is not to let it get that far in the first place.

Jack: Exactly. What can we do within the product and policy to lower probability. Again, don’t think we or others have worked against that enough.

Kara: Ok, new one @jack

What do you think about twitter breaks and purges. Why do you think that is? I can’t say I’ve heard many people say they feel “good” after not being on twitter for a while: https://twitter.com/TaylorLorenz/status/1095039347596898305

Jack: Feels terrible. I want people to walk away from Twitter feeling like they learned something and feeling empowered to some degree. It depresses me when that’s not the general vibe, and inspires me to figure it out. That’s my desire

Kara: But why do they feel that way? You made it.

Jack: We made something with one intent. The world showed us how it wanted to use it. A lot has been great. A lot has been unexpected. A lot has been negative. We weren’t fast enough to observe, learn, and improve

Kara: Ok, new one @jack

Kara: In that vein, how does it affect YOU?

Jack: I also don’t feel good about how Twitter tends to incentivize outrage, fast takes, short term thinking, echo chambers, and fragmented conversation and consideration. Are they fixable? I believe we can do a lot to address. And likely have to change more fundamentals to do so.

Kara: But you invented it. You can control it. Slowness is not really a good excuse.

Jack: It’s the reality. We tried to do too much at once and were not focused on what matters most. That contributes to slowness. As does our technology stack and how quickly we can ship things. That’s improved a lot recently

Kara: Ok trying AGAIN @jack in another new thread! This one about @realDonaldTrump:

We know a lot more about what Donald Trump thinks because of Twitter, and we all have mixed feelings about that.

Kara: Have you ever considered suspending Donald Trump? His tweets are somewhat protected because he’s a public figure, but would he have been suspended in the past if he were a “regular” user?

Jack: We hold all accounts to the same terms of service. The most controversial aspect of our TOS is the newsworthy/public interest clause, the “protection” you mention. That doesn’t extend to all public figures by default, but does speak to global leaders and seeing how they think.

Kara: That seems questionable to a lot of people. Let me try it a different way: What historic newsworthy figure would you ban? Is someone bad enough to ban. Be specific. A name.

Jack: We have to enforce based on our policy and what people do on our service. And evolve it with the current times. No way I can answer that based on people. Has to be focused on patterns of how people use the technology.

Kara: Not one name? Ok, but it is a copout imho. I have a long list.

Jack: I think it’s more durable to focus on use cases because that allows us to act broader. Likely that these aren’t isolated cases but things that spread

Kara: it would be really great to get specific examples as a lot of what you are doing appears incomprehensible to many.

Kara: Ok trying AGAIN @jack in another new thread! This one about @realDonaldTrump:

Kara: And will Twitter’s business/engagement suffer when @realDonaldTrump is no longer President?

Jack: I don’t believe our service or business is dependent on any one account or person. I will say the number of politics conversations has significantly increased because of it, but that’s just one experience on Twitter. There are multiple Twitters, all based on who you follow.

Kara: Ok new question (answer the newsworthy historical figure you MIGHT ban pls): Single biggest improvement at Twitter since 2016 that signals you’re ready for the 2020 elections?

Jack: Our work against automations and coordinated campaigns. Partnering with government agencies to improve communication around threats

Kara: Can you give a more detailed example of that that worked?

Jack: We shared a retro on 2018 within this country, and tested a lot with the Mexican elections too. Indian elections coming up. In mid-terms we were able to monitor efforts to disrupt both online and offline and able to stop those actions on Twitter.

Kara: Ok new question (answer the newsworthy historical figure you MIGHT ban pls): Single biggest improvement at Twitter since 2016 that signals you’re ready for the 2020 elections?

Kara: What confidence should we have that Russia or other state-sponsored actors won’t be able to wreak havoc on next year’s elections?

Jack: We should expect a lot more coordination between governments and platforms to address. That would give me confidence. And have some skepticism too. That’s healthy. The more we can do this work in public and share what we find, the better

Kara: I still am dying for specifics here. [meme image: Give me some specifics. I love specifics, the specifics were the best part!]

Jack: I think it’s more durable to focus on use cases because that allows us to act broader. Likely that these aren’t isolated cases but things that spread

Kara: going to shift to biz questions since it is not a lot of time and this system is CHAOTIC (as I thought it would be): What about the move to DAU instead of MAU. Why the move? And how are we to interpret the much smaller numbers?

Jack: We want to be valuable to people daily. Not monthly. It’s a higher bar for ourselves. Sure, it looks like a smaller absolute number, but the folks we have using Twitter are some of the most influential in the world. They drive conversation. We belevie we can best grow this.

Kara: Ok, then WHO is the most exciting influential on Twitter right now? BE SPECIFIC

Jack: To me personally? I like how @elonmusk uses Twitter. He’s focused on solving existential problems and sharing his thinking openly. I respect that a lot, and all the ups and downs that come with it

Kara: What about @AOC

Jack: Totally. She’s mastering the medium

Kara: She is well beyond mastering it. She speaks fluent Twitter.

Jack: True

Kara: Also are you ever going to hire someone to effectively be your number 2?

Jack: I think it’s better to spread that responsibility across multiple people. It creates less dependencies and the company gets more options around future leadership

Kara: going to shift to biz questions since it is not a lot of time and this system is CHAOTIC (as I thought it would be): What about the move to DAU instead of MAU. Why the move? And how are we to interpret the much smaller numbers?

Kara: Also: How close were you to selling Twitter in 2016? What happened?

What about giving the company to a public trust per your NYT discussion.

Jack: We ultimately decided we were better off independent. And I’m happy we did. We’ve made a lot of progress since that point. And we got a lot more focused. Definitely love the idea of opening more to 3rd parties. Not sure what that looks like yet. Twitter is close to a protocol.

Kara: Chop chop on the other answers! I have more questions! If you want to use this method, quicker!

Jack: I’m moving as fast as I can Kara

Kara: Clip clop!

Kara: going to shift to biz questions since it is not a lot of time and this system is CHAOTIC (as I thought it would be): What about the move to DAU instead of MAU. Why the move? And how are we to interpret the much smaller numbers?

Kara: also: Is twitter still considering a subscription service? Like “Twitter Premium” or something?

Jack: Always going to experiment with new models. Periscope has super hearts, which allows us to learn about direct contribution. We’d need to figure out the value exchange on subscription. Has to be really high for us to charge directly

Jack: Totally. She’s mastering the medium

Kara: Ok, last ones are about you and we need to go long because your system here it confusing says the people of Twitter:

1. What has been Twitter’s biggest missed opportunity since you came back as CEO?

Jack: Focus on conversation earlier. We took too long to get there. Too distracted.

Kara: By what? What is the #1 thing that distracted you and others and made this obvious mess via social media?

Jack: Tried to do too much at once. Wasn’t focused on what our one core strength was: conversation. That lead to really diluted strategy and approach. And a ton of reactiveness.

Kara: Speaking of that (CONVERSATION), let's do one with sounds soon, like this

https://www.youtube.com/watch?v=oiJkANps0Qw

Kara: She is well beyond mastering it. She speaks fluent Twitter.

Jack: True

Kara: Why are you still saying you’re the CEO of two publicly traded companies? What’s the point in insisting you can do two jobs that both require maximum effort at the same time?

Jack: I’m focused on building leadership in both. Not my desire or ambition to be CEO of multiple companies just for the sake of that. I’m doing everything I can to help both. Effort doesn’t come down to one person. It’s a team

Kara: LAST Q: For the love of God, please do Recode Decode podcast with me soon, because analog talking seems to be a better way of asking questions and giving answers. I think Twitter agrees and this has shown how hard this thread is to do. That said, thx for trying. Really.

Jack: This thread was hard. But we got to learn a ton to fix it. Need to make this feel a lot more cohesive and easier to follow. Was extremely challenging. Thank you for trying it with me. Know it wasn’t easy. Will consider different formats!

Kara: Make a glass house for events and people can watch and not throw stones. Pro tip: Twitter convos are wack

Jack: Yep. And they don’t have to be wack. Need to figure this out. This whole experience is a problem statement for what we need to fix

Jack: This thread was hard. But we got to learn a ton to fix it. Need to make this feel a lot more cohesive and easier to follow. Was extremely challenging. Thank you for trying it with me. Know it wasn’t easy. Will consider different formats!

Kara: My kid is hungry and says that you should do a real interview with me even if I am mean. Just saying.

Jack: I don’t think you’re mean. Always good to experiment.

Kara: Neither does my kid. He just wants to go get dinner

Jack: Go eat! Thanks, Kara

this is an archive of an old article by John Carmack which seems to have disappeared off of the internet

Abstract

Virtual reality (VR) is one of the most demanding human-in-the-loop applications from a latency standpoint. The latency between the physical movement of a user’s head and updated photons from a head mounted display reaching their eyes is one of the most critical factors in providing a high quality experience.

Human sensory systems can detect very small relative delays in parts of the visual or, especially, audio fields, but when absolute delays are below approximately 20 milliseconds they are generally imperceptible. Interactive 3D systems today typically have latencies that are several times that figure, but alternate configurations of the same hardware components can allow that target to be reached.

A discussion of the sources of latency throughout a system follows, along with techniques for reducing the latency in the processing done on the host system.

Introduction

Updating the imagery in a head mounted display (HMD) based on a head tracking sensor is a subtly different challenge than most human / computer interactions. With a conventional mouse or game controller, the user is consciously manipulating an interface to complete a task, while the goal of virtual reality is to have the experience accepted at an unconscious level.

Users can adapt to control systems with a significant amount of latency and still perform challenging tasks or enjoy a game; many thousands of people enjoyed playing early network games, even with 400+ milliseconds of latency between pressing a key and seeing a response on screen.

If large amounts of latency are present in the VR system, users may still be able to perform tasks, but it will be by the much less rewarding means of using their head as a controller, rather than accepting that their head is naturally moving around in a stable virtual world. Perceiving latency in the response to head motion is also one of the primary causes of simulator sickness. Other technical factors that affect the quality of a VR experience, like head tracking accuracy and precision, may interact with the perception of latency, or, like display resolution and color depth, be largely orthogonal to it.

A total system latency of 50 milliseconds will feel responsive, but still subtly lagging. One of the easiest ways to see the effects of latency in a head mounted display is to roll your head side to side along the view vector while looking at a clear vertical edge. Latency will show up as an apparent tilting of the vertical line with the head motion; the view feels “dragged along” with the head motion. When the latency is low enough, the virtual world convincingly feels like you are simply rotating your view of a stable world.

Extrapolation of sensor data can be used to mitigate some system latency, but even with a sophisticated model of the motion of the human head, there will be artifacts as movements are initiated and changed. It is always better to not have a problem than to mitigate it, so true latency reduction should be aggressively pursued, leaving extrapolation to smooth out sensor jitter issues and perform only a small amount of prediction.

Data collection

It is not usually possible to introspectively measure the complete system latency of a VR system, because the sensors and display devices external to the host processor make significant contributions to the total latency. An effective technique is to record high speed video that simultaneously captures the initiating physical motion and the eventual display update. The system latency can then be determined by single stepping the video and counting the number of video frames between the two events.

In most cases there will be a significant jitter in the resulting timings due to aliasing between sensor rates, display rates, and camera rates, but conventional applications tend to display total latencies in the dozens of 240 fps video frames.

On an unloaded Windows 7 system with the compositing Aero desktop interface disabled, a gaming mouse dragging a window displayed on a 180 hz CRT monitor can show a response on screen in the same 240 fps video frame that the mouse was seen to first move, demonstrating an end to end latency below four milliseconds. Many systems need to cooperate for this to happen: The mouse updates 500 times a second, with no filtering or buffering. The operating system immediately processes the update, and immediately performs GPU accelerated rendering directly to the framebuffer without any page flipping or buffering. The display accepts the video signal with no buffering or processing, and the screen phosphors begin emitting new photons within microseconds.

In a typical VR system, many things go far less optimally, sometimes resulting in end to end latencies of over 100 milliseconds.

Sensors

Detecting a physical action can be as simple as a watching a circuit close for a button press, or as complex as analyzing a live video feed to infer position and orientation.

In the old days, executing an IO port input instruction could directly trigger an analog to digital conversion on an ISA bus adapter card, giving a latency on the order of a microsecond and no sampling jitter issues. Today, sensors are systems unto themselves, and may have internal pipelines and queues that need to be traversed before the information is even put on the USB serial bus to be transmitted to the host.

Analog sensors have an inherent tension between random noise and sensor bandwidth, and some combination of analog and digital filtering is usually done on a signal before returning it. Sometimes this filtering is excessive, which can contribute significant latency and remove subtle motions completely.

Communication bandwidth delay on older serial ports or wireless links can be significant in some cases. If the sensor messages occupy the full bandwidth of a communication channel, latency equal to the repeat time of the sensor is added simply for transferring the message. Video data streams can stress even modern wired links, which may encourage the use of data compression, which usually adds another full frame of latency if not explicitly implemented in a pipelined manner.

Filtering and communication are constant delays, but the discretely packetized nature of most sensor updates introduces a variable latency, or “jitter” as the sensor data is used for a video frame rate that differs from the sensor frame rate. This latency ranges from close to zero if the sensor packet arrived just before it was queried, up to the repeat time for sensor messages. Most USB HID devices update at 125 samples per second, giving a jitter of up to 8 milliseconds, but it is possible to receive 1000 updates a second from some USB hardware. The operating system may impose an additional random delay of up to a couple milliseconds between the arrival of a message and a user mode application getting the chance to process it, even on an unloaded system.

Displays

On old CRT displays, the voltage coming out of the video card directly modulated the voltage of the electron gun, which caused the screen phosphors to begin emitting photons a few microseconds after a pixel was read from the frame buffer memory.

Early LCDs were notorious for “ghosting” during scrolling or animation, still showing traces of old images many tens of milliseconds after the image was changed, but significant progress has been made in the last two decades. The transition times for LCD pixels vary based on the start and end values being transitioned between, but a good panel today will have a switching time around ten milliseconds, and optimized displays for active 3D and gaming can have switching times less than half that.

Modern displays are also expected to perform a wide variety of processing on the incoming signal before they change the actual display elements. A typical Full HD display today will accept 720p or interlaced composite signals and convert them to the 1920×1080 physical pixels. 24 fps movie footage will be converted to 60 fps refresh rates. Stereoscopic input may be converted from side-by-side, top-down, or other formats to frame sequential for active displays, or interlaced for passive displays. Content protection may be applied. Many consumer oriented displays have started applying motion interpolation and other sophisticated algorithms that require multiple frames of buffering.

Some of these processing tasks could be handled by only buffering a single scan line, but some of them fundamentally need one or more full frames of buffering, and display vendors have tended to implement the general case without optimizing for the cases that could be done with low or no delay. Some consumer displays wind up buffering three or more frames internally, resulting in 50 milliseconds of latency even when the input data could have been fed directly into the display matrix.

Some less common display technologies have speed advantages over LCD panels; OLED pixels can have switching times well under a millisecond, and laser displays are as instantaneous as CRTs.

A subtle latency point is that most displays present an image incrementally as it is scanned out from the computer, which has the effect that the bottom of the screen changes 16 milliseconds later than the top of the screen on a 60 fps display. This is rarely a problem on a static display, but on a head mounted display it can cause the world to appear to shear left and right, or “waggle” as the head is rotated, because the source image was generated for an instant in time, but different parts are presented at different times. This effect is usually masked by switching times on LCD HMDs, but it is obvious with fast OLED HMDs.

Host processing

The classic processing model for a game or VR application is:

Read user input -> run simulation -> issue rendering commands -> graphics drawing -> wait for vsync -> scanout

I = Input sampling and dependent calculation
S = simulation / game execution
R = rendering engine
G = GPU drawing time
V = video scanout time

All latencies are based on a frame time of roughly 16 milliseconds, a progressively scanned display, and zero sensor and pixel latency.

If the performance demands of the application are well below what the system can provide, a straightforward implementation with no parallel overlap will usually provide fairly good latency values. However, if running synchronized to the video refresh, the minimum latency will still be 16 ms even if the system is infinitely fast. This rate feels good for most eye-hand tasks, but it is still a perceptible lag that can be felt in a head mounted display, or in the responsiveness of a mouse cursor.

Ample performance, vsync:
ISRG------------|VVVVVVVVVVVVVVVV|
.................. latency 16 – 32 milliseconds

Running without vsync on a very fast system will deliver better latency, but only over a fraction of the screen, and with visible tear lines. The impact of the tear lines are related to the disparity between the two frames that are being torn between, and the amount of time that the tear lines are visible. Tear lines look worse on a continuously illuminated LCD than on a CRT or laser projector, and worse on a 60 fps display than a 120 fps display. Somewhat counteracting that, slow switching LCD panels blur the impact of the tear line relative to the faster displays.

If enough frames were rendered such that each scan line had a unique image, the effect would be of a “rolling shutter”, rather than visible tear lines, and the image would feel continuous. Unfortunately, even rendering 1000 frames a second, giving approximately 15 bands on screen separated by tear lines, is still quite objectionable on fast switching displays, and few scenes are capable of being rendered at that rate, let alone 60x higher for a true rolling shutter on a 1080P display.

Ample performance, unsynchronized:
ISRG
VVVVV
..... latency 5 – 8 milliseconds at ~200 frames per second

In most cases, performance is a constant point of concern, and a parallel pipelined architecture is adopted to allow multiple processors to work in parallel instead of sequentially. Large command buffers on GPUs can buffer an entire frame of drawing commands, which allows them to overlap the work on the CPU, which generally gives a significant frame rate boost at the expense of added latency.

CPU:ISSSSSRRRRRR----|
GPU:                |GGGGGGGGGGG----|
VID:                |               |VVVVVVVVVVVVVVVV|
    .................................. latency 32 – 48 milliseconds

When the CPU load for the simulation and rendering no longer fit in a single frame, multiple CPU cores can be used in parallel to produce more frames. It is possible to reduce frame execution time without increasing latency in some cases, but the natural split of simulation and rendering has often been used to allow effective pipeline parallel operation. Work queue approaches buffered for maximum overlap can cause an additional frame of latency if they are on the critical user responsiveness path.

CPU1:ISSSSSSSS-------|
CPU2:                |RRRRRRRRR-------|
GPU :                |                |GGGGGGGGGG------|
VID :                |                |                |VVVVVVVVVVVVVVVV|
     .................................................... latency 48 – 64 milliseconds

Even if an application is running at a perfectly smooth 60 fps, it can still have host latencies of over 50 milliseconds, and an application targeting 30 fps could have twice that. Sensor and display latencies can add significant additional amounts on top of that, so the goal of 20 milliseconds motion-to-photons latency is challenging to achieve.

Latency Reduction Strategies

Prevent GPU buffering

The drive to win frame rate benchmark wars has led driver writers to aggressively buffer drawing commands, and there have even been cases where drivers ignored explicit calls to glFinish() in the name of improved “performance”. Today’s fence primitives do appear to be reliably observed for drawing primitives, but the semantics of buffer swaps are still worryingly imprecise. A recommended sequence of commands to synchronize with the vertical retrace and idle the GPU is:

SwapBuffers();
DrawTinyPrimitive();
InsertGPUFence();
BlockUntilFenceIsReached();

While this should always prevent excessive command buffering on any conformant driver, it could conceivably fail to provide an accurate vertical sync timing point if the driver was transparently implementing triple buffering.

To minimize the performance impact of synchronizing with the GPU, it is important to have sufficient work ready to send to the GPU immediately after the synchronization is performed. The details of exactly when the GPU can begin executing commands are platform specific, but execution can be explicitly kicked off with glFlush() or equivalent calls. If the code issuing drawing commands does not proceed fast enough, the GPU may complete all the work and go idle with a “pipeline bubble”. Because the CPU time to issue a drawing command may have little relation to the GPU time required to draw it, these pipeline bubbles may cause the GPU to take noticeably longer to draw the frame than if it were completely buffered. Ordering the drawing so that larger and slower operations happen first will provide a cushion, as will pushing as much preparatory work as possible before the synchronization point.

Run GPU with minimal buffering:
CPU1:ISSSSSSSS-------|
CPU2:                |RRRRRRRRR-------|
GPU :                |-GGGGGGGGGG-----|
VID :                |                |VVVVVVVVVVVVVVVV|
     ................................... latency 32 – 48 milliseconds

Tile based renderers, as are found in most mobile devices, inherently require a full scene of command buffering before they can generate their first tile of pixels, so synchronizing before issuing any commands will destroy far more overlap. In a modern rendering engine there may be multiple scene renders for each frame to handle shadows, reflections, and other effects, but increased latency is still a fundamental drawback of the technology.

High end, multiple GPU systems today are usually configured for AFR, or Alternate Frame Rendering, where each GPU is allowed to take twice as long to render a single frame, but the overall frame rate is maintained because there are two GPUs producing frames

Alternate Frame Rendering dual GPU:
CPU1:IOSSSSSSS-------|IOSSSSSSS-------|
CPU2:                |RRRRRRRRR-------|RRRRRRRRR-------|
GPU1:                | GGGGGGGGGGGGGGGGGGGGGGGG--------|
GPU2:                |                | GGGGGGGGGGGGGGGGGGGGGGG---------|
VID :                |                |                |VVVVVVVVVVVVVVVV|
     .................................................... latency 48 – 64 milliseconds

Similarly to the case with CPU workloads, it is possible to have two or more GPUs cooperate on a single frame in a way that delivers more work in a constant amount of time, but it increases complexity and generally delivers a lower total speedup.

An attractive direction for stereoscopic rendering is to have each GPU on a dual GPU system render one eye, which would deliver maximum performance and minimum latency, at the expense of requiring the application to maintain buffers across two independent rendering contexts.

The downside to preventing GPU buffering is that throughput performance may drop, resulting in more dropped frames under heavily loaded conditions.

Late frame scheduling

Much of the work in the simulation task does not depend directly on the user input, or would be insensitive to a frame of latency in it. If the user processing is done last, and the input is sampled just before it is needed, rather than stored off at the beginning of the frame, the total latency can be reduced.

It is very difficult to predict the time required for the general simulation work on the entire world, but the work just for the player’s view response to the sensor input can be made essentially deterministic. If this is split off from the main simulation task and delayed until shortly before the end of the frame, it can remove nearly a full frame of latency.

Late frame scheduling:
CPU1:SSSSSSSSS------I|
CPU2:                |RRRRRRRRR-------|
GPU :                |-GGGGGGGGGG-----|
VID :                |                |VVVVVVVVVVVVVVVV|
                    .................... latency 18 – 34 milliseconds

Adjusting the view is the most latency sensitive task; actions resulting from other user commands, like animating a weapon or interacting with other objects in the world, are generally insensitive to an additional frame of latency, and can be handled in the general simulation task the following frame.

The drawback to late frame scheduling is that it introduces a tight scheduling requirement that usually requires busy waiting to meet, wasting power. If your frame rate is determined by the video retrace rather than an arbitrary time slice, assistance from the graphics driver in accurately determining the current scanout position is helpful.

View bypass

An alternate way of accomplishing a similar, or slightly greater latency reduction Is to allow the rendering code to modify the parameters delivered to it by the game code, based on a newer sampling of user input.

At the simplest level, the user input can be used to calculate a delta from the previous sampling to the current one, which can be used to modify the view matrix that the game submitted to the rendering code.

Delta processing in this way is minimally intrusive, but there will often be situations where the user input should not affect the rendering, such as cinematic cut scenes or when the player has died. It can be argued that a game designed from scratch for virtual reality should avoid those situations, because a non-responsive view in a HMD is disorienting and unpleasant, but conventional game design has many such cases.

A binary flag could be provided to disable the bypass calculation, but it is useful to generalize such that the game provides an object or function with embedded state that produces rendering parameters from sensor input data instead of having the game provide the view parameters themselves. In addition to handling the trivial case of ignoring sensor input, the generator function can incorporate additional information such as a head/neck positioning model that modified position based on orientation, or lists of other models to be positioned relative to the updated view.

If the game and rendering code are running in parallel, it is important that the parameter generation function does not reference any game state to avoid race conditions.

View bypass:
CPU1:ISSSSSSSSS------|
CPU2:                |IRRRRRRRRR------|
GPU :                |--GGGGGGGGGG----|
VID :                |                |VVVVVVVVVVVVVVVV|
                      .................. latency 16 – 32 milliseconds

The input is only sampled once per frame, but it is simultaneously used by both the simulation task and the rendering task. Some input processing work is now duplicated by the simulation task and the render task, but it is generally minimal.

The latency for parameters produced by the generator function is now reduced, but other interactions with the world, like muzzle flashes and physics responses, remain at the same latency as the standard model.

A modified form of view bypass could allow tile based GPUs to achieve similar view latencies to non-tiled GPUs, or allow non-tiled GPUs to achieve 100% utilization without pipeline bubbles by the following steps:

Inhibit the execution of GPU commands, forcing them to be buffered. OpenGL has only the deprecated display list functionality to approximate this, but a control extension could be formulated.

All calculations that depend on the view matrix must reference it independently from a buffer object, rather than from inline parameters or as a composite model-view-projection (MVP) matrix.

After all commands have been issued and the next frame has started, sample the user input, run it through the parameter generator, and put the resulting view matrix into the buffer object for referencing by the draw commands.

Kick off the draw command execution.

Tiler optimized view bypass:
CPU1:ISSSSSSSSS------|
CPU2:                |IRRRRRRRRRR-----|I
GPU :                |                |-GGGGGGGGGG-----|
VID :                |                |                |VVVVVVVVVVVVVVVV|
                                       .................. latency 16 – 32 milliseconds

Any view frustum culling that was performed to avoid drawing some models may be invalid if the new view matrix has changed substantially enough from what was used during the rendering task. This can be mitigated at some performance cost by using a larger frustum field of view for culling, and hardware clip planes based on the culling frustum limits can be used to guarantee a clean edge if necessary. Occlusion errors from culling, where a bright object is seen that should have been occluded by an object that was incorrectly culled, are very distracting, but a temporary clean encroaching of black at a screen edge during rapid rotation is almost unnoticeable.

Time warping

If you had perfect knowledge of how long the rendering of a frame would take, some additional amount of latency could be saved by late frame scheduling the entire rendering task, but this is not practical due to the wide variability in frame rendering times.

Late frame input sampled view bypass:
CPU1:ISSSSSSSSS------|
CPU2:                |----IRRRRRRRRR--|
GPU :                |------GGGGGGGGGG|
VID :                |                |VVVVVVVVVVVVVVVV|
                          .............. latency 12 – 28 milliseconds

However, a post processing task on the rendered image can be counted on to complete in a fairly predictable amount of time, and can be late scheduled more easily. Any pixel on the screen, along with the associated depth buffer value, can be converted back to a world space position, which can be re-transformed to a different screen space pixel location for a modified set of view parameters.

After drawing a frame with the best information at your disposal, possibly with bypassed view parameters, instead of displaying it directly, fetch the latest user input, generate updated view parameters, and calculate a transformation that warps the rendered image into a position that approximates where it would be with the updated parameters. Using that transform, warp the rendered image into an updated form on screen that reflects the new input. If there are two dimensional overlays present on the screen that need to remain fixed, they must be drawn or composited in after the warp operation, to prevent them from incorrectly moving as the view parameters change.

Late frame scheduled time warp:
CPU1:ISSSSSSSSS------|
CPU2:                |RRRRRRRRRR----IR|
GPU :                |-GGGGGGGGGG----G|
VID :                |                |VVVVVVVVVVVVVVVV|
                                    .... latency 2 – 18 milliseconds

If the difference between the view parameters at the time of the scene rendering and the time of the final warp is only a change in direction, the warped image can be almost exactly correct within the limits of the image filtering. Effects that are calculated relative to the screen, like depth based fog (versus distance based fog) and billboard sprites will be slightly different, but not in a manner that is objectionable.

If the warp involves translation as well as direction changes, geometric silhouette edges begin to introduce artifacts where internal parallax would have revealed surfaces not visible in the original rendering. A scene with no silhouette edges, like the inside of a box, can be warped significant amounts and display only changes in texture density, but translation warping realistic scenes will result in smears or gaps along edges. In many cases these are difficult to notice, and they always disappear when motion stops, but first person view hands and weapons are a prominent case. This can be mitigated by limiting the amount of translation warp, compressing or making constant the depth range of the scene being warped to limit the dynamic separation, or rendering the disconnected near field objects as a separate plane, to be composited in after the warp.

If an image is being warped to a destination with the same field of view, most warps will leave some corners or edges of the new image undefined, because none of the source pixels are warped to their locations. This can be mitigated by rendering a larger field of view than the destination requires; but simply leaving unrendered pixels black is surprisingly unobtrusive, especially in a wide field of view HMD.

A forward warp, where source pixels are deposited in their new positions, offers the best accuracy for arbitrary transformations. At the limit, the frame buffer and depth buffer could be treated as a height field, but millions of half pixel sized triangles would have a severe performance cost. Using a grid of triangles at some fraction of the depth buffer resolution can bring the cost down to a very low level, and the trivial case of treating the rendered image as a single quad avoids all silhouette artifacts at the expense of incorrect pixel positions under translation.

Reverse warping, where the pixel in the source rendering is estimated based on the position in the warped image, can be more convenient because it is implemented completely in a fragment shader. It can produce identical results for simple direction changes, but additional artifacts near geometric boundaries are introduced if per-pixel depth information is considered, unless considerable effort is expended to search a neighborhood for the best source pixel.

If desired, it is straightforward to incorporate motion blur in a reverse mapping by taking several samples along the line from the pixel being warped to the transformed position in the source image.

Reverse mapping also allows the possibility of modifying the warp through the video scanout. The view parameters can be predicted ahead in time to when the scanout will read the bottom row of pixels, which can be used to generate a second warp matrix. The warp to be applied can be interpolated between the two of them based on the pixel row being processed. This can correct for the “waggle” effect on a progressively scanned head mounted display, where the 16 millisecond difference in time between the display showing the top line and bottom line results in a perceived shearing of the world under rapid rotation on fast switching displays.

Continuously updated time warping

If the necessary feedback and scheduling mechanisms are available, instead of predicting what the warp transformation should be at the bottom of the frame and warping the entire screen at once, the warp to screen can be done incrementally while continuously updating the warp matrix as new input arrives.

Continuous time warp:
CPU1:ISSSSSSSSS------|
CPU2:                |RRRRRRRRRRR-----|
GPU :                |-GGGGGGGGGGGG---|
WARP:                |               W| W W W W W W W W|
VID :                |                |VVVVVVVVVVVVVVVV|
                                     ... latency 2 – 3 milliseconds for 500hz sensor updates

The ideal interface for doing this would be some form of “scanout shader” that would be called “just in time” for the video display. Several video game systems like the Atari 2600, Jaguar, and Nintendo DS have had buffers ranging from half a scan line to several scan lines that were filled up in this manner.

Without new hardware support, it is still possible to incrementally perform the warping directly to the front buffer being scanned for video, and not perform a swap buffers operation at all.

A CPU core could be dedicated to the task of warping scan lines at roughly the speed they are consumed by the video output, updating the time warp matrix each scan line to blend in the most recently arrived sensor information.

GPUs can perform the time warping operation much more efficiently than a conventional CPU can, but the GPU will be busy drawing the next frame during video scanout, and GPU drawing operations cannot currently be scheduled with high precision due to the difficulty of task switching the deep pipelines and extensive context state. However, modern GPUs are beginning to allow compute tasks to run in parallel with graphics operations, which may allow a fraction of a GPU to be dedicated to performing the warp operations as a shared parameter buffer is updated by the CPU.

Discussion

View bypass and time warping are complementary techniques that can be applied independently or together. Time warping can warp from a source image at an arbitrary view time / location to any other one, but artifacts from internal parallax and screen edge clamping are reduced by using the most recent source image possible, which view bypass rendering helps provide.

Actions that require simulation state changes, like flipping a switch or firing a weapon, still need to go through the full pipeline for 32 – 48 milliseconds of latency based on what scan line the result winds up displaying on the screen, and translational information may not be completely faithfully represented below the 16 – 32 milliseconds of the view bypass rendering, but the critical head orientation feedback can be provided in 2 – 18 milliseconds on a 60 hz display. In conjunction with low latency sensors and displays, this will generally be perceived as immediate. Continuous time warping opens up the possibility of latencies below 3 milliseconds, which may cross largely unexplored thresholds in human / computer interactivity.

Conventional computer interfaces are generally not as latency demanding as virtual reality, but sensitive users can tell the difference in mouse response down to the same 20 milliseconds or so, making it worthwhile to apply these techniques even in applications without a VR focus.

A particularly interesting application is in “cloud gaming”, where a simple client appliance or application forwards control information to a remote server, which streams back real time video of the game. This offers significant convenience benefits for users, but the inherent network and compression latencies makes it a lower quality experience for action oriented titles. View bypass and time warping can both be performed on the server, regaining a substantial fraction of the latency imposed by the network. If the cloud gaming client was made more sophisticated, time warping could be performed locally, which could theoretically reduce the latency to the same levels as local applications, but it would probably be prudent to restrict the total amount of time warping to perhaps 30 or 40 milliseconds to limit the distance from the source images.

Acknowledgements

Zenimax for allowing me to publish this openly.

Hillcrest Labs for inertial sensors and experimental firmware.

Emagin for access to OLED displays.

Oculus for a prototype Rift HMD.

Nvidia for an experimental driver with access to the current scan line number.

About The Blog

This started out as a way to jot down thoughts on areas that seem interesting but underappreciated. Since then, this site has grown to the point where it gets millions of hits a month and I see that it's commonly cited by professors in their courses and on stackoverflow.

That's flattering, but more than anything else, I view that as a sign there's a desperate shortage of understandable explanation of technical topics. There's nothing here that most of my co-workers don't know (with the exception of maybe three or four posts where I propose novel ideas). It's just that they don't blog and I do. I'm not going to try to convince you to start writing a blog, since that has to be something you want to do, but I will point out that there's a large gap that's waiting to be filled by your knowledge. When I started writing this blog, I figured almost no one would ever read it; sure Joel Spolsky and Steve Yegge created widely read blogs, but that was back when almost no one was blogging. Now that there are millions of blogs, there's just no way to start a new blog and get noticed. Turns out that's not true.

This site also archives a few things that have fallen off the internet, like this history of subspace, the 90s video game, the su3su2u1 introduction to physics, the su3su2u1 review of hpmor, Dan Weinreb's history of Symbolics and Lisp machines, this discussion of open vs. closed social networks, this discussion about the differences between SV and Boston, and Stanford and MIT, the comp.programming.threads FAQ, and this presentation about Microsoft culture from 2000.

P.S. If you enjoy this blog, you'd probably enjoy RC, which I've heard called "nerd camp for programmers".

Verilog is the most commonly used language for hardware design in America (VHDL is more common in Europe). Too bad it's so baroque. If you ever browse the Verilog questions on Stack Overflow, you'll find a large number of questions, usually downvoted, asking “why doesn't my code work?”, with code that's not just a little off, but completely wrong.

Lets look at an example: “Idea is to store value of counter at the time of reset . . . I get DRC violations and the memory, bufreadaddr, bufreadval are all optimized out.”

always @(negedge reset or posedge clk) begin
  if (reset == 0) begin
    d_out <= 16'h0000;
    d_out_mem[resetcount] <= d_out;
    laststoredvalue <= d_out;
  end else begin
    d_out <= d_out + 1'b1;
  end
end

always @(bufreadaddr)
  bufreadval = d_out_mem[bufreadaddr];

We want a counter that keeps track of how many cycles it's been since reset, and we want to store that value in an array-like structure that's indexed by resetcount. If you've read a bit on semantics of Verilog, this is a perfectly natural way to solve the problem. Our poster knows enough about Verilog to use ‘<=' in state elements, so that all of the elements are updated at the same time. Every time there's a clock edge, we'll increment d_out. When reset is 0, we'll store that value and reset d_out. What could possibly go wrong?

The problem is that Verilog was originally designed as a language to describe simulations, so it has constructs to describe arbitrary interactions between events. When X transitions from 0 to 1, do Y. Great! Sounds easy enough. But then someone had the bright idea of using Verilog to represent hardware. The vast majority of statements you could write down don't translate into any meaningful hardware. Your synthesis tool, which translates from Verilog to hardware will helpfully pattern match to the closest available thing, or produce nothing, if you write down something untranslatable. If you're lucky, you might get some warnings.

Looking at the code above, the synthesis tool will see that there's something called dout which should be a clocked element that's set to something when it shouldn't be reset, and is otherwise asynchronously reset. That's a legit hardware construct, so it will produce an N-bit flip-flop and some logic to make it a counter that gets reset to 0. BTW, this paragraph used to contain a link to http://en.wikipedia.org/wiki/Flip-flop(electronics), but ever since I switched to Hugo, my links to URLs with parens in them are broken, so maybe try copy+pasting that URL into your browser window if you want know what a flip-flop is.

Now, what about the value we're supposed to store on reset? Well, the synthesis tool will see that it's inside a block that's clocked. But it's not supposed to do anything when the clock is active; only when reset is asserted. That's pretty unusual. What's going to happen? Well, that depends on which version of which synthesis tool you're using, and how the programmers of that tool decided to implement undefined behavior.

And then there's the block that's supposed to read out the stored value. It looks like the intent is to create a 64:1 MUX. Putting aside the cycle time issues you'll get with such a wide MUX, the block isn't clocked, so the synthesis tool will have to infer some sort of combinational logic. But, the output is only supposed to change if bufreadaddr changes, and not if d_out_mem changes. It's quite easy to describe that in our simulation language, the but the synthesis tool is going to produce something that is definitely not what the user wants here. Not to mention that laststoredvalue isn't meaningfully connected to bufreadvalue.

How is it possible that a reasonable description of something in Verilog turns into something completely wrong in hardware? You can think of hardware as some state, with pure functions connecting the state elements. This makes it natural to think about modeling hardware in a functional programming language. Another natural way to think about it would be with OO. Classes describe how the hardware works. Instances of the class are actual hardware that will get put onto the chip. Yet another natural way to describe things would be declaratively, where you write down constraints the hardware must obey, and the synthesis tool outputs something that meets those constraints.

Verilog does none of these things. To write Verilog that will produce correct hardware, you have to first picture the hardware you want to produce. Then, you have to figure out how to describe that in this weird C-like simulation language. That will then get synthesized into something like what you were imaging in the first step.

As a software engineer, how would you feel if 99% of valid Java code ended up being translated to something that produced random results, even though tests pass on the untranslated Java code? And, by the way, to run tests on the translated Java code you have to go through a multi-day long compilation process, after which your tests will run 200 million times slower than code runs in production. If you're thinking of testing on some sandboxed production machines, sure, go ahead, but it costs 8 figures to push something to any number of your production machines, and it takes 3 months. But, don't worry, you can run the untranslated code only 2 million times slower than in production ¹. People used to statically typed languages often complain that you get run-time errors about things that would be trivial to statically check in a language with stronger types. We hardware folks are so used to the vast majority of legal Verilog constructs producing unsynthesizable garbage that we don't find it the least bit surprising that you not only do you not get compile-time errors, you don't even get run-time errors, from writing naive Verilog code.

Old school hardware engineers will tell you that it's fine. It's fine that the language is so counter-intuitive that almost all people who initially approach Verilog write code that's not just wrong but nonsensical. "All you have to do is figure out the design and then translate it to Verilog". They'll tell you that it's totally fine that the mental model you have of what's going on is basically unrelated to the constructs the language provides, and that they never make errors now that they're experienced, much like some experienced C programmers will erronously tell you that they never have security related buffer overflows or double frees or memory leaks now that they're experienced. It reminds me of talking to assembly programmers who tell me that assembly is as productive as a high level language once you get your functions written. Programmers who haven't talked to old school assembly programmers will think I'm making that up, but I know a number of people who still maintain that assembly is as productive as any high level langauge out there. But people like that are rare and becoming rarer. With hardware, we train up a new generation of people who think that Verilog is as productive as any language could be every few years!

I won't even get into how Verilog is so inexpressive that many companies use an ad hoc tool to embed a scripting language in Verilog or generate Verilog from a scripting language.

There have been a number of attempts to do better than jamming an ad hoc scripting language into Verilog, but they've all fizzled out. As a functional language that's easy to add syntax to, Haskell is a natural choice for Verilog code generation; it spawned ForSyDe, Hydra, Lava, HHDL, and Bluespec. But adoption of ForSyDe, Hydra, Lava, and HHDL is pretty much zero, not because of deficiencies in the language, but because it's politically difficult to get people to use a Haskell based language. Bluespec has done better, but they've done it by making their language look C-like, scrapping the original Haskell syntax and introducing Bluespec SystemVerilog and Bluespec SystemC. The aversion to Haskell is so severe that when we discussed a hardware style at my new gig, one person suggested banning any Haskell based solution, even though Bluespec has been used to good effect in a couple projects within the company.

Scala based solutions look more promising, not for any technical reason, but because Scala is less scary. Scala has managed to bring the modern world (in terms of type systems) to more programmers than ML, Ocaml, Haskell, Agda, etc., combined. Perhaps the same will be true in the hardware world. Chisel is interesting. Like Bluespec, it simulates much more quickly than Verilog, and unsynthesizable representations are syntax errors. It's not as high level, but it's the only hardware description language with a modern type system that I've been able to discuss with hardware folks without people objecting that Haskell is a bad idea.

Commercial vendors are mostly moving in the other direction because C-like languages make people feel all warm and fuzzy. A number of them are pushing high-level hardware synthesis from SystemC, or even straight C or C++. These solutions are also politically difficult to sell, but this time it's the history of the industry, and not the language. Vendors pushing high-level synthesis have a decades long track record of overpromising and underdelivering. I've lost track of the number of times I've heard people dismiss modern offerings with “Why should we believe that this they're for real this time?”

What's the future? Locally, I've managed to convince a couple of people on my team that Chisel is worth looking at. At the moment, none of the Haskell based solutions are even on the table. I'm open to suggestions.

CPU internals series

• CPU bugs
• New CPU features since the 80s
• A brief history of branch prediction
• The cost of branches and integer overflow checking in real code
• Why CPU development is hard
• Verilog sucks, part 1
• Verilog sucks, part 2

P.S. Dear hardware folks, sorry for oversimplifying so much. I started writing footnotes explaining everything I was glossing over until I realized that my footnotes were longer than the post. The culled footnotes may make it into their own blog posts some day. A very long footnote that I'll briefly summarize is that semantically correct Verilog simulation is inherently slower than something like Bluespec or Chisel because of the complications involved with the event model. EDA vendors have managed to get decent performance out of Verilog, but only by hiring large teams of the best simulation people in the world to hammer at the problem, the same way JavaScript is fast not because of any property of the language, but because there are amazing people working on the VM. It should tell you something when a tiny team working on a shoestring grant-funded budget can produce a language and simulation infrastructure that smokes existing tools.

You may wonder why I didn't mention linters. They're a great idea and for reasons I don't understand, two of the three companies I've done hardware development for haven't used linters. If you ask around, everyone will agree that they're a good idea, but even though a linter will run in the thousands to tens of thousands of dollars range, and engineers run in hundreds of thousands of dollars range, it hasn't been politically possible to get a linter even on multi-person teams that have access to tools that cost tens or hundreds of thousands of dollars per license per year. Even though linters are a no-brainer, companies that spend millions to tens of millions a year on hardware development often don't use them, and good SystemVerilog linters are all out of the price range of the people who are asking StackOverflow questions that get downvoted to oblivion.

Troll? That's how people write Verilog¹. At my old company, we had a team of formal methods PhD's who wrote a linter that typechecked our code, based on our naming convention. For our chip (which was small for a CPU), building a model (compiling) took about five minutes, running a single short test took ten to fifteen minutes, and long tests took CPU months. The value of a linter that can run in seconds should be obvious, not even considering the fact that it can take hours of tracing through waveforms to find out why a test failed².

Lets look at some of the most commonly used naming conventions.

Pipeline stage

When you pipeline hardware, you end up with many versions of the same signal, one for each stage of the pipeline the signal traverses. Even without static checks, you'll want some simple way to differentiate between these, so you might name them foo_s1, foo_s2, and foo_s3, indicating that they originate in the first, second, and third stages, respectively. In any particular stage, a signal is most likely to interact with other signals in the same stage; it's often a mistake when logic from other stages is accessed. There are reasons to access signals from other stages, like bypass paths and control logic that looks at multiple stages, but logic that stays contained within a stage is common enough that it's not too tedious to either “cast” or add a comment that disables the check, when looking at signals from other stages.

Clock domain

Accessing a signal in a different clock domain without synchronization is like accessing a data structure from multiple threads without synchronization. Sort of. But worse. Much worse. Driving combinational logic from a metastable state (where the signal is sitting between a 0 and 1) can burn a massive amount of power³. Here, I'm not just talking about being inefficient. If you took a high-power chip from the late 90s and removed the heat sink, it would melt itself into the socket, even under normal operation. Modern chips have such a high maximum power possible power consumption that the chips would self destruct if you disabled the thermal regulation, even with the heat sink. Logic that's floating at an intermediate value not only uses a lot of power, it bypasses a chip's usual ability to reduce power by slowing down the clock⁴. Using cross clock domain signals without synchronization is a bad idea, unless you like random errors, high power dissipation, and the occasional literal meltdown.

Module / Region

In high speed designs, it's an error to use a signal that's sourced from another module without registering it first. This will insidiously sneak through simulation; you'll only notice when you look at the timing report. On the last chip I worked on, it took about two days to generate a timing report⁰. If you accidentally reference a signal from a distant module, not only will you not meet your timing budget for that path, the synthesis tool will allocate resources to try to make that path faster, which will slow down everything else⁵, making the entire timing report worthless⁶.

PL Trolling

I'd been feeling naked at my new gig, coding Verilog without any sort of static checking. I put off writing my own checker, because static analysis is one of those scary things you need a PhD to do, right? And writing a parser for SystemVerilog is a ridiculously large task⁷. But, it turns out that don't need much of a parser, and all the things I've talked about are simple enough that half an hour after starting, I had a tool that found seven bugs, with only two false positives. I expect we'll have 4x as much code by the time we're done, so that's 28 bugs from half an hour of work, not even considering the fact that two of the bugs were in heavily used macros.

I think I'm done for the day, but there are plenty of other easy things to check that will certainly find bugs (e.g, checking for regs/logic that are declared or assigned, but not used). Whenever I feel like tackling a self-contained challenge, there are plenty of not-so-easy things, too (e.g., checking if things aren't clock gated or power gated when they should be, which isn't hard to do statistically, but is non-trivial statically).

Huh. That wasn't so bad. I've now graduated to junior PL troll.

You ever notice that there's this funny threshold for getting to the front page on sites like HN? The exact threshold varies depending on how much traffic there is, but, for articles that aren't wildly popular, there's this moment when the article is at N-1 votes. There is, perhaps, a 60% chance that the vote will come and the article will get pushed to the front page, where it will receive a slew of votes. There is, maybe, a 40% chance it will never get the vote that pushes it to the front page, causing it to languish in obscurity forever.

It's non-optimal that an article that will receive 50 votes in expectation has a 60% chance of getting 100+ votes, and a 40% chance of getting 2 votes. Ideally, each article would always get its expected number of votes and stay on the front page for the expected number of time, giving readers exposure to the article in proportion to its popularity. Instead, by random happenstance, plenty of interesting content never makes it the front page, and as a result, the content that does make it gets a higher than optimal level of exposure.

You also see the same problem, with the sign bit flipped, on low traffic sites that push things to the front page the moment they're posted, like lobste.rs and the smaller sub-reddits: they displace links that most people would be interested in by putting links that almost no one cares about on the front page just so that the few things people do care about get enough exposure to be upvoted. On reddit, users "fix" this problem by heavily downvoting most submissions, pushing them off the front page, resulting in a problem that's fundamentally the same as the problem HN has.

Instead of implementing some simple and easy to optimize, sites pile on ad hoc rules. Reddit implemented the rising page, but it fails to solve the problem. On low-traffic subreddits, like r/programming the threshold is so high that it's almost always empty. On high-traffic sub-reddits, anything that's upvoted enough to make it to the rising page is already wildly successful, and whether or not an article becomes successful is heavily dependent on whether or not the first couple voters happen to be people who upvote the post instead of downvoting it, i.e., the problem of getting onto the rising page is no different than the problem of getting to the top normally.

HN tries to solve the problem by manually penalizing certain domains and keywords. That doesn't solve the problem for the 95% of posts that aren't penalized. For posts that don't make it to the front page, the obvious workaround is to delete and re-submit your post if it doesn't make the front page the first time around, but that's now a ban worthy offense. Of course, people are working around that, and HN has a workaround for the workaround, and so on. It's endless. That's the problem with "simple" ad hoc solutions.

There's an easy fix, but it's counter-intuitive. By adding a small amount of random noise to the rank of an article, we can smooth out the discontinuity between making it onto the front page and languishing in obscurity. The math is simple, but the intuition is even simpler¹. Imagine a vastly oversimplified model where, for each article, every reader upvotes with a fixed probability and the front page gets many more eyeballs than the new page. The result follows. If you like, you can work through the exercise with a more realistic model, but the result is the same².

Adding noise to smooth out a discontinuity is a common trick when you can settle for an approximate result. I recently employed it to work around the classic floating point problem, where adding a tiny number to a large number results in no change, which is problem when adding many small numbers to some large numbers³. For a simple example of applying this, consider keeping a reduced precision counter that uses loglog(n) bits to store the value. Let countVal(x) = 2^x and inc(x) = if (rand(2^x) == 0) x++⁴. Like understanding when to apply Taylor series, this is a simple trick that people are often impressed by if they haven't seen it before⁵.

Update: HN tried this! Dan Gackle tells me that it didn't work very well (it resulted in a lot of low quality junk briefly hitting the front page and then disappearing. I think that might be fixable by tweaking some parameters, but the solution that HN settled on, having a human (or multiple humans) put submissions that are deemed to be good or interesting into a "second chance queue" that boosts the submission onto the front page, works better than an a simple randomized algorithm with no direct human input could with any amount of parameter tweaking. I think this is also true of moderation, where the "new" dang/sctb moderation regime has resulted in a marked increase in comment quality, probably better than anything that could be done with an automated ML-based solution today — Google and FB have some of the most advanced automated systems in the world, and the quality of the result is much worse than what we see on HN.

Also, at the time this post was written (2013), the threshold to get onto the front page was often 2-3 votes, making the marginal impact of a random passerby who happens to like a submission checking the new page very large. Even during off peak times now (in 2019), the threshold seems to be much higher, reducing the amount of randomness. Additionally, the rise in the popularity of HN increased the sheer volume of low quality content that languishes on the new page, which would reduce the exposure that any particular "good" submisison would get if it were among the 30 items on the new page that would randomly get boosted onto the front page. That doesn't mean there aren't still problems with the current system: most people seem to upvote and comment based on the title of the article and not the content (to check this, read the comments of articles that are mistitled before someone calls this out for a partiular post — it's generally quite clear that most commenters haven't even skimmed the article, let alone read it), but that's a topic for a different post.

What's the first thing you do when you find a bug or see a missing feature in an open source project? Check out the project page and submit a patch!

Oh. Maybe their message is so encouraging that they get hundreds of pull requests a week, and the backlog isn't that bad.

Maybe not. Giant sucker than I am, I submitted a pull request even after seeing that. All things considered, I should consider myself lucky that it's possible to submit pull requests at all. If I'm really lucky, maybe they'll get around to looking at it one day.

I don't mean to pick on this particular project. I can understand how this happens. You're a dev who can merge pull requests, but you're not in charge of triaging bugs and pull requests; you have a day job, projects that you own, and a life outside of coding. Maybe you take a look at the repo every once in a while, merge in good pull requests, and make comments on the ones that need more work, but you don't look at all 116 open pull requests; who has that kind of time?

This behavior, eminently reasonable on the part of any individual, results in a systemic failure, a tax on new open source contributors. I often get asked how to get started with open source. It's easy for me to forget that getting started can be hard because the first projects I contributed to have a response time measured in hours for issues and pull requests¹. But a lot of people have experiences which aren't so nice. They contribute a few patches to a couple projects that get ignored, and have no idea where to go from there. It doesn't take egregious individual behavior to create a hostile environment.

That's kept me from contributing to some projects. At my last job, I worked on making a well-known open source project production quality, fixing hundreds of bugs over the course of a couple months. When I had some time, I looked into pushing the changes back to the open source community. But when I looked at the mailing list for the project, I saw a wasteland of good patches that were completely ignored, where the submitter would ping the list a couple times and then give up. Did it seem worth spending a week to disentangle our IP from the project in order to submit a set of patches that would, in all likelihood, get ignored? No.

If you have commit access to a project that has this problem, please own the process for incoming pull requests (or don't ask for pull requests in your repo description). It doesn't have to permanent; just until you have a system in place². Not only will you get more contributors to your project, you'll help break down one barrier to becoming an open source contributor.

In CPU design, most successful teams have a fairly long lineage and rely heavily on experienced engineers. When we look at CPU startups, teams that have a successful exist often have a core team that's been together for decades. For example, PA Semi's acquisition by Apple was a moderately successful exit, but where did that team come from? They were the SiByte team, which left after SiByte was acquired by Broadcom, and SiByte was composed of many people from DEC who had been working together for over a decade. My old company was similar: an IBM fellow collected the best people he worked with at IBM who was a very early Dell employee and then exec (back when Dell still did interesting design work), then split off to create a chip startup. There have been quite a few CPU startups that have raised tens to hundreds of millions and leaned heavily on inexperienced labor; fresh PhDs and hardware engineers with only a few years of experience. Every single such startup I know of failed¹.

This is in stark contrast to software startups, where it's common to see successful startups founded by people who are just out of school (or who dropped out of school). Why should microprocessors be any different? It's unheard of for a new, young, team to succeed at making a high-performance microprocessor, although this hasn't stopped people from funding these efforts.

In software, it's common to hear about disdain for experience, such as Zuckerberg's comment, "I want to stress the importance of being young and technical, Young people are just smarter.". Even when people don't explicitly devalue experience, they often don't value it either. As of this writing, Joel Spolsky's ”Smart and gets things done” is probably the most influential piece of writing on software hiring. Note that it doesn't say "smart, experienced, and gets things done.". Just "smart and gets things done" appears to be enough, no experience required. If you lean more towards the Paul Graham camp than the Joel Spolsky camp, there will be a lot of differences in how you hire, but Paul's advice is the same in that experience doesn't rank as one of his most important criteria, except as a diss.

Let's say you wanted to hire a plumber or a carptener, what would you choose? "Smart and gets things done" or "experienced and effective"? Ceteris paribus, I'll go for "experienced and effective", doubly so if it's an emergency.

Physical work isn't the kind of thing you can derive from first principles, no matter how smart you are. Consider South Korea after WWII. Its GDP per capita was lower than Ghana, Kenya, and just barely above the Congo. For various reasons, the new regime didn't have to deal with legacy institutions; and they wanted Korea to become a first-world nation.

The story I've heard is that the government started by subsidizing concrete. After many years making concrete, they wanted to move up the chain and start more complex manufacturing. They eventually got to building ships, because shipping was a critical part of the export economy they wanted to create.

They pulled some of their best business people who had learned skills like management and operations in other manufacturing. Those people knew they didn't have the expertise to build ships themselves, so they contracted it out. They made the choice to work with Scottish firms, because Scotland has a long history of shipbuilding. Makes sense, right?

It didn't work. For historical and geographic reasons, Scotland's shipyards weren't full-sized; they built their ships in two halves and then assembled them. Worked fine for them, because they'd be doing it at scale since the 1800s, and had world renowned expertise by the 1900s. But when the unpracticed Koreans tried to build ships using Scottish plans and detailed step-by-step directions, the result was two ship halves that didn't quite fit together and sunk when assembled.

The Koreans eventually managed to start a shipbuilding industry by hiring foreign companies to come and build ships locally, showing people how it's done. And it took decades to get what we would consider basic manufacturing working smoothly, even though one might think that all of the requisite knowledge existed in books, was taught in university courses, and could be had from experts for a small fee. Now, their manufacturing industries are world class, e.g., according to Consumer Reports, Hyundai and Kia produce reliable cars. Going from producing unreliable econoboxes to reliable cars you can buy took over a decade, like it did for Toyota when they did it decades earlier. If there's a shortcut to quality other than hiring a lot of people who've done it before, no one's discovered it yet.

Today, any programmer can take Geoffrey Hinton's course on neural networks and deep learning, and start applying state of the art machine learning techniques. In software land, you can fix minor bugs in real time. If it takes a whole day to run your regression test suite, you consider yourself lucky because it means you're in one of the few environments that takes testing seriously. If the architecture is fundamentally flawed, you pull out your copy of Feathers' “Working Effectively with Legacy Code” and repeatedly apply fixes.

This isn't to say that software isn't hard, but there are a lot of valueable problems that don't need a decade of hard-won experience to attack. But if you want to build a ship, and you "only" have a decade of experience with carpentry, milling, metalworking, etc., well, good luck. You're going to need it. With a large ship, “minor” fixes can take days or weeks, and a fundamental flaw means that your ship sinks and you've lost half a year of work and tens of millions of dollars. By the time you get to something with the complexity of a modern high-performance microprocessor, a minor bug discovered in production costs three months and millions of dollars. A fundamental flaw in the architecture will cost you five years and hundreds of millions of dollars².

Physical mistakes are costly. There's no undo and editing isn't simply a matter of pressing some keys; changes consume real, physical resources. You need enough wisdom and experience to avoid common mistakes entirely – especially the ones that can't be fixed.

Thanks to Sophia Wisdom for comments/corrections/discussion.

CPU internals series

• CPU bugs
• New CPU features since the 80s
• A brief history of branch prediction
• The cost of branches and integer overflow checking in real code
• Why CPU development is hard
• Verilog sucks, part 1
• Verilog sucks, part 2

2021 comments

In retrospect, I think that I was too optimistic about software in this post. If we're talking about product-market fit and success, I don't think the attitude in the post is wrong and people with little to no experience often do create hits. But now that I've been in the industry for a while and talked to numerous people about infra at various startups as well as large companies, I think creating high quality software infra requires no less experience than creating high quality physical items. Companies that decided this wasn't the case and hire a bunch of smart folks from top schools to build their infra have ended up with low quality, unreliable, expensive, and difficult to operate infrastructure. It just turns out that, if you have very good product-market fit, you don't need your infra to work. Your company can survive and even thrive while having infra that has 2 9s of uptime and costs an order of magnitude more than your competitor's infra or if your product's architecture means that it can't possibly work correctly. You'll make less money than you would've otherwise, but the high order bits are all on the product side. If you contrast that chip companies with inexperienced engineers that didn't produce a working product, well, you can't really sell a product that doesn't work even if you try. If you get very lucky, like if you happened to start deep learning chip company at the right time, you might get big company to acquire your non-working product. But, it's much harder to get an exit like that for a microprocessor.

Earlier this year, I interviewed with a well-known tech startup, one of the hundreds of companies that claims to have harder interviews, more challenging work, and smarter employees than Google¹. My first interviewer, John, gave me the standard tour: micro-kitchen stocked with a combination of healthy snacks and candy; white male 20-somethings gathered around a foosball table; bright spaces with cutesy themes; a giant TV set up for video games; and the restroom. Finally, he showed me a closet-sized conference room and we got down to business.

After the usual data structures and algorithms song and dance, we moved on to the main question: how would you design a classification system for foo²? We had a discussion about design tradeoffs, but the key disagreement was about the algorithm. I said, if I had to code something up in an interview, I'd use a naive matrix factorization algorithm, but that I didn't expect that I would get great results because not everything can be decomposed easily. John disagreed – he was adamant that PCA was the solution for any classification problem.

We discussed the mathematical underpinnings for twenty-five minutes – half the time allocated for the interview – and it became clear that neither of us was going to convince the other with theory. I switched gears and tried the empirical approach, referring to an old result on classifying text with LSA (which can only capture pairwise correlations between words)³ vs. deep learning⁴. Here's what you get with LSA:

Each color represents a different type of text, projected down to two dimensions; you might not want to reduce to the dimensionality that much, but it's a good way to visualize what's going on. There's some separation between the different categories; the green dots tend to be towards the bottom right, the black dots are a lot denser in the top half of the diagram, etc. But any classification based on that is simply not going to be very good when documents are similar and the differences between them are nuanced.

Here's what we get with a deep autoencoder:

It's not perfect, but the results are a lot better.

Even after the example, it was clear that I wasn't going to come to an agreement with my interviewer, so I asked if we could agree to disagree and move on to the next topic. No big deal, since it was just an interview. But I see this sort of misapplication of bog standard methods outside of interviews at least once a month, usually with the conviction that all you need to do is apply this linear technique for any problem you might see.

Engineers are the first to complain when consultants with generic business knowledge come in, charge $500/hr and dispense common sense advice while making a mess of the details. But data science is new and hot enough that people get a pass when they call themselves data scientists instead of technology consultants. I don't mean to knock data science (whatever that means), or even linear methods⁵. They're useful. But I keep seeing people try to apply the same four linear methods to every problem in sight.

In fact, as I was writing this, my girlfriend was in the other room taking a phone interview with the data science group of a big company, where they're attempting to use multivariate regression to predict the performance of their systems and decomposing resource utilization down to the application and query level from the regression coefficient, giving you results like 4000 QPS of foobar uses 18% of the CPU. The question they posed to her, which they're currently working on, was how do you speed up the regression so that you can push their test system to web scale?

The real question is, why would you want to? There's a reason pretty much every intro grad level computer architecture course involves either writing or modifying a simulator; real system performance is full of non-linear cliffs, the sort of thing where you can't just apply a queuing theory model, let alone a linear regression model. But when all you have are linear hammers, non-linear screws look a lot like nails.

In response to this, John Myles White made the good point that linear vs. non-linear isn't really the right framing, and that there really isn't a good vocabulary for talking about this sort of thing. Sorry for being sloppy with terminology. If you want to be more precise, you can replace each mention of "linear" with "mumble mumble objective function" or maybe "simple".

Here's the graph of a toy benchmark¹ of page-aligned vs. mis-aligned accesses; it shows a ratio of performance between the two at different working set sizes. If this benchmark seems contrived, it actually comes from a real world example of the disastrous performance implications of using nice power of 2 alignment, or page alignment in an actual system².

Except for very small working sets (1-8), the unaligned version is noticeably faster than the page-aligned version, and there's a large region up to a working set size of 512 where the ratio in performance is somewhat stable, but more so on our Sandy Bridge chip than our Westmere chip.

To understand what's going on here, we have to look at how caches organize data. By way of analogy, consider a 1,000 car parking garage that has 10,000 permits. With a direct mapped scheme (which you could call 1-way associative³), each of the ten permits that has the same 3 least significant digits would be assigned the same spot, i.e., permits 0618, 1618, 2618, and so on, are only allowed to park in spot 618. If you show up at your spot and someone else is in it, you kick them out and they have to drive back home. The next time they get called in to work, they have to drive all the way back to the parking garage.

Instead, if each car's permit allows it to park in a set that has ten possible spaces, we'll call that a 10-way set associative scheme, which gives us 100 sets of ten spots. Each set is now defined by the last 2 significant digits instead of the last 3. For example, with permit 2618, you can park in any spot from the set {018, 118, 218, …, 918}. If all of them are full, you kick out one unlucky occupant and take their spot, as before.

Let's move out of analogy land and back to our benchmark. The main differences are that there isn't just one garage-cache, but a hierarchy of them, from the L1⁴, which is the smallest (and hence, fastest) to the L2 and L3. Each seat in a car corresponds to an address. On x86, each addresses points to a particular byte. In the Sandy Bridge chip we're running on, we've got a 32kB L1 cache with 64-byte line size and, 64 sets, with 8-way set associativity. In our analogy, a line size of 64 would correspond to a car with 64 seats. We always transfer things in 64-byte chunks and the bottom log₂(64) = 6 bits of an address refer to a particular byte offset in a cache line. The next log₂(64) = 6 bits determine which set an address falls into⁵. Each of those sets can contain 8 different things, so we have 64 sets * 8 lines/set * 64 bytes/line = 32kB. If we use the cache optimally, we can store 32,768 items. But, since we're accessing things that are page (4k) aligned, we effectively lose the bottom log₂(4k) = 12 bits, which means that every access falls into the same set, and we can only loop through 8 things before our working set is too large to fit in the L1! But if we'd misaligned our data to different cache lines, we'd be able to use 8 * 64 = 512 locations effectively.

Similarly, our chip has a 512 set L2 cache, of which 8 sets are useful for our page aligned accesses, and a 12288 set L3 cache, of which 192 sets are useful for page aligned accesses, giving us 8 sets * 8 lines / set = 64 and 192 sets * 8 lines / set = 1536 useful cache lines, respectively. For data that's misaligned by a cache line, we have an extra 6 bits of useful address, which means that our L2 cache now has 32,768 useful locations.

In the Sandy Bridge graph above, there's a region of stable relative performance between 64 and 512, as the page-aligned version version is running out of the L3 cache and the unaligned version is running out of the L1. When we pass a working set of 512, the relative ratio gets better for the aligned version because it's now an L2 access vs. an L3 access. Our graph for Westmere looks a bit different because its L3 is only 3072 sets, which means that the aligned version can only stay in the L3 up to a working set size of 384. After that, we can see the terrible performance we get from spilling into main memory, which explains why the two graphs differ in shape above 384.

For a visualization of this, you can think of a 32 bit pointer looking like this to our L1 and L2 caches:

TTTT TTTT TTTT TTTT TTTT SSSS SSXX XXXX

TTTT TTTT TTTT TTTT TSSS SSSS SSXX XXXX

The bottom 6 bits are ignored, the next bits determine which set we fall into, and the top bits are a tag that let us know what's actually in that set. Note that page aligning things, i.e., setting the address to

???? ???? ???? ???? ???? 0000 0000 0000

was just done for convenience in our benchmark. Not only will aligning to any large power of 2 cause a problem, generating addresses with a power of 2 offset from each other will cause the same problem.

Nowadays, the importance of caches is well understood enough that, when I'm asked to look at a cache related performance bug, it's usually due to the kind of thing we just talked about: conflict misses that prevent us from using our full cache effectively⁶. This isn't the only way for that to happen -- bank conflicts and and false dependencies are also common problems, but I'll leave those for another blog post.

Resources

For more on caches on memory, see What Every Programmer Should Know About Memory. For something with more breadth, see this blog post for something "short", or Modern Processor Design for something book length. For even more breadth (those two links above focus on CPUs and memory), see Computer Architecture: A Quantitative Approach, which talks about the whole system up to the datacenter level.

Dear David,

I'm afraid my off the cuff response the other day wasn't too well thought out; when you talked about taking calc III and linear algebra, and getting resistance from one of your friends because "wolfram alpha can do all of that now," my first reaction was horror-- which is why I replied that while I've often regretted not taking a class seriously because I've later found myself in a situation where I could have put the skills to good use, I've never said to myself "what a waste of time it was to learn that fundamental mathematical concept and use it enough to that I truly understand it."

But could this be selection bias? It's easier to recall the math that I use than the math I don't. To check, let's look at the nine math classes I took as an undergrad. If I exclude the jobs I've had that are obviously math oriented (pure math and CS theory, plus femtosecond optics), and consider only whether I've used math skills in non-math-oriented work, here's what I find: three classes whose material I've used daily for months or years on end (Calc I/II, Linear Algebra, and Calc III); three classes that have been invaluable for short bursts (Combinatorics, Error Correcting Codes, and Computational Learning Theory); one course I would have had use for had I retained any of the relevant information when I needed it (Graduate Level Matrix Analysis); one class whose material I've only relied on once (Mathematical Economics); and only one class I can't recall directly applying to any non-math-y work (Real Analysis). Here's how I ended up using these:

Calculus I/II¹: critical for dealing with real physical things as well as physically inspired algorithms. Moreover, one of my most effective tricks is substituting a Taylor or Remez series (or some other approximation function) for a complicated function, where the error bounds aren't too high and great speed is required.

Linear Algebra: although I've gone years without, it's hard to imagine being able to dodge linear algebra for the rest of my career because of how general matrices are.

Calculus III: same as Calc I/II.

Combinatorics: useful for impressing people in interviews, if nothing else. Most of my non-interview use of combinatorics comes from seeing simplifications of seemingly complicated problems; combines well with probability and randomized algorithms.

Error Correcting Codes: there's no substitute when you need ECC. More generally, information theory is invaluable.

Graduate Level Matrix Analysis: had a decade long gap between learning this and working on something where the knowledge would be applicable. Still worthwhile, though, for the same reason Linear Algebra is important.

Real Analysis: can't recall any direct applications, although this material is useful for understanding topology and measure theory.

Computational Learning Theory: useful for making the parts of machine learning people think are scary quite easy, and for providing an intuition for areas of ML that are more alchemy than engineering.

Mathematical Economics: Lagrange multipliers have come in handy sometimes, but more for engineering than programming.

Seven out of nine. Not bad. So I'm not sure how to reconcile my experience with the common sentiment that, outside of a handful of esoteric areas like computer graphics and machine learning, there is no need to understand textbook algorithms, let alone more abstract concepts like math.

Part of it is selection bias in the jobs I've landed; companies that do math-y work are more likely to talk to me. A couple weeks ago, I had a long discussion with a group of our old Hacker School friends, who now do a lot of recruiting at career fairs; a couple of them, whose companies don't operate at the intersection of research and engineering, mentioned that they politely try to end the discussion when they run into someone like me because they know that I won't take a job with them².

But it can't all be selection bias. I've gotten a lot of mileage out of math even in jobs that are not at all mathematical in nature. Even in low-level systems work that's as far removed from math as you can get, it's not uncommon to be find a simple combinatorial proof to show that a solution that seems too stupid to be correct is actually optimal, or correct with high probability; even when doing work that's far outside the realm of numerical methods, it sometimes happens that the bottleneck is a function that can be more quickly computed using some freshman level approximation technique like a Taylor expansion or Newton's method.

Looking back at my career, I've gotten more bang for the buck from understanding algorithms and computer architecture than from understanding math, but I really enjoy math and I'm glad that knowing a bit of it has biased my career towards more mathematical jobs, and handed me some mathematical interludes in profoundly non-mathematical jobs.

All things considered, my real position is a bit more relaxed than I thought: if you enjoy math, taking more classes for the pure joy of solving problems is worthwhile, but math classes aren't the best use of your time if your main goal is to transition from an academic career to programming.

Cheers,
Dan

Russian translation available here

In the fall of 2000, I took my first engineering class: ECE 352, an entry-level digital design class for first-year computer engineers. It was standing room only, filled with waitlisted students who would find seats later in the semester as people dropped out. We had been warned in orientation that half of us wouldn't survive the year. In class, We were warned again that half of us were doomed to fail, and that ECE 352 was the weed-out class that would be responsible for much of the damage.

The class moved briskly. The first lecture wasted little time on matters of the syllabus, quickly diving into the real course material. Subsequent lectures built on previous lectures; anyone who couldn't grasp one had no chance at the next. Projects began after two weeks, and also built upon their predecessors; anyone who didn't finish one had no hope of doing the next.

A friend of mine and I couldn't understand why some people were having so much trouble; the material seemed like common sense. The Feynman Method was the only tool we needed.

1. Write down the problem
2. Think real hard
3. Write down the solution

The Feynman Method failed us on the last project: the design of a divider, a real-world-scale project an order of magnitude more complex than anything we'd been asked to tackle before. On the day he assigned the project, the professor exhorted us to begin early. Over the next few weeks, we heard rumors that some of our classmates worked day and night without making progress.

But until 6pm the night before the project was due, my friend and I ignored all this evidence. It didn't surprise us that people were struggling because half the class had trouble with all of the assignments. We were in the half that breezed through everything. We thought we'd start the evening before the deadline and finish up in time for dinner.

We were wrong.

An hour after we thought we'd be done, we'd barely started; neither of us had a working design. Our failures were different enough that we couldn't productively compare notes. The lab, packed with people who had been laboring for weeks alongside those of us who waited until the last minute, was full of bad news: a handful of people had managed to produce a working division unit on the first try, but no one had figured how to convert an incorrect design into something that could do third-grade arithmetic.

I proceeded to apply the only tool I had: thinking really hard. That method, previously infallible, now yielded nothing but confusion because the project was too complex to visualize in its entirety. I tried thinking about the parts of the design separately, but that only revealed that the problem was in some interaction between the parts; I could see nothing wrong with each individual component. Thinking about the relationship between pieces was an exercise in frustration, a continual feeling that the solution was just out of reach, as concentrating on one part would push some other critical piece of knowledge out of my head. The following semester I would acquire enough experience in managing complexity and thinking about collections of components as black-box abstractions that I could reason about a design another order of magnitude more complicated without problems — but that was three long winter months of practice away, and this night I was at a loss for how to proceed.

By 10pm, I was starving and out of ideas. I rounded up people for dinner, hoping to get a break from thinking about the project, but all we could talk about was how hopeless it was. How were we supposed to finish when the only approach was to flawlessly assemble thousands of parts without a single misstep? It was a tedious version of a deranged Atari game with no lives and no continues. Any mistake was fatal.

A number of people resolved to restart from scratch; they decided to work in pairs to check each other's work. I was too stubborn to start over and too inexperienced to know what else to try. After getting back to the lab, now half empty because so many people had given up, I resumed staring at my design, as if thinking about it for a third hour would reveal some additional insight.

It didn't. Nor did the fourth hour.

And then, just after midnight, a number of our newfound buddies from dinner reported successes. Half of those who started from scratch had working designs. Others were despondent, because their design was still broken in some subtle, non-obvious way. As I talked with one of those students, I began poring over his design. And after a few minutes, I realized that the Feynman method wasn't the only way forward: it should be possible to systematically apply a mechanical technique repeatedly to find the source of our problems. Beneath all the abstractions, our projects consisted purely of NAND gates (woe to those who dug around our toolbox enough to uncover dynamic logic), which outputs a 0 only when both inputs are 1. If the correct output is 0, both inputs should be 1. If the output is, incorrectly, 1, then at least one of the inputs must incorrectly be 0. The same logic can then be applied with the opposite polarity. We did this recursively, finding the source of all the problems in both our designs in under half an hour.

We excitedly explained our newly discovered technique to those around us, walking them through a couple steps. No one had trouble; not even people who'd struggled with every previous assignment. Within an hour, the group of folks within earshot of us had finished, and we went home.

I understand now why half the class struggled with the earlier assignments. Without an explanation of how to systematically approach problems, anyone who didn't intuitively grasp the correct solution was in for a semester of frustration. People who were, like me, above average but not great, skated through most of the class and either got lucky or wasted a huge chunk of time on the final project. I've even seen people talented enough to breeze through the entire degree without ever running into a problem too big to intuitively understand; those people have a very bad time when they run into a 10 million line codebase in the real world. The more talented the engineer, the more likely they are to hit a debugging wall outside of school.

What I don't understand is why schools don't teach systematic debugging. It's one of the most fundamental skills in engineering: start at the symptom of a problem and trace backwards to find the source. It takes, at most, half an hour to teach the absolute basics – and even that little bit would be enough to save a significant fraction of those who wash out and switch to non-STEM majors. Using the standard engineering class sequence of progressively more complex problems, a focus on debugging could expand to fill up to a semester, which would be enough to cover an obnoxious real-world bug: perhaps there's a system that crashes once a day when a Blu-ray DVD is repeatedly played using hardware acceleration with a specific video card while two webcams and record something with significant motion, as long as an obscure benchmark from 1994 is running¹.

This dynamic isn't unique to ECE 352, or even Wisconsin – I saw the same thing when TA'ed EE 202, a second year class on signals and systems at Purdue. The problems were FFTs and Laplace transforms instead of dividers and Boolean², but the avoidance of teaching fundamental skills was the same. It was clear, from the questions students asked me in office hours, that those who were underperforming weren't struggling with the fundamental concepts in the class, but with algebra: the problems were caused by not having an intuitive understanding of, for example, the difference between f(x+a) and f(x)+a.

When I suggested to the professor³ that he spend half an hour reviewing algebra for those students who never had the material covered cogently in high school, I was told in no uncertain terms that it would be a waste of time because some people just can't hack it in engineering. I was told that I wouldn't be so naive once the semester was done, because some people just can't hack it in engineering. I was told that helping students with remedial material was doing them no favors; they wouldn't be able to handle advanced courses anyway because some students just can't hack it in engineering. I was told that Purdue has a loose admissions policy and that I should expect a high failure rate, because some students just can't hack it in engineering.

I agreed that a few students might take an inordinately large amount of help, but it would be strange if people who were capable of the staggering amount of memorization required to pass first year engineering classes plus calculus without deeply understanding algebra couldn't then learn to understand the algebra they had memorized. I'm no great teacher, but I was able to get all but one of the office hour regulars up to speed over the course of the semester. An experienced teacher, even one who doesn't care much for teaching, could have easily taught the material to everyone.

Why do we leave material out of classes and then fail students who can't figure out that material for themselves? Why do we make the first couple years of an engineering major some kind of hazing ritual, instead of simply teaching people what they need to know to be good engineers? For all the high-level talk about how we need to plug the leaks in our STEM education pipeline, not only are we not plugging the holes, we're proud of how fast the pipeline is leaking.

Thanks to Kelley Eskridge, @brcpo9, and others for comments/corrections.