Lambda the Ultimate

inactiveTopic Linus Torvalds on Coding style
started 3/6/2002; 8:49:13 AM - last post 3/7/2002; 2:59:45 PM
Dan Shappir - Linus Torvalds on Coding style  blueArrow
3/6/2002; 8:49:13 AM (reads: 1661, responses: 5)
Linus Torvalds on Coding style
I'm not claiming to be deep, I'm claiming to do it for fun.

Linus on software design, and the lack thereof. Not really about programming languages (ok not at all), but about the design/implementation cycle in general, of which programming languages play an important part.

Posted to Software-Eng by Dan Shappir on 3/6/02; 8:52:35 AM

Frank Atanassow - Re: Linus Torvalds on Coding style  blueArrow
3/6/2002; 10:37:41 AM (reads: 842, responses: 0)
The problem with "singlemindedness and strict control" (or "design") is that it sure gets you from point A to point B in a much straighter line, and with less expenditure of energy, but how the HELL are you going to consistently know where you actually want to end up? It's not like we know that B is our final destination.

Wow, this is a telling statement. I guess "specification" is not in Linus' vocabulary.

If this is the attitude of most Linux developers and scripters, I suddenly understand a lot more about them.

Doing programming for fun is fine. Indeed, whatever your work is, I think that if you don't find it fun most of the time, you should find some other kind of work. But I don't think we should substitute `having fun' for `making progress', at least not in the big picture.

Let me tell you what I find really disappointing, though. I see software development as something with many more dimensions than simply programming, and I enjoy almost all of them. I enjoy specification, implementation design, coding, proof and verification, and sometimes even testing. Algorithm design, semantic modelling, program transformation, compiler and tool design, etc., are all part and parcel of this, and if you look at them deeply enough (as with most any topic, actually) they get more and more interesting.

What's disappointing, then, is that so many people seem to enjoy only the coding part, and this is the only way they are willing to look at a program: through the source code.

Perhaps Linus is in this group, and that's why he has to rationalize away the need for a more structured approach to development.

Frank Atanassow - Re: Linus Torvalds on Coding style  blueArrow
3/6/2002; 11:06:51 AM (reads: 848, responses: 0)
Please allow me to short-circuit the person who is going to reply to the above post. Here is what you will say:

Frank, you pointy-headed geek, your characterization of software development by a list of highfalutin academic balderdash which omits such important activities as debugging, low-level optimization, manual inlining and whatnot also betrays the fact that you also rationalize away development concerns that you yourself find unenjoyable. There are many people who enjoy these dimensions, so maybe this is a case of the pot calling the kettle black?
Yeah, I admit I am not crazy about these activities. But here is the way I see it: I find them repetitive and redundant, which is why I try to avoid them from the outset by using statically typed declarative languages and compilers that can do these things for me; I think that any person who works with computers, first and foremost, wants to avoid repetitive activities, i.e., jobs which the computer can do for them. For me, anything a computer can do for you is by definition meaningless and banal. Computers only push symbols according to a recipe; it's people who do the thinking.

Sure, computers can't do low-level optimization, etc. as well as humans sometimes, but I guess I'm more willing to tolerate some constant factors more than bit-twiddlers, because I have (what I find to be) more interesting things to do.

scruzia - Re: Linus Torvalds on Coding style  blueArrow
3/6/2002; 10:33:21 PM (reads: 814, responses: 1)
I don't think I'm the person who you were aiming to short-circuit. I do agree with you about the many dimensions of software development, but:

Ouch, you omit DOCUMENTATION completely. Specification is not documentation. A very important part of software development is making things understandable to people who read English more easily than they read mathematical specs.

And there is a lot of art involved these days, in making software in the form of tools that help people get their job done. In such situations, ahead-of-time specification is far less important than prototyping and ongoing communication with the users of the tool (even if the main user is the other side of your own brain). If your goal is to come up with something that will be used, you need to iterate with the user(s) on figuring out what's useful, and what form it should take. This exploration can be one of the more enjoyable parts of software development, and making detailed specs of each experiment of this kind is usually a big waste of time.

That said, I see Linus' statement as being much less applicable to things like a Linux kernel, than to some kinds of application software.

Frank Atanassow - Re: Linus Torvalds on Coding style  blueArrow
3/7/2002; 7:14:44 AM (reads: 840, responses: 0)
To me, documentation is part of specification and implementation.

Michael Christopher Vanier - Re: Linus Torvalds on Coding style  blueArrow
3/7/2002; 2:59:45 PM (reads: 757, responses: 0)
Frank, I don't think that Linus' argument was against "specification" per se but against over-specification. When I write code I almost always write a specification first, but I have yet to write one that didn't mutate dramatically as I learned more about the problem I was trying to solve. Maybe this isn't true for all problems, but it seems pretty typical to me. That's why I tend to advocate prototyping more than strict specifications, because the prototype is the tool that helps you figure out what the specification should be in the first place! Now, if you restrict "specification" to mean only "what the program should do", then you might be able to design it up-front and not change it (but usually not even then... there's always another feature). However, if specification also covers implementation, then my experience is that prototyping is more useful than trying to figure out everything in advance (which may not be what you're advocating, but a lot of what I've read on specifications makes it sound like that's what they advocate).