[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: COBOL compiler



On Tue, 2003-08-26 at 10:24, Yves Goergen wrote:
> Von: "Ron Johnson" <ron.l.johnson@cox.net>
> > On Tue, 2003-08-26 at 08:50, Kirk Strauser wrote:
> > > At 2003-08-26T12:52:33Z, Ron Johnson <ron.l.johnson@cox.net> writes:
> > > 
> > > > Too bad you have such a negative view of COBOL.  In the hands of someone
> > > > with a brain, it's quite a powerful and modular language.
> > > 
> > > All Turing-complete languages are equally powerful.  That doesn't mean that
> > > any given one would fill me with a desire to start hacking around with it.
> > > 
> > > You know, I'd never seen Cobol before the screenshots on your link.  Those
> > > just confirmed everything I've heard about it. :)
> > 
> > For a "Hello, World" program, or an OS, or a graphics toolkit, even
> > Admiral Hooper would not say that COBOL is the proper tool.  OTOH, 
> > for large commercial apps, COBOL is far and away the best tool for
> > the job.
> 
> ehm, at my work, they have a real big host system. from what i've
> heard, it's programming language is cobol, running under a specific
> IBM OS. i don't know a lot of that stuff, but there'll be some
> good reasons why IBM did that.
> 
> but my father (he knows cobol very well...) had massive problems
> coming from cobol (DOS) to some more current windows programming.
> from cobol, he has never seen multi-tasking/multi-threading concepts
> nor (graphical) windows, a mouse or even such principal programming

If he's used a mainframe OS, he's used a multi-tasking OS, and
he knows it full well.  His green-screen is/was single-tasking,
but heck, so were the teletypes & VT-100s used by early minicomputer
programmers.

> language conepts as functions (!). one must imagine, how can cobol
> be an easy to understand and to maintain language if you're by design
> supposed to write spaghetti code like it was once in gwbasic?

When I programmed in COBOL-74 (unless your father retired in 1975,
he's used it), I used *many* procedure (a.k.a. sub-program) calls.

The COBOL-74 that I learned in University was hell, since the
books tried to teach GOTO-less methods for a language that *needed*
the GOTO to be rational.

When I got into the Real World, I relearned COBOL-74 from truly
excellent men who knew how to use COBOL-74's strengths to ensure
that source code written in COBOL-74 does not have to look like
an explosion at an Italian restaurant.

> IMHO any C/pascal-like language or partially still (visual) basic
> seems far more fiendly to me. and i was involved in the developemt
> of some bigger (partly commercial) applications now, and i must
> say that VB and VC++ are very good tools for such.

Some time after I left the COBOL job, I was employed writing C
in an app that screamed for COBOL.  I'd say that 1/5th of the
SLOCs, and most of the bugs, were of the form:

  strncpy(really_long_variable, another_long_variable, 
          sizeof(another_long_variable));

By commercial, I meant record-oriented "data processing" type
software, not programs sold in stores and catalogs or by sales
people.

> and, yes - i'm a student, too..... (you may think of me what you
> stated above, it may be right or not)

-- 
-----------------------------------------------------------------
Ron Johnson, Jr. ron.l.johnson@cox.net
Jefferson, LA USA

"As the night fall does not come at once, neither does 
oppression. It is in such twilight that we must all be aware of 
change in the air - however slight - lest we become unwitting 
victims of the darkness."
Justice William O. Douglas



Reply to: