g r o t t o 1 1

Peeve Farm
Breeding peeves for show, not just to keep as pets
  Blog \Blôg\, n. [Jrg, fr. Jrg. "Web-log".
     See {Blogger, BlogSpot, LiveJournal}.]
     A stream-of-consciousness Web journal, containing
     links, commentary, and pointless drivel.


On My Blog Menu:

InstaPundit
USS Clueless
James Lileks
Little Green Footballs
As the Apple Turns
Entropicana
Cold Fury
Capitalist Lion
Red Letter Day
Eric S. Raymond
Tal G in Jerusalem
Secular Islam
Aziz Poonawalla
Corsair the Rational Pirate
.clue

« ? Blogging Brians # »





Book Plug:

Buy it and I get
money. I think.
BSD Mall




 10/6/2003 -  10/8/2003
 9/29/2003 -  10/5/2003
 9/22/2003 -  9/28/2003
 9/15/2003 -  9/21/2003
  9/8/2003 -  9/14/2003
  9/1/2003 -   9/7/2003
 8/25/2003 -  8/31/2003
 8/18/2003 -  8/24/2003
 8/11/2003 -  8/17/2003
  8/4/2003 -  8/10/2003
 7/28/2003 -   8/3/2003
 7/21/2003 -  7/27/2003
 7/14/2003 -  7/20/2003
  7/7/2003 -  7/13/2003
 6/30/2003 -   7/6/2003
 6/23/2003 -  6/29/2003
 6/16/2003 -  6/22/2003
  6/9/2003 -  6/15/2003
  6/2/2003 -   6/8/2003
 5/26/2003 -   6/1/2003
 5/19/2003 -  5/25/2003
 5/12/2003 -  5/18/2003
  5/5/2003 -  5/11/2003
 4/28/2003 -   5/4/2003
 4/21/2003 -  4/27/2003
 4/14/2003 -  4/20/2003
  4/7/2003 -  4/13/2003
 3/31/2003 -   4/6/2003
 3/24/2003 -  3/30/2003
 3/17/2003 -  3/23/2003
 3/10/2003 -  3/16/2003
  3/3/2003 -   3/9/2003
 2/24/2003 -   3/2/2003
 2/17/2003 -  2/23/2003
 2/10/2003 -  2/16/2003
  2/3/2003 -   2/9/2003
 1/27/2003 -   2/2/2003
 1/20/2003 -  1/26/2003
 1/13/2003 -  1/19/2003
  1/6/2003 -  1/12/2003
12/30/2002 -   1/5/2003
12/23/2002 - 12/29/2002
12/16/2002 - 12/22/2002
 12/9/2002 - 12/15/2002
 12/2/2002 -  12/8/2002
11/25/2002 -  12/1/2002
11/18/2002 - 11/24/2002
11/11/2002 - 11/17/2002
 11/4/2002 - 11/10/2002
10/28/2002 -  11/3/2002
10/21/2002 - 10/27/2002
10/14/2002 - 10/20/2002
 10/7/2002 - 10/13/2002
 9/30/2002 -  10/6/2002
 9/23/2002 -  9/29/2002
 9/16/2002 -  9/22/2002
  9/9/2002 -  9/15/2002
  9/2/2002 -   9/8/2002
 8/26/2002 -   9/1/2002
 8/19/2002 -  8/25/2002
 8/12/2002 -  8/18/2002
  8/5/2002 -  8/11/2002
 7/29/2002 -   8/4/2002
 7/22/2002 -  7/28/2002
 7/15/2002 -  7/21/2002
  7/8/2002 -  7/14/2002
  7/1/2002 -   7/7/2002
 6/24/2002 -  6/30/2002
 6/17/2002 -  6/23/2002
 6/10/2002 -  6/16/2002
  6/3/2002 -   6/9/2002
 5/27/2002 -   6/2/2002
 5/20/2002 -  5/26/2002
 5/13/2002 -  5/19/2002
  5/6/2002 -  5/12/2002
 4/29/2002 -   5/5/2002
 4/22/2002 -  4/28/2002
 4/15/2002 -  4/21/2002
  4/8/2002 -  4/14/2002
  4/1/2002 -   4/7/2002
 3/25/2002 -  3/31/2002
 3/18/2002 -  3/24/2002
 3/11/2002 -  3/17/2002
  3/4/2002 -  3/10/2002
 2/25/2002 -   3/3/2002
 2/18/2002 -  2/24/2002
 2/11/2002 -  2/17/2002
  2/4/2002 -  2/10/2002
 1/28/2002 -   2/3/2002
 1/21/2002 -  1/27/2002
 1/14/2002 -  1/20/2002
  1/7/2002 -  1/13/2002
12/31/2001 -   1/6/2002
12/24/2001 - 12/30/2001
12/17/2001 - 12/23/2001
Monday, July 29, 2002
12:45 - The Open Source Essays
http://www.denbeste.nu/cd_log_entries/2002/07/OpenSourcepart1.shtml

(top) link
There's a well-worth-reading series of essays on the nature of software development and how open-source fits into it over at USS Clueless, sparked by a one-on-one meeting with Eric S. Raymond. There's good stuff there.

I've been of the mind for a long time that open-source software works best for infrastructural, well-defined, server-side software that is intended to serve a purpose according to a spec (e.g. an RFC). But it doesn't work very well for consumer software that requires delivery deadlines, UI guidelines, corporate alliances, codec licensing, and so on. In other words, open-source works great for servers, but it's miserable for desktops.

(By this token, I've noted how Linux makes a dandy server but a joke of a consumer desktop-- while Windows makes a perfectly fine desktop but a laughable server. The design goals of the two genres of computing are entirely different, and they're respectively best served by different models of software development.)

Then there's the question of software bloat and Moore's Law, and the position that software bloat is more a conscious result of coding for reliability and quick time-to-market than it is a consequence of too many undisciplined kids being hired off the streets.

There are numerous ways in which this tradeoff plays out. For example, most embedded code is written in C, which doesn't hold your hand and pretty much requires you to do everything yourself. More modern languages like C++ and Java offer considerable assets to the programmer in terms of handling automatically things which a C programmer would have to do directly. On the other hand, you have to load a much bigger runtime system (consuming memory) and a lot of the code generated by the language runs less efficiently than would comparable C-code (decreasing execution speed). A competent C++ programmer could probably finish his program sooner and it would usually have far fewer bugs, though, and if the hardware can sustain the lowered efficiency of the code, it's still probably the right thing to do.

His points are good, but I'd feel better having expanded on them a little. Yes, it's true that as codebases grow by orders of magnitude, so does the risk of bugs and of delay. But there are ways to mitigate that. Object-oriented programming, for instance, is a design initiative whose entire point is in making large-scale projects react like small-scale projects by reducing the number of interfaces between modules that the programmer has to deal with manually. But den Beste is right-- OO is slower than non-OO code, and so software that's written to take advantage of OO design principles might get to market quicker and be more bug-free, but it'll also be slower. As a matter of fact, that's a good deal of what's behind OS X's perceived slowness: Cocoa is a very OO-heavy development platform.

But, again, there are ways to mitigate this. The way the development process works these days in an OO-heavy project is for the first iteration of something to be done in as high-level a coding style as possible, using as many OO elements as possible, and delivering the promised features in a timely manner without overly many bugs. This release will be sluggish in execution; but in the second iteration, that's where you start optimizing. You take the components that represent the biggest performance hits and you re-code them in C. Then, in the next iteration, you take the C parts that cause the biggest performance hits and re-code them in assembly. The newest and riskiest code remains OO, but as the code matures and the engineering team comes to know it well, it evolves downward to lower-level implementations that are a lot faster-- and a lot less risky to write that way now than it would have been if it had been done that way at the outset. New OO features will tend to suck away the performance benefit gained by the low-level optimizations, but in a well-managed project the result will be a net gain in speed and in functionality.

The downside of this development process is that it takes a long time and the initial impressions in the public are of something that's very slow. But, once again, sometimes a company's goal is more about feature delivery than about absolute speed; and besides, speed will always increase with time. Whether it's because of better hardware or better-implemented iterations of the software, the apps will get faster as they mature. And in the meantime, we've had those cool features to play with.

It's not a viable development plan for all the classes of software that den Beste mentions, or even for most of them. But for consumer multimedia software, it does a pretty good job, I think.

Back to Top


© Brian Tiemann