Re: CoBOL moved to OO

From: Richard (riplin_at_Azonic.co.nz)
Date: 12/30/03 

Date: 30 Dec 2003 11:39:48 -0800

"Judson McClendon" <judmc@sunvaley0.com> wrote

> Perhaps 'Ferrari' was a bad example. Substitute 'automobile' instead,

Well I am sure that you can switch to something else yet again to try
to maintain your argument.

> it is a better analogy anyway. But you don't have to know ALL the
> controls to start and drive either one. :-)

Don't you ? Which ones don't you need to know and how do you tell
whether it is needed or not ? You are merely using your familiarity
to assume that what you know is 'easy' and what you don't know is
'hard'.
 
> Stanley Steamer: You don't have to obtain water and fuel, fire up the
> thing and wait for steam every time you start a modern vehicle.

I didn't know that a Ferrari didn't need fuel.

But you did not need those with the more recent Standley Steamers
which were fitted with flash boilers. Compared to contemporary
automobiles they were easier to drive and started within 30 seconds
using fuel from the fuel tank. They weren't wood fired you know.

> You
> must know that these things are required, and how to do them, in order
> to start a Stanley Steamer.

I actually have some technical documentation from the 50s about
Stanley and other steam cars. My father was interested in building
one at the time.
 
> In a modern automobile, you only need to know how to start the
> engine (insert and turn key), put it in gear (move gearshift lever)
> and what the accelerator, brakes and steering wheel do.

Do you ? How do you _know_ that ? --> experience.

Why do you think a Stanley or Model T is hard ? --> inexperience.

> You have
> to know all this except the starter to start and run a model T, plus
> you have to know how to (literally) crank the engine, set the spark
> and do a manual shift.

No. Wrong. Model Ts did not have 'manual', they had a planetary
gearbox with a change pedal and automatic clutch. No harder to use
than knowing to put the autoshift to 'D' rather than 'R', or not
knowing that it was not one of the controls that could be ignored and
leaving it in 'P'.

Model Ts were designed to be used by people who had never driven
before and could be taught by the dealer to drive away after 5
minutes.

> If you don't understand how to set the spark,
> you will likely get a broken arm when the engine backfires while
> you are cranking it. A common injury in those days. Many people
> now don't even know how to drive a manual shift transmission. :-)

And if you don't know not to put the gear in 'P' when moving ...

Starting a Model-T is just a sequence of operations: move this lever
here, operate this toggle (fuel pump) 3 times, turn on key, turn crank
once slowly, then pull hard.

For your car you don't need a written sequence of what to do, you
probably don't even notice you are doing it: gear to Neutral, key in,
seat belt on, press accelerator down (to set auto-choke), turn key to
start.

It is just a sequence, you just learn it.

I don't drive automatics. When I have had to use them in the past I
founded them 'hard' to use (due entirely to unfamiliarity).

However I have, in my youth, had a car with a Wilso pre-selector
planetary gearbox and automatic cluth that did, from time to time,
need crank starting and had advance/retard and hand thottle.

I would find a Modsel T easy to drive.

> Mastering C++ or VB or Java is orders of magnitude more difficult
> than mastering COBOL, even as a first language.

Again you are basing this on your experience. Cobol is 'easy' because
you done it for xx years. You may well find C++ hard, until you've
done it for a while.

Over the last week I've had to write a complete cgi application in
Perl/MySQL because the hosting site does not run my preferred
Python/PostgreSQL. I've avoided Perl in the past, but it is just
another language. Languages one is familiar with are easy, ones
unknown are hard.

It may well be that moving from Cobol to C++ (or Java) is really hard
because it includes unlearning all the Cobolish things that clutter
one up. But starting without pre-conceived ideas about how a language
_should_ work would make most of them equally hard/easy.

> Not to write a
> "Hello World" program, but mastering them. Using them, once they
> are mastered, is not necessarily more difficult, but requires more
> ongoing research to answer questions like "what component does
> this function?" A brief glance at the MFC manuals should assure
> anyone of that (if anyone has the complete MFC, Win32 API and
> all the characteristics of all the objects they are likely to have to
> deal with down pat, I admire their stunning accomplishment :).

All those APIs are _not_ part of the language and are used equally
whatever language is used. I have written extensive Windows API
programs in Cobol, and not just dialog boxes but graphical
representations of container ships and stability and strength curves,
even with 'the view from the helm' in perspective over the actual
container loading taking into account the trim of the ship (actually
the view could be from anywhere and there was a 'cookie' that changed
viewpoint from 1000 metres aft and off to one side to do a 'flyby').

Yes, Java is huge too, but if you wanted to do all those things in
Cobol it would be just the same. How do you do EMails ? run ftp ?
create spreadsheets ? access distributed databases ?

Or are you saying that Cobol is easy because it only does batch
updates and the odd report to a line printer ?

> And,
> at least in the volatile Windows environment, your target API gets
> rewritten every few years by Microsoft. This and other rapidly
> changing tool definitions require significantly more time and effort
> to maintain your skill level. More time learning means less time
> producing. Surely, few would debate this. :-)

But Windows API is not C++ nor Cobol, nor Java, nor Python. It is
something that any of those can use. Or it is something that need not
be used.
 
> It's not a question of the tools being "too difficult," it is a question
> of the cost of this extra overhead compared to the benefits gained.
> The business world should always make decisions based on ROI.

Of course. I would agree that for business applications (ie
accounting) the Windows API is not required. It is better to have a
decent text mode environment. IMHO CICS is not. I also think that it
would be much harder to master CICS (which I never used but I do know
how it works) than, say, VB.