3 ms·

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 d

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.

hxa7241 15y ago
> 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 http://www.hxa.name/notes/note-hxa7241-20101124T1927Z.html
- DanielBMarkham 15y ago
  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.
abstractfactory 15y ago
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.
ehsanu1 15y ago
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. Wow, do people really think 10k LOC not enough to build up useful abstraction layers? Tell that to Alan Kay, who is working with the Viewpoints Research Institute working on building a full system (from the OS kernel to GUI apps like document editors) in 20k LOC. While they're not there yet, they have a 200 LOC TCP/IP implementation, 800 LOC graphics system, comparable to Cairo (which is 20k LOC of C if I remember correctly), and many other achievements. [1] They're able to do this partly due to their language-oriented designs: they create specialized languages for each system. Note that the compilers for these languages are included in the LOC-counts given above. These are not general-purpose languages, but DSLs, and they are written in a language that is specialized for writing languages, naturally. [2] [1] See the STEPS progress reports for more details: http://vpri.org/html/writings.php http://vpri.org/html/writings.php [2] OMeta: http://www.tinlizzie.org/ometa/ http://www.tinlizzie.org/ometa/
ehsanu1 15y ago
My reply was killed, but I have no idea why, since it seems like a reasonable reply. Here it is again: 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. Wow, do people really think 10k LOC not enough to build up useful abstraction layers? Tell that to Alan Kay, who is working with the Viewpoints Research Institute working on building a full system (from the OS kernel to GUI apps like document editors) in 20k LOC. While they're not there yet, they have a 200 LOC TCP/IP implementation, 800 LOC graphics system, comparable to Cairo (which is 20k LOC of C if I remember correctly), and many other achievements. [1] They're able to do this partly due to their language-oriented designs: they create specialized languages for each system. Note that the compilers for these languages are included in the LOC-counts given above. These are not general-purpose languages, but DSLs, and they are written in a language that is specialized for writing languages, naturally. [2] [1] See the STEPS progress reports for more details: http://vpri.org/html/writings.php http://vpri.org/html/writings.php [2] OMeta: http://www.tinlizzie.org/ometa/ http://www.tinlizzie.org/ometa/
apu 15y ago
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 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 http://www.vpri.org/pdf/tr2007008_steps.pdf

hxa7241 15y ago

> 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 http://www.hxa.name/notes/note-hxa7241-20101124T1927Z.html

DanielBMarkham 15y ago
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.

abstractfactory 15y ago

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.

ehsanu1 15y ago

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. Wow, do people really think 10k LOC not enough to build up useful abstraction layers? Tell that to Alan Kay, who is working with the Viewpoints Research Institute working on building a full system (from the OS kernel to GUI apps like document editors) in 20k LOC. While they're not there yet, they have a 200 LOC TCP/IP implementation, 800 LOC graphics system, comparable to Cairo (which is 20k LOC of C if I remember correctly), and many other achievements. [1] They're able to do this partly due to their language-oriented designs: they create specialized languages for each system. Note that the compilers for these languages are included in the LOC-counts given above. These are not general-purpose languages, but DSLs, and they are written in a language that is specialized for writing languages, naturally. [2] [1] See the STEPS progress reports for more details: http://vpri.org/html/writings.php http://vpri.org/html/writings.php [2] OMeta: http://www.tinlizzie.org/ometa/ http://www.tinlizzie.org/ometa/

ehsanu1 15y ago

My reply was killed, but I have no idea why, since it seems like a reasonable reply. Here it is again: 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. Wow, do people really think 10k LOC not enough to build up useful abstraction layers? Tell that to Alan Kay, who is working with the Viewpoints Research Institute working on building a full system (from the OS kernel to GUI apps like document editors) in 20k LOC. While they're not there yet, they have a 200 LOC TCP/IP implementation, 800 LOC graphics system, comparable to Cairo (which is 20k LOC of C if I remember correctly), and many other achievements. [1] They're able to do this partly due to their language-oriented designs: they create specialized languages for each system. Note that the compilers for these languages are included in the LOC-counts given above. These are not general-purpose languages, but DSLs, and they are written in a language that is specialized for writing languages, naturally. [2] [1] See the STEPS progress reports for more details: http://vpri.org/html/writings.php http://vpri.org/html/writings.php [2] OMeta: http://www.tinlizzie.org/ometa/ http://www.tinlizzie.org/ometa/

apu 15y ago

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 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 http://www.vpri.org/pdf/tr2007008_steps.pdf