Bruce neatly sums up my feelings on languages. It's about maintenance.

Cobol has 4 divisions, 45 Statements and 42 functions (all approximate,
depending on version etc).

Even if the programmer uses cryptic file, data and working-storage names, a
simple global change of say "sn" to "ws-surname" with an intelligent editor
makes the code readable - annoying sometimes, but readable.

To a reasonably seasoned Cobol programmer, there are very few mysteries in
some else's Cobol code. He (she) might curse the construction, but will
quickly get to grips with the logic, especially with a good Cobol aware
editor.

And yet, despite it's apparent simplicity, Cobol solves most business
problems.

PowerHouse Quiz (reporting) has 32 statements, 62 functions (most common to
all P/House Modules) (all approximate)
PowerHouse QTP (batch processing) has 34 statements, many shared with Quiz.
PowerHouse QDesign (screen handling) has 38 Statements, the concept of
Procedures (28) and Verbs (50).

PowerHouse solves most business problems, and is pretty easy to understand,
once again probably because choices are limited.

We use Cobol and Powerhouse. We also use Perl, Java, C, Visual Basic, VB and
Java Script in .asp, etc in our total solution.

We also have logic embedded in MPE script and Job streams, and POSIX scripts
(more of the latter, lately).

Fortunately, all our business logic is in our code, and not in database
specific triggers, rules and stored procedures, which I've always viewed
with deep suspicion, and Image/SQL has thankfully forbidden :)

Regards

Neil


-----Original Message-----
From: Bruce Toback [mailto:[log in to unmask]]
Sent: 20 November 2001 06:14
To: [log in to unmask]
Subject: Re: picking a language


Ted Ashton writes:

>Thus it was written in the epistle of James Ots,
>...
>>
>>       I also keep hearing about it being readable, but I've never
>> seen a single readable piece of Perl code yet.
>
>Isn't this just a little like saying, "I've never learned to read
>Russian and I've never seen a single readable piece of Russian yet"?

Oh, goodie... a softball. Language wars are much less stressful than the
present hot topic.

No, it's not the same thing. Programmers ought to be able to read programs
even without much training in a specific language. Languages that meet that
test -- ALGOL, FORTRAN, COBOL, BASIC -- tend to have long lives. Languages
that violate that principle -- LISP, APL, SNOBOL, Smalltalk -- tend to be
used only by tiny communities or fall by the wayside. I've written programs
in all of the latter languages, and they're far more powerful than
general-purpose languages like C or COBOL for certain tasks. They're also
capable of handling ordinary business data processing. But their quirky
syntax leaves uninitiated programmers in the dust.

I've now run across two companies who've had to throw away large investments
in Perl code because it was utterly unmaintainable by anyone except the
suddenly-departed original author. There are serious disadvantages from a
longevity point of view to any language with a syntax that can't be
understood without special training. I want to be able to have someone pick
up any program that's important to my business and have some idea of what it
does, whether or not they've had special training. Perl doesn't meet that
test. I wish that LISP did, and especially Objective C. But I'll forego
their power in order to make sure that someone can pick up the program in 15
years and figure out more or less what it's doing.

-- Bruce


--------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
btoback AT optc.com                |     -- Edna St. Vincent Millay
Mail sent to [log in to unmask] will be inspected for a
fee of US$250. Mailing to said address constitutes agreement to pay,
including collection costs.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *