Re: Theodore Adorno, a prophet of data systems design

From: goose (ruse_at_webmail.co.za)
Date: 01/07/04 

Date: 7 Jan 2004 01:28:28 -0800

spinoza1111@yahoo.com (Edward G. Nilges) wrote in message news:<f5dda427.0401061549.26111711@posting.google.com>...
> ruse@webmail.co.za (goose) wrote in message news:<ff82ae1b.0401060139.1e940335@posting.google.com>...
> > spinoza1111@yahoo.com (Edward G. Nilges) wrote in message news:<f5dda427.0401032250.67d66eca@posting.google.com>...
>
> Hey, goose man. Good to see you.
>

Hello there.

> >
> > <snipped>
> >
> > >
> > > Of course, Adorno was describing the personality of people whose main
> > > job is to keep a job and this overdescribes data systems people,
> > > especially those who cling to outdated languages.
> >
> > <oooohhh, the *irony*>
> >
> > by implication, then, we should all leave outdated windows
> > and move to linux, with its plethora of new languages which
> > are installed by default?
>
> Yes, it has a LOT of cool languages. I think it has Ruby, for example.
>
> Which is why I work in Windows because the language development is
> more needed.

I concede that much work needs to be done in language development
in windows. However, all the languages that most Linux distros come
with by default are available for windows as well, but microsoft
windows /doesn't/ come with a decent language.

The situation that I wuold like is getting a gnu cd with my
windows purchase (snoball + hell -> chance that that will happen).

<snipped war stories>

> >
> > just because VB is outdated, that does not mean we should
> > abandon it, right?
> >
> The controlling issue is that Microsoft is abandoning VB as we know
> it.
>

that is the danger with /any/ proprietry software. The controlling
party of the software (which is almost never the purchaser) can
do whatever they want to in order to extort more money from
the victim^H^H^H^H^H^Hpurchaser.

>
> > look at it this way; everything you do depends on C, we should
> > not just all /move/ to C *because* we all depend on it, and
> > because the everyday stuff we use (written in C) hardly ever
> > fails while those outdated languages (like VB) fails all the
> > time.
> >
> Hmm, maybe the memory leaks etc. become features that the user
> actually relies on.

nope. It /may/ become something that the user accepts as a result
of *having* the software (another windows example: users are no
so used to having to switch off the PC every evening, and installing
virus docters, and rebooting when an application runs wild that
they *do* *not* *even* *know* that they can have a PC with 422
days continous uptime. its almost pavlovian, in that the user
reaches for the reboot button whenever the screen turns blue).

but this is hardly relevant. C may not be a forgiving language,
BUT (and this is important) only programmers who are not paying
attention get burned with the memory leaks, and buffer overruns,
etc. With any language, there is a (sorta) pact between the
programmer and the language -> "If programmer adheres to these
rules, the language guarantees no memory leaks, buffer overruns,
etc".

It is not just C and C programmers who have this pact. lets say
you use a third party library written in VB.NET (or whatever),
and you call a function foo() in that library. the library can
guarantee that "foo returns valid results if the input to foo()
is valid". should you call foo with invalid input, then foo
is not obliged to return valid results. In fact, from the above
(hypothetical) /guarantee/, foo() may not even return.

the fault there would not lie with the language, now would it?

<snipped bad-suit story>

> Real users make dreck work by heroically working around phenomena that
> INCLUDE unpredictable behavior based on uninitalized variables (a
> practice fostered by C),
  
but forbidden by C (by the standard anyway; what in case its a
trap value?) and only appears in the code of bad programmers.

> programs that produce the wrong answer fast
> (a practice fostered by C egoism and the belief that efficiency is
> everything),
   
strangely, the C /idiom/ seems to be portability, and *not*
efficiency. sure, there are C programmers who believe in efficiency
over everything else, just like there are java programmers who believe
the same, and VB programmers who believe the same, and python
programmers who believe the same.

surely thats not the fault of the language.

> strange behavior near undocumented limits (a practice

there are no undocumented limits, as far as I know. feel free
to prove me wrong by posting the list of undocumented limits.

> fostered by the arrogant way in which C programmers use constant array
> limits), strange string behavior (a practice fostered by the absurd
> Nul limit of C),

how is that a limit. the size of a C string is constrained only
by the memory you have available. any other method of storing strings
in memory imposes arbitrary limits.

> and the eternal green screen (a practice fostered by
> C's favorite OS).

what is a "green screen"?

>
> > <snipped>
> >
> > > That's because so many posters in this newsgroup wait in fear and
> > > shame for their defects to be discovered. I don't, even though I have
> > > defects.
> >
> > luckily for us, most of the worlds software *is* written in C
> > (with a mixture of assembler) and doesn't fail as often as
> > desktop/server software.
> >
> Not sure how you can know this.

well, I just did a rough count of everything available to me
right now, and found only the desktop havnig software in something
other than C (and the desktop also runs C-written software as well).

your microwave wont run java, your dstv decoded is not running
VB, your dvd player does not run on C#.

but they *do* all use C to some extent or another.

>
> My number (80% failure rate) is of equal breadth so you might well
> challenge me, goose man, if I challenge your information on this.
>
> But Dan Appleman, in a book on VB.Net, names the worst bug in the
> world in an excellent discussion of the dangers of threads.
>
> It's the bug we don't know about.
>
> Inductively and for the very good reason that the embedded and low
> level OS code that C is used for his hidden, we don't know its bug
> status. It's possible that direct users work around.

but all my appliances *work*. they dont crash, they dont require
rebooting; they just work.

it *is* possible they have bugs that no has ever found, just as its
possible that desktop/server systems have bugs that no one has
ever found (in addition to the ones we *do* find).

let me put it this way. your life would be much more difficult
if all the "C software" in your house broke down 1% of the time:
1% of a day is roughly 14.4 minutes. do you want to miss 14.4 minutes
of your favourite show on tv? do you want to have your microwave down
for 14.4 minutes when you are hungry? has any appliance made you wait
14.4 minutes?

now you get to work, and the mailserver goes away for 2 hours. some
of us wont even notice! the fileserver has to go down for 1 hour
routine maintenance? well, we just copy the files over to the local
hard disk. your browser crashes while surfing? just restart it.

those office things happen all the time, and they are the software
most likely to be written in a language other than C. those home
applicances sometimes "break" after many years service, not failing
even once in as many as 17 years[1].

>
> Whereas in the case of enterprise, desktop and server software in
> governments and public companies, the review process can document a
> failure.
>

true. but failures in embedded are not tolerated by the market.
failures in desktop/server are *expected*.

>
> > (your VB-programmed or .NET programmed applications tend to fail
> > much more often than my C-programmed ignition-system).
>
> Well, my auto mechanic can beat up your auto mechanic.
>

<grin>
oh yeah!!! we-ell the wifey-types dad is an auto mechanic, and I bet
that this governator look-a-like can beat up your auto mechanic
*and* his apprentice :-)

> What we want from an electronic ignition is MUCH simpler than what we
> want from an enterprise system.

not really, more on this below.

> Basically, I want to turn the key and
> have the car start.

and an enterprise user says "basically, I want to click this button
and have *all* the results that are relevant".

big deal, same difference.

<warning, pedant follows>
the ignition system has to do a lot more than help the car start. it
has to read various sensors to get crank-speed, camshaft-speed, current
crank position, current camshaft-position and (in cases of fuel
injection) sense throttle load, engine revs. it also has to *control*
various bits-n-pieces in the car.
</pedant>

>
> [I should mention in this regard that the cars I actually drive are
> the sort of car whose ignition consists of rolling it down the street
> and jumping in. This is mostly by choice since SUV owners make me
> sick.]
>
> There are considerably more interfaces in a VB enterprise system and
> therefore more points at which failure can occur.

In a car ignition system (which I am currently having a bash at),
there are many more /types/ of unknowns that one has to cater for.

It is especially difficult to design a _fail_safe_ system; enterprise
systems (which I have a background in as well) are tons more easier
to design than the average auto-ignition system is. enterprise systems
are staggeringly flexible, and can (usually will) be built out of a
number of different languages and smaller systems.

the embedded stuff that I do has no flexibility. there are time
constraints and memory constraints that one has to adhere to, in
addition to the usual _fail_safe_ mandate (we cant have someone
killed because the cardiac machine programmer decided that $18 was
too much to pay for a copy of the C standard, and used a non-standard
function hastily copied and pasted from a car ignition system).

In enterprise development, you can have the luxury of java and C++
and python and ruby and lisp and C and sbn and haskell and prolog
and bash-shell scripting and perl and php and web-interfaces (did
I leave anything out?) and windows and linux and *bsd and sco and
solaris. you can get away with making something /not/ failsafe.

in very few embedded devices will the consumer tolerate frequent
failures.

notes:
[1] the 17 year service is from the ignition system of a 1986
    e28 bmw 525e (called the 528e in USA, i think). this car
    has got the original engine and cylinder head from '86,
    as well as the original 'box. nothing has broken down in
    17 years except for a bolt pinning the steering box down
    (re-welded by non bmw welder:-), the front grill and bumper
    (which were tragically killed in a parking lot bender) and
    a side rearview mirror (also a victim of stupid parking lot
    drivers)

    and it *still* gives me < 12l/100km (traffic with aircon)
    and <10l/100km (open road), consuming absolutely *no*
    oil between services and a /very/ comfortable ride.

    Also have got the full service history (from bmw) for this
    car handy, if I ever get senile enough to want to sell it:-)

goose,
   verbose today, again !