Richard writes:
> One school of thought is that we should write new stuff
> in C, avoiding use of the heap and pointers to avoid hard
> to find bugs.

Well, you can only do this to a certain extent.  Any reference to a string /
character array in C essentially results in a naked pointer.  But sure,
"defensive C" would probably be a good choice.

> but how hard it is for Cobol programmers to learn to use C?

Of course it will depend on the COBOL programmer more than anything else.
If you go back to the long Unix-versus-MPE posting I wrote back on 11/10
(from the "how can I on Unix" thread) and change "MPE" to "COBOL" and "Unix"
to "C", I think it's still pretty relevant.

Someone who finds that they are unable to write reliable C programs may also
find that they are unable to write good Unix applications, since both
require more skill than a typical MPE program or application.  When driving
the little "Autopia" cars at Disneyland, you don't have to be a very
skillful driver since you are prevented from driving "outside the lines".
But Linux and C do very little to protect you from your own mistakes (they
both assume that you are a god of computers as the people who created them
apparently thought themselves to be).

It's quite easy to become a proficient C/Unix programmer, you just need to
learn a bit more before you get in the car and start driving than you did
when you started out with MPE, or you need to expect to wreck a few cars
before you get the hang of it :-)

> [...]but I'm afraid of Java for performance reasons.

CPU is cheap, and this is especially true for applications programs that
spend very little time in their own logic because most of the work is being
done by a DBMS, the file system, the network, etc.

> Another school of thought is that the programmers write in
> the language they know best, to get the best code with the
> highest productivity.

This is probably always going to be the fastest route to a robust and
predictable solution.

> How well do different languages cooperate on Unix or Linus?
> (i.e. Can Cobol make libraries C can call, and the reverse?)

The biggest problem with COBOL is that it is probably the least available
language on Unix and Linux, since the kind of people who like to hack Unix
code are the least likely to also like writing COBOL programs, so the COBOL
compilers that exist tend to be expensive commercial products.

The Unix COBOL compilers often have proprietary runtime libraries and some
are not native compilers at all, but are either pure interpreters or produce
an intermediate PCODE type thing which is run by a virtual machine.  I
suspect all of them have at least the ability to call out to C (and
therefore most other languages), and you can probably call into most of them
as well, but things start to look more like Java than C.

Most everything else on Unix tries to be compatible with C/C++, so in the
worst case you might have to write a small amount of "glue" code in C to
make random language A be able to invoke code written in random language B.

G.

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