Hacker News Reader

Kay's assertion seems incredible -- he really has to prove it.

What assertion, exactly? That the personal computing stack can be implemented in 20K LOC? They've already achieved the bulk of it, so that claim no longer qualifies as incredible.

Pooh-poohing this staggering achievement because they didn't reinvent personal computing while they were at it really takes the cake for moving the bar. If someone had gotten all the world's recorded music on a thumb drive in 1970, would you have complained that they didn't write the music themselves?

What assertion, exactly? That the personal computing stack can be implemented in 20K LOC?

No, the assertion from the article that "99% or even 99.9% of the effort that goes into creating a large software system is not productive."

While it's very interesting and frankly astonishing that they've been able to reimplement things that are fairly well understood in 100x less code, this is not at all the same as proving the assertion that these things could have been originally done in 100x less code. I hope that it's true that they could have been -- it's exciting to think that it might be true -- but it doesn't seem to be a claim that STEPS proves, or tries to, from the explicit goal of reusing concepts and designs from other OSes.

To build that personal computing environment, they had to solve various problems, including compilation, drawings, text editing, and networking. To me, the set is sufficiently diverse to make full generalization probable. It may take a genius to apply this to other domains, but I'm confident it can be done. Once it is, your average programmer can begin to be 10 times more productive, or more.

First, Kay didn't write the article.

Second, sorry, but I'm not buying this response at all. These guys have done something that all conventional thinking about software complexity would say was impossible. They've refuted something fundamental about universal practice. Seems to me the only open-minded response is to be flabbergasted and ask what else we need to question.

To say (I'm exaggerating how it sounds) "Oh, well, sure, they did that impossible, but this other impossible over here, that's the one that really matters" just seems like rationalization to me.

Oh and also, it's at least three orders of magnitude, not two.

The supposition was attributed to Kay:

"Alan Kay speculates in this talk that 99% or even 99.9% of the effort that goes into creating a large software system is not productive."

This is the claim.

Without in any way diminishing the astonishing accomplishments of the STEPS team, let's remember that they've spent (are spending) five years to write 20K lines of code. This doesn't sound like the level of effort is 1000 (or 100, or possibly even 10) times less for what they've accomplished than it would have been had they implemented exactly the same functionality in, say, Java. Would the Java code have been 1000 times bigger? It seems quite likely that it would have! But the bulkiness of the end product's source code doesn't determine the amount of effort that went into building it.

Could it be that they spent four and a half years figuring this new system out, and a few weeks writing the 20K lines of source? It could; I haven't read most of their papers. If that was the case, then that's what needs to be pointed out to refute the assumption that they're spending as much or almost as much effort on the end product (but with astonishingly little source code required to specify it).

You do have a good point that one should consider not just the code size but the effort to get there (though let's not forget the effort to maintain and extend it over time). But are you sure you're framing it correctly? It seems unfair to compare the effort it takes to pioneer a fundamentally new approach to the effort it takes to implement a common one. That's like comparing the guys who have to cut a tunnel through mountain rock to the ones who get to drive through it later. We have no idea how easy it might get to build new systems their way once the relevant techniques were absorbed by industry. The founding project is no basis for predicting that, other than that historically these things get far easier as the consequences are worked out over time.

What we do know from general research (at least, I've read this many times - anyone know the source?) is that programmer effort tends to be about the same per line of code. That's one reason everyone always cites for higher-level languages being better. Maybe that result doesn't hold up here, but it seems like a reasonable baseline.

Yes, it is incredible. (Edit: ah okay, not the assertion I thought of) And they mostly did it. Conclusion: there is a silver bullet.

If you can do a second draft with 10 times less code, then at least 90% of the first draft's complexity was accidental. By definition, so to speak. The question of avoiding that accidental complexity at the first try is a separate question.

The VPRI did find particular abstractions, embodied in their various Domain Specific Languages. Implicit parallelism (not concurrency) was tested in one of their languages (Nile), for 2.5 drawing. The problem was embarrassingly parallel to begin with, but they only had to modify the runtime to parallelize it (30 times faster with 40 cores). I also believe they have some form of implicit concurrency.

Also, it doesn't matter if they didn't invent some new ground-breaking abstraction. Because they just showed that applying the right old ideas in a systematic ways can have a tremendous effect. Now the industry just have to wake up.

> The question of avoiding that accidental complexity at the first try is a separate question.

But is that not the more important question? -- how much effort it takes to design software (which surely is the gist of Brooks' observation).

If the final code is much smaller, yet it took as long to design/write, what has been gained? Something, certainly (easier to manipulate, reuse), and furthermore there must be a fairly good relation between size and effort, yet it is the effort to create that is the key matter here.

Is the effort to create, really the key matter? Typically most of the cost is incurred in other activities, such as maintenance of software after the initial release.

Not always, but there is software that you write once, and then forget. For some shops (proprietary and custom software, mostly), the cost of the first try is what counts most. Nevertheless, I addressed that effort to create: geniuses write languages, and the rest of us use them. And with sufficiently good compilation languages, I bet we wouldn't need a genius to implement a worthwhile language.

But if given some set of tasks and a program A which performs them one can show that there exists a program B which performs the same tasks and is 100x smaller than program A (taking into account language/framework implementations) doesn't that show that at least 99% of the complexity of program A was not essential ?

That's incoherent.

If you accept the claims of

> People regularly say they translated their system from language A to language B and got 10-100 times code-size reductions.

then it's clearly false at least for first systems that

> there is essential complexity in software, and it is the dominant factor.

Well, it should really say something more like 'essential complexity in software development'. The size of the software does not simply, directly represent the effort -- making compacter code might take more effort, and it is only because of the extra work of design iteration that improvements were possible.

But there are various things involved so I am certainly not sure.