Re: Theodore Adorno, a prophet of data systems design

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

Date: 8 Jan 2004 01:35:12 -0800

spinoza1111@yahoo.com (Edward G. Nilges) wrote in message news:<f5dda427.0401071457.3893048d@posting.google.com>...
> ruse@webmail.co.za (goose) wrote in message news:<ff82ae1b.0401070128.641dedcf@posting.google.com>...
> > 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>...

<snipped>

> > > 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.
>
> What we need to examine here is a language which identifies an
> unfairness in a market in isolation as if it could be identified.

looking at the three levels of indentation above, this seems
suspiciously like a non-sequitar(sp?). I would appreciate it
if you could re-respond to the bit "that is the danger..", as
the response above does not make any sense to me.

>
> What I have always admired about Microsoft, ever since I received
> crudely typed newsletters from Bill Gates in Albuquerque, has been the
> fact that they pay people. In the early days, they paid people and
> they've met their payroll ever since the early days.

yes, but even the nappy factory I worked at while a kid paid.
that is *expected*.

<snipped OT economic/politic/piracy issues>

>
>
> >
> > >
> > > > 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".
> >
> The problem is that the default case is that any REAL program is
> written by multiple authors in one of two ways. Either a team works on
> the program, or else a series of schnooks work on the program.

there are a few more ways than that. for example, it may be written
by a small, compact team of brilliant programmers, or it may be
written in series by a lot of brilliant programmers, with a few
mediocre programmers, or .... the list goes on ...

>
> There is no one set of rules for good C practice that guarantees no
> memory leaks, overruns etc.,
   
there is. follow the rules.

> and I can even prove this without knowing
> as much about C as Richard Heathfield.

if you *dont* follow the rules of language X, then you are apt
to get burned. if you are told "bad things will happen if you do Y",
and you go ahead and do Y anyway, why be surprised when bad things
happen?

>
> It goes as follows: if there was one set of rules for good C practice,

there is.

> "good C practice", in order to ensure safe TEAM development (whether
> as above parallel in the case of a development team, or serial in the
> case of a series of schnooks) would encapsulate these rules IN A NEW
> LANGUAGE...and this is precisely what Stroustrup did when he used the
> preprocessor to develop C++.

that also does not follow. the existence of a problem does not
imply the existence of a solution. you are saying that the existence
of problems in C implies a SAFE NEW language which is C, but without
the problems?

>
> Lemme put this another way. If a language is so filled with problems
> that the programmer has to know, in excess of computer SCIENCE, so

[1]

> much trivia, arcana, bop Kabalah, Lost Secrets of the Old Ones,
> Magick, palmistry, mesmerism and cold fusion, THEN the language is the
> problem.

that also does not follow. there are a few general rules to follow
in C to prevent yourself getting burned. there /are/ safer languages,
with fewer rules, and they are well-suited for their *intended* use.

I suspect that their are fewer /rules that can burn you/ in java than
in C, but the java rules are not as simple, see? (google for "java
memory leak" to see what I mean).

In C, "free all memory allocations" is a simple rule,
easy to understand and simple to follow. to prevent the same
class of problem in java, you need to first know a helluva
lot of things about *why* memory leaks occur in a language with
a GC.

VB is not free of its problems either. nor is lisp, nor C++, nor
python, nor php, etc ad nauseum.

C has no more and no fewer "flaws" than any general computer
language.

>
> Thus I prove from outside C "expertise" (which I fear resembles bop
> Kabalah) that it is time to freeze new development in C.

that isn't proof. all you did was say "there are flaws in C"[2].

<snipped OT phil.101>

>
> > 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?
> >
> The lesson of high reliability languages from Pascal through Ada and
> Eiffel is that it does.

nope. it is perfectly possible to write applications that "crash"
in /any/ language. look at the following pseudocode, with a bug in
it.

while (not_at_end_of_list) do
begin
   process_item_at_this_point_in_list;
   go_to_begin_of_list;
end

no language can protect you from that bug.
every language will let you /fix/ the code so that the bug
goes away (replace go_to_begin_of_list with go_to_next_item_in_list).

>
> > <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.
>
> But, it appears and is not prevented as it is in VB.

it appears because the programmers broke the rules. if you
break the rules in VB, do you blame the language when things
go awry?

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

I assume you agree with this, as you have not responded to this.

> > > 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.
> >
> Not in C. However, the way in which C allocates arrays and fails to
> provide hash tables as part of the language encourages secret decision
> making which should be the user's as when the programmer allocates the
> array as 1024 because 1024 seems like a big number.

what would you prefer? it is trivially easy to write wrappers
so that no magic numbers are in the code.

>
> One of my issues with using C on a VMS system to develop a "C-like"
> compiler for business rules was I did not want to in any way bound the
> complexity of the rules. But all I had in C was the linked list
> perhaps with a hash index. I found the repeated coding of linked lists
> tedious and not suitable work for a gentleman.

so you can use a generic-ish list. have a loko at the standard
qsort() function in C. it can sort /any/ array. just because
the programmer hardcoded limits into their code when there are
alternatives (which are limit-less) does not make the language
a poor language.

what about pascal strings?

>
> > > 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.
> >
> It's a limit because a central computing insight is the refusal to
> treat any computing object as "special" because of the demands of
> one's system.

so you agree that it is not a limit on the length of the string,
but a limit on what the string can hold?

>
> For example, one reason why, when I started out, DEC Petey P 8s were
> more powerful than my 1401 was the representation of a line break by
> characters who were conceptually the same as any other characters.
>
> If your string paradigm makes any character at all The Chosen One, and
> any string that in good faith "wants" to contain Nul "special" you to
> this extent reify a technical demand and prioritize it over human
> needs.

or you do what thousands of programmers have already done; viz write
a string wrapper (once again, very trivial, took me less than an hour
to write and test) which includes escape characters.

this way, the string length is constrained *only* be the size
of available memory *and* the contents can be anything that the
machine is capable of holding.

>
> What am I smoking? Nothing. I stopped smoking.
>
> The ideal is in fact to be able to create a string, and be damned.
> There should be absolutely no limit on the potential size of the
> string. This may be theoretically impossible.

it is perfectly possible (and trivial) to write a string wrapper
module in C which is *only* limited by the size of memory.

>
> The second best is to make sure that the strings, that cannot be
> admitted to the community of strings, are truly special in so many
> ways that they are truly unusual by definition (strings containing NUL
> are common). And, representing string length as a long int
> accomplishes this goal.

but then you are limited by a programmer imposed length.

(look at your "1024 array length" example above. I got the
impression in that example that arbitrary limits were not
considered a good thing by you).

as an example from my utility library, I have written fslurp(),
which takes a text file and "slurps" the entire text file into
memory (if memory is available) as a single string.

I have used this function for many years, and have not yet come
across a text string which holds a Null Character (the chosen one)
as part of its value.

however, should I need to holds strings which may contain a null
character, I will wrap the string in my own string representation
(which C allows) which will escape special characters.

<snipped green-screen explanation>

> >
> > >
> > > > <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.
> >
> No, they run with software that might by accident be written in C

you do realise that whether its by accident or design, "they do all
use C ..." still holds. another thing to keep in mind is that embedded
systems are /never/ designed by accident. you only have to realise
that there is an error in your product (with 200000 sold) once, to
do careful design and implementation for the rest of your life.

once you realise that you sold 200000 products with a bug and *all*
have to be recalled, you (as an individual) will take the utmost
care to avoid that happening again.

desktop/server software, otoh, is fairly simple and hassle-free
to patch bugs on. mail the user a disk.

> or
> maybe some other language.

very few devices are written totally in assembler. I would like
you to point out an MCu or platform that *does* *not* have a C
compiler. even better, point out a household appliance that
has been written in something other than C (+assembler).

This *is* a challenge (I issue very many of them, dont I? :-).
find my a household device which is not written in C to
some extent. A household device that is completely ffree of C.

> > >
> > > 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.
>
> Until they don't for some strange reason.

you are right. sometimes they *dont* work. but I've never had
to /patch/ the software on them to make them work again. I can
honestly say that I've never heard of faulty software in home
appliances going awry; generally when something goes wrong, its
an electronic/electrical component, not software.

> And have you set the time on
> your VCR?
>

alas, I have no idea on how to set the time on my VCR (and the manual
seems to have been translated from hindi to english by someone who
knows neither language:), but others (kids) have set it for me, so
I /do/ know that it works.

> >
> > 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?
> >
> I spend most of my time at work and I would prefer to have some gal
> fix me home cooked meals in a brick oven. On weekends, I would prefer
> to channel George Foreman and whip up some ribs. I don't think the old
> guy's grill uses a CPU.

sure. good for you. but the millions of people on the planet who
/do/ depend on these devices still count. they could not care
that the software with which they spend 90% of their time is written
in C.

>
> These devices to which you refer are at best conveniences which
> channel a "disciplined mobilization of everyday life" which
> increasingly is seen not to be sustainable in the long term.

the automobile is not sustainable? how about the microwave, or the
tv, or the dvd/vcr/cd player?

or any of the millions of C-programmed chips around you?

>
> > 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.
>
> Interesting point, though. The stuff at home seems to work whereas the
> stuff at work crashes. My thesis is because social relations are
> dysfunctional as compared with individual lifestyle, at least for
> many.

or it could be that the stuff at home is written in C, while the
stuff at work isn't.

>
> >
> > 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].
> >
> Has nowt whatsoever to do with C at all.

yes it does. point me to software written in VB that has run
without maintenance for even half as long (I know you cannot:).

C has been used in many areas where long-term viability is important.
C will continue to offer long-term viability until someone can
come up with a language *as* portable (or more) as C is, and one
that can target 8-bit hardware *and* the latest supercomputers.

C is ubiquitous. If you have a module written in platform-independent
C, you can be sure it will run on every piece of hardware in existence.
currently, you can also be sure that it will run on hardware designed
twenty years into the future.

your modules in any other language are not as portable. it is simply
not feasible for an embedded firm to write modules that they want to
reuse in a language other than C.

>
> > >
> > > 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*.

I assume you agree with this, as you have not responded to it.

> >
> > >
> > > > (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.
> >
> No, because you at a minimum need to see irrevelant information if it
> is important.

this does not make sense. if it is "irrelevant" then it is not
important. when it *becomes* relevant, it becomes important.

> You don't want a system that filters exogenous
> information. It might be important, out of the blue, from outside the
> system in which you think you exist, such as a summons.

I /think/ you mean that some information that you might consider
irrelevant can, in the future or present, with the right set of
conditions, become very relevant.

I would definately agree with that, although it has no (clear)
relevance (at this stage) to the argument at hand.

tip: try designing the input module for an embedded system
that takes input from a keypad. its actually a lot more
in-depth than it looks. and it has a lot more points of failure
(for the software) than you would at first think.

<snipped no responses to my paragraphs>

> > 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.
> >
> We accomplish this by the sign off process which in many companies is
> broken, in the sense that the stakeholders who sign off are never
> powerful enough to even know that once the system goes into
> production, it will satisfy its real users.

that may be the reason for the so very many patches and upgrades
needed, but it does not answer my premise that enterprise systems
are no more difficult to design and write than embedded.

Why do you think that embedded people get paid more (in SA, at any
rate)? it /might/ be supply and demand, as there are fewer embedded
people than enterprise people.

the reason for the fewer embedded /could/ be that enterprise
is easier than embedded. I would be interested to know your thoughts
on the reason that embedded get paid slightly more, and the
reason that there are fewer embedded people than enterprise people.

<snipped>

[1] How is VB better suited for COMPUTER SCIENCE than C?
    afaik, C still has more language features that allow
    implementation of computer science principles than
    VB.

[2] You made an assertion. now is the correct time to back it
    up with "hard" proof, not conjecture.

goose,
   my, this is time consuming :-)

Loading