[geeks] Software Bloat

[Greg A. Woods]

[ On Monday, December 17, 2001 at 10:50:15 (-0500), Joshua D Boyd wrote: ]
> Subject: Re: [geeks] Software Bloat
>
> Most people who complain about software bloat have a sort-of legitimate 
> complaint.  Only sort-of because nobody is forcing them to buy new software.

Oh how wrong you are.  About the 'forcing' part, that is!  ;-)

The likes of M$ have long ago learned how to "force" people to buy new
software.  Their techniques are many and varied, but when put together
it really does amount to _forcing_ and is no different than extortion,
and we should all know by now that extortion is illegal in most places
in the world, even if it isn't enforced (like it's not in this case in
the USA! ;-).

> The issue with software bloat (and what gets people really upset though they 
> don't know it) is maintainability.

That's one of them, though M$ have proven that if you hire enough
monkeys they really can write 30 million lines of code that mostly works
(though what it all does nobody will ever know!).

The other more tangible (i.e. measurable, monitarily) problem with
software bloat is that it makes software complex and hard to use.

> I seriously think that free software could be in a better position to get these
> stupid media things right.  I think the biggest and most immediate need in 
> this area is to get ALSA into the linux kernel.  I don't know if NetBSD or
> FreeBSD has anything similar going on.  I gave up trying to install alsa 
> myself, but my understanding is that in addition to better hardware support for
> multi-chanel hardware, it is also supposed to smooth out a number of the 
> problems that I run into with esd versus /dev/dsp (mainly, most of my programs
> use /dev/dsp, but parts of GNOME insist on having esd, and they two are a pain
> to get to co-exist).  

I'd been using the command-line version of mpg123 to play MP3s and to
listen to streaming audio (i.e. Internet radio).  When xmms appeared in
the NetBSD pkgsrc collection I decided to give it a try (because I also
found a NAS plug-in for it).  It worked OK, though the graphics weren't
very stunning, or in synchronisation with the audio, on my 10-mbit
network, not even when I gave my Xterm a dedicated switch port (the
bandwidth's not the problem -- it's the latency, even on a switched LAN!).
Even so I played with some of the thousands of "skins" for it.  What a
stupid silly waste of time, even though some were quite attractive!

I eventually gave up on it though.  In doing so I also discovered the
new version of mpg123 has at least a compile-time option to do NAS too,
so I'm nearly in heaven with my audio capabilities, and I don't give a
hoot about the graphics (if I did I've have shelled out ~$750[usa] for
an HMX-Pro24 to get real colour instead of this 8-bit imitation I'm
using now! ;-).  I might even have been able to get a 100baseTX port for
it too, and thus cut the latency down perhaps enough to make it work!

> Unfortunately, a word processor is a whole different scale of maintainability.
> Still, I think there must be a way.  Emacs isn't bad.  It seems to be easy to
> port to new platforms, which often is a good sign for maintainability, plus 
> lisp is usually considered a very maintainable language.

The GNU Emacs C source is getting really bloated, and in some senses
much of the elisp code is bloated too.  However the separation does at
least help make the maintenance manageable.

It's actually taken a great deal of very detailed effort to modernise
the portability of the C code in GNU Emacs, and it still relies on what
one migh call strictly non-standard systems features to make it actually
usable.  However it was done by a small team of extremely talented
people, not a warehouse full of monkeys.  :-)

>  Maybe the next time
> a team decides to take on the wordprocessor market, they should consider just
> building a small simple little run time, and then build the rest on top using
> python or guile (I'm partial to guile, but python might be more palletable to
> people like my parents).

Ruby would be better.  :-)

Smalltalk would be ideal.

Scheme isn't bad though, and ANSI Common Lisp is OK too.

>  Then when you release a version that only has 50% of
> the features, when mid sized company X says that they need such and such that 
> you left out, you can offer to add that feature for a very low price (say less
> than they would need to spend on a site license of word).

What we (i.e. software developers and computer types in general) really
need to do is to find a way to teach the masses how to do more with less.

> Writing systems like this in a scripting language could be considered a sign of
> bloat by some people.  It probably would require more disk space.  But, it 
> should make the software more maintainable, and hopefully faster (easier to 
> work with language usually means easier to optimize, plus you can always
> rewrite critical parts in C if need be), and if it is those 2 things, most
> people won't care about the disk space.

You're right about that first sentence, at least according to every
Emacs detractor I've ever heard from!  ;-)

However you're also right on the money in the last sentence too.  Look
around on the net for the "autobiography" about the development of
AutoCAD and the decision to use lisp as its extension language.
Everything he says about that decision is still true today, other than
the fact that there are some other capable languages to make the
decision to use lisp a little harder....

-- 
								Greg A. Woods

+1 416 218-0098;  <gwoods at acm.org>;  <g.a.woods at ieee.org>;  <woods at robohack.ca>
Planix, Inc. <woods at planix.com>; VE3TCP; Secrets of the Weird <woods at weird.com>