Re: Theodore Adorno, a prophet of data systems design

From: Edward G. Nilges (spinoza1111_at_yahoo.com)
Date: 01/07/04 

Date: 6 Jan 2004 15:49:48 -0800

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.

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

>
> that does not make sense as there are plenty of people who
> still consider VB (and other microsoft tools) as "good enough"
> to use, even if there are technically superior alternatives.

We don't consider it "good enough for government work". Instead we
consider it a challenge to our abilities.

Buddy of mine wrote an efficient chess program in Cobol to demonstrate
the capabilities of a new minicomputer in the 1970s. I wrote a
simulator for a digital switch in Cobol.

To do so, I had to think about the stars and not the telescope. I
define the problem as an interpreter which would pass through the
engineer's finite state spec.

Since Cobol provides multidimension arrays it was then duck soup to
create the tables as an Occurs clause and write the simple
algorithm...in Cobol.

The project solved a real user problem and this was the fact that the
user could not recreate calls using events, especially complex
conference calls, and could not bill for the call. Since the problem
started in the business office, it became a Cobol problem.

I seldom see under today's "nondisclosure" requirements simple, end to
end narratives, not of how slick one is at microeffiency, nor of the
defects of character of somebunny else who one hates with a homophobe
passion, but of how ONE SOLVED A PROBLEM.

Let's have some 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.

 
> 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. You should read Gerald Weinberg's story of "Levine
the Genius Tailor" in The Psychology of Computer Programming. Since
you may not have the book I shall retell it.

Guy goes to a tailor and orders a bespoke suit. On the due date he
puts it on at the tailor shop, it doesn't fit.

Levine the Genius Tailor says, "no problem, just hold your arm like
this and hold your leg like this."

Guy hobbles out onto the street. He meets a passerby.

Passerby says, "who's your tailor?"

Flattered that somebody seems to think he's made a good buy, guy says,
why, Levine.

Passerby says, "give me his business card! Why, Levine must be a
genius to fit a cripple like you!"

Real users make dreck work by heroically working around phenomena that
INCLUDE unpredictable behavior based on uninitalized variables (a
practice fostered by C), programs that produce the wrong answer fast
(a practice fostered by C egoism and the belief that efficiency is
everything), strange behavior near undocumented limits (a practice
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), and the eternal green screen (a practice fostered by
C's favorite OS).

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

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.

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

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

What we want from an electronic ignition is MUCH simpler than what we
want from an enterprise system. Basically, I want to turn the key and
have the car start.

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

>
> goose,
> oh, yeah

Relevant Pages

  • Re: Gartner on Assessing the Age of Software Languages and Tools
    ... with no mainframe COBOL at all, ... And general-purpose computers running general-purpose applications are a ... movement in general programming toward better ... But are these pockets of "old time languages" significant in a global ...
    (comp.lang.cobol)
  • Re: Could this save COBOL?
    ... I am personally of the opinion that any languages not supporting the OO ... paradigm will be gone within 10 years, and that includes COBOL, unless it is ... OO COBOL running in the Dot NET environment could have a real chance of ... If the lifeblood of COBOL is going to be 1960s code in a mainframe ...
    (comp.lang.cobol)
  • Re: Is there a mainframe skills shortage?
    ... That's because the author of the article is comparing it to standard SQL. ... and material around Lamdas and functional programming. ... obvious which languages were the ones to learn. ... stick to writing system software and leave applications to the COBOL ...
    (comp.lang.cobol)
  • Re: Cobol News - Microfocus and AcuCOBOL
    ... I think they are the languages of today. ... I disagree strongly about problems for the programmer. ... It is a hard concept for COBOL people to grasp.. ... functionality comes along, it inherits what is there already and extends it. ...
    (comp.lang.cobol)
  • Re: Is there a mainframe skills shortage?
    ... it is a new syntax for query expressions. ... It is simply new technology that ... will be implemented by a number of languages. ... stick to writing system software and leave applications to the COBOL people. ...
    (comp.lang.cobol)