Account Options

  1. Sign in
The old Google Groups will be going away soon.
Switch to the new Google Groups.
Google Groups Home
« Groups Home
Message from discussion Small, fast software (Re: Writing fast compilers...)
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Daniel Mocsny  
View profile  
 More options Aug 31 1991, 11:18 am
Newsgroups: comp.arch
From: dmoc...@minerva.che.uc.edu (Daniel Mocsny)
Date: 31 Aug 91 14:20:30 GMT
Local: Sat, Aug 31 1991 10:20 am
Subject: Re: Small, fast software (Re: Writing fast compilers...)
In article <+9LD...@xds13.ferranti.com> pe...@ficc.ferranti.com (peter da silva) writes:

>The problem has nothing to do with lazy programmers, and it has little to do
>with the advance in technology. It has to do with politics and marketing.

The "politics" you speak of must result from the enormous artificial
problems vendors create for users by "horizontally" fragmenting a
market. E.g., when 10 vendors create similar products, they have a
very large number of inconsequential design decisions to make, often
of no greater real impact than deciding which side of the road traffic
should use. Apolitical vendors will make these decisions at random,
creating frivolous incompatibilities between competing products in a
given category.

These frivolous incompatibilities destroy incalculable amounts of
user wealth, because they make computers harder to use. Users are as
greedy as vendors, so they understandably have a strong interest in
persuading vendors to behave consistently wherever performance is not
an issue. Since each vendor has an interest in coercing all other vendors
except itself to change, the approach to vendor consistency requires
a political process.

>System V R 4 and BSD UNIX have the edge on smaller systems because they are
>seen as being "better", somehow, because they derived from AT&T's code. There
>are plenty of systems that are smaller with as much or better functionality
>that can't get a toehold because they don't provide a bug-for-bug compatible
>interface.

A few MB of RAM is much cheaper today than the productivity loss during
the time for a worker to master a new system of any useful complexity.
The payoff from the new system must be much greater than merely
conserving $200 worth of RAM. (Lots of workers cost their companies
that much in a couple of days or less.)

>X-Windows has the edge on smaller window systems because it's "free" and
>because it's from MIT. There really isn't enough additional functionality
>in X over your classic Rob Pike window system to justify the size, but
>because of political decisions (based in part on opposition to Sun's NeWS
>system which, while unweildy, does have functionality to match) nobody can
>compete.

Users have real work to do. They usually don't care about which among N
largely equivalent windowing systems they use. But they do know that
using more than one incompatible windowing system is a useless
complication that keeps them away from what they bought their computer
to do: creating wealth.

>And the really rotten thing is that this is all used as a marketing tool by
>IBM and Microsoft to push their own proprietary systems on the consumer. "See",
>they say, "OS/2 runs happily in 2 MB" (TWO MEGABYTES? Jesus... that's the MAX
>you can fit in a 3b1)... but you need 4MB (or 8, or 12, or whatever number
>they can support) for UNIX.

The average information worker routinely manipulates (or routinely
*could profit from manipulating*) chunks of information larger than
2 MB. (However, most of them still do this inefficiently, e.g., with
paper.) As far as most users are concerned, a computer which addresses
a maximum of 2 MB belongs in a museum or a toy store.

>The UNIX API is first class. The implementations are suffering badly from
>feeping creaturism. It's long since past the time they should have been
>done over from scratch. But they won't be, because of the politics.

Even the best programmers find that to add features, they must usually
add code. However, computer users try to use computers to solve real
problems. Real problems have an infinite number of features. Computer
users tend to reject software that is simpler than the problems they
are trying to solve.

Few mechanics can get by with just one hammer and one screwdriver.
Instead, they have to lug around huge cases of tools, which cost a lot
of money and take up a lot of space. That's because mechanics get paid
to fix things, not to glorify the aesthetics of minimalism.

--
Dan Mocsny                              
Internet: dmoc...@minerva.che.uc.edu


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.