Comment by DanielBMarkham | Hacker News Reader

Comment by DanielBMarkham | Hacker News Reader

Great article full of lots of insights. Here's some of the ones I got.

- People are generally happy with what they have: digging around is not a fun thing to do.

- It is very easy for the maintenance programmer to make assumptions about the preconditions for a piece of code that is not valid.

- Size of code is a critical metric for quality.

And most importantly (and probably overlooked), quality is just but one metric of software. The name of the game here is providing value to the customer, not about writing perfect code. John kind of throws that out there in a pro forma way, then goes ahead without digging any deeper. Oddly enough, I can't really draw any conclusions about static code analysis, the topic of the essay, without a clear definition from the author about what the trade-offs are. We're left with "just use it" as a conclusion.

After reading this, I wonder if programmers don't get stuck on the same general level of abstraction and this staying-in-the-same-level thinking introduces unnecessary code complexity. To illustrate, let's try a thought experiment.

Suppose there was no modern OS -- just a x86 compatible CPU and BIOS -- and you were supposed to put an image on the screen stored on a USB drive.

It would involve huge amounts of work -- code to get information from the drive, code to understand images, code to respond to the keyboard, etc.

The reason we can do this so easily today is that whatever we write is basically in a DSL that sits on top of other DSL/APIs. We are working at a higher level of abstraction.

I wonder if putting programming projects on a "code diet" isn't something we should try more often. Announce that whatever our solution is, it's not going to be more than 10KLOC. If we have to split into teams to provide layers, we will. Each team has 10KLOC and should create a DSL at their particular level of abstraction.

This forces us to keep project codebases very small, yet should provide just as much freedom to create very powerful software as we have today. I understand that many will say "but there's no way you're going to make any kind of useful layer of abstraction in 10K of code!" I disagree, but that a big can of worms to open up in a HN thread. The important question is this: should we create arbitrary limits on our abstraction layers as a way to enforce higher code quality?

Just thinking aloud.

> code diet . . . (limit of 10K lines)

Yes, sort-of, although . . .

A simple example 'in the small' to consider: function/procedure size. Should we (syntactically) limit functions to, say, <30 lines?

What we are really trying to do here is limit complexity. And that is not simply a result of length, but more of interrelation.

If we recall Dijkstra's intent with 'Structured Programming', it was to make complexity proportional to program length. It is not the total amount, but the way it is arranged or broken up. Strict size limits in effect sort-of do that -- they make complexity nearer constant (since it is bounded) within each part.

> should create a DSL at their particular level

And that leads to why the DSL idea (or something else to do a similar job) is more important than the simple limit idea. What we want primarily is different structuring.

In terms of the function-size example, we can (rather ideally) compare imperative with functional programming. FP languages seem to tend away from the length problem: because they are more trees of expressions instead of sequences. They have different structuring basics that control interrelation complexity more.

To put it briefly: we want it so you cannot add length without also adding 'depth' (of abstraction, of levels, of separation).

Expressed more fully here: 'Should there be hard limits on program part sizes?' http://www.hxa.name/notes/note-hxa7241-20101124T1927Z.html

I agree. But I think you've missed it. My point was about human behavior, not the innards of program structure.

To rephrase: would imposing arbitrary code length restrictions along with DSL-type training automatically drive programmers to write better quality code?

I believe the answer is yes. You are correct in that the technical issue is more complicated than that, but my point was asking if making an arbitrary rule would drive teams into making those kinds of design choices, instead of just being happy with the way things were and continuing to expand the code base ad infinitum. I was trying to draw in several lines of thought I gleaned from the essay and synthesize something new.

I also think there's a big difference in creating an arbitrary limit on function size and doing the same for an overall project. I wouldn't like the idea of limiting function size at all. You can do a lot in 10K lines of code. There's a lot more freedom there. Once again, my thrust is human behavior. Telling somebody that each little piece of code they write is subject to somewhat arbitrary restrictions is a lot more onerous to me than simply making a "budget" for the entire project.

Abstractions are partial and leaky models of the thing they abstract over. When you build your system as a tall, skinny tower of small abstractions, you are trading one problem for another. Eventually you will need to thread some new functionality all the way through your stack, or you will have to debug a problem that requires understanding cross-layer interactions, and you will end up spending much of your time fighting your abstraction choices.

Unfortunately there is no silver bullet. No single recipe will tell you how to cut up every project into modules. You have to work hard to find the right decomposition for your problem. Arbitrary size limits are as likely to hurt you as help you.

That said, programmers should indeed strive to write less code, as a rule of thumb.

10KLOC per team is admirable, but one of the long-term projects I'm most excited about is Alan Kay's "Inventing Fundamental New Computing Technologies" project. They're trying to get under 20KLOC for an entire operating system + all "common" applications!

http://vpri.org/html/work/ifnct.htm

It's really exciting, and they've already made some great progress towards that goal. I recommend reading their first year progress report as it has a lot of the most exciting stuff about this (they just finished year 5):

http://www.vpri.org/pdf/tr2007008_steps.pdf

Reply on news.ycombinator.com