[geeks] Software Bloat

[Joshua D Boyd]

On Mon, Dec 17, 2001 at 01:52:42PM -0500, Greg A. Woods wrote:
>[ 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! ;-).

I fail to see how wide scale forcing is going on.  My home machines work just
fine with a minimum of MS Ware, and the one completely MS notebook I use 
doesn't have a single line of MS code newer than 5 years old.
 
If by forcing, you are refering to people trying to send you new Word files,
then try to use your local word processor to open them, and if that doesn't 
word, log onto the companies conversion server.  (cluster of IIS machines 
running the latest version of Office for converting documents out to saner 
formats).

>> 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!).

Yes, but they do it by breaking it up into logically seperate modules, as I
advocate in that hypothetical word processor below.  For instance, some of 
those monkeys are working on drivers, others on different add in programs, etc.
I suspect that part of the problem is not clearly enough defined APIs, and
programmers not knowing what is going on on the other side of the API.  Hence
advocating more readable code and introspective systems.
 
> The other more tangible (i.e. measurable, monitarily) problem with
> software bloat is that it makes software complex and hard to use.

I maintain that the chief cause of software being hard to use is 
maintainability.  OK, maybe not the chief cause, but a leading cause.  The
true leading cause is worrying about bullet points on the box more than the
user experience.  For companies that sorta care (like MS), the issue is 
compounded by not being able to rapidly try new changes in their unmaintainable
mountain of code.  Plus, they only care to a certain extent, I believe.
 
>>I seriously think that free software could be in a better position to get the
>>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,
>> 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 have a 10mbit switched lan, and I never have had trouble with streaming MP3s
off the server using XMMS.  I'm sure experiences vary.  I really mainly use
gcd since XMMS's CDaudio driver has a bug that cause loud pops between tracks.

I think that XMPS is a better way to go.  They are more flexible.  I'm not sure
if they actually have very many audio drivers though.  It would be interesting
to try writing some sometime.

There was a reaons that I picked WinAMP to talk about instead of XMMS, and that
is because I think that WinAMP does a better job than XMMS.
 
<snip>
 
>>Unfortunately, word processors are a 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.

I haven't dug into the C code, only the elisp.  The elisp code is large and
complicated, but I've found that it usually isn't too hard to interogate the
code to find out what it does.  But, I haven't done much major work either.
 
> 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.  :-)

Microsoft does not have a warehouse full of monkeys.  They give those monkeys
nicer offices than most of us get.

As to emacs, perhaps I was mistaken about it's maintainability.  Sometimes I 
think emacs tries to do too much.  Specifically, it sets itself up as an editor
and builds its UI around that, but for some tasks more is needed.  For one 
thing, it is extremely usefull to be able to be more graphical than emacs is
meant to be.  Plus, it is very complex and hard to use, and the help system 
isn't easy to use.  The documentation is readable enough to me, but I always
find it difficult to remeber how to navigate.  I think that Help should in 
general be GUI based if possible, and if not, well, I don't know.
 
>> 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.  :-)

Still haven't had a chance to look at Ruby.  Aside from better library support
(such as GTK and GNOME), what makes Ruby better for you than scheme?  Python?
Also, is the superior libraries for Ruby because Ruby makes it unusually easy
to create, or some other reason?
 
> Smalltalk would be ideal.

I hack some with smalltalk.  I like it's purity, especially in the case of
squeak, but I don't find it the most readable, nor do I find squeak to be
navigatable.  If the squeak people could hack in a manor to write and execute
machine code from inside the system (IE, so that every little extension doesn't
require a recompile of the VM), then it could make a pretty cool little OS.
 
> Scheme isn't bad though, and ANSI Common Lisp is OK too.

As much as I like scheme and lisp, I think that my parents would quickly become
frustrated trying to write and read it.

Now, one interesting thing I keep hearing about python is that it has fully 
formed s-expressions underneith, and that it is possible to access them from
python code.  Further, it has first class functions, although I should probably
verify that this means what I think it means before I blather too much more.

It has been suggested that python is what lisp was intended to be.  In 
particular, reportedly McCarthy didn't mean for people to be typing 
s-expressions forever, he meant to have an actuall syntax on top that then got
parsed into the lisp s-expressions before execution.  This could be just 
heresay though.
 
I also would be interested in having someone explain to me why they feel that
Smalltalk is superior to python someday.

>>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 (less
>>than they would need to spend on a site license of word presumably).
> 
> 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.

But, not all users can or want to do with less.  What is needed is to teach 
people to make do with what they can handle, then tackle new things as they can
use them.  My father is a good example of someone who would have been hard 
pressed to try to make do with much less in Excel (I don't think he used the
charting tool though) at his previous job.  And physics people use a whole 
different set of features.

With my extensible idea, I would ship a barebones spreadsheet.  It would have
a fully programmable scripting language, and easy methods for calling external
code, but other than that, little more than a grid, some basic calculation 
tools, and some super simple charting options. 

Then, for various prices ranging from absolutely free to bloody expensive, 
additional modules would be available, like more comprehensive charting, 
detailed statistical analysys, database bindings, network bindings, stock
analysis packages written on top of the statistics, charting, and networking
tools, etc.  The idea being to encourage people to think about what they need 
rather than just giving them tool overload before they have a clue about what
is happening.

SIAG displays some of this, except they just chuck everything in the package
rather than ask people to add modules seperately.
 
>>Writing systems like this in 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!  ;-)

Yeah, emacs detractors where exactly who I had in mind when I wrote that first
sentence.
 
> 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....

I started reading that, but only got to the part where they discussed having
the old corporation be a majority partner in the limited liability partnership,
with all the founders as minority partners, so that the IRS wouldn't tax them
like a corportation, but if things went wrong, the corporation would take the
legal fall rather than the individuals.  Very interesting stuff.  I should dig
it up and read more.

-- 
Joshua D. Boyd