Re: Java compatibility issues (WAS: MF having issues?)


"charles hottel" <jghottel@xxxxxxxxx> wrote in message
news:d14f7$4409e4b1$4f9c662$13111@xxxxxxxxxxxxxxxx
I do not think that the issue is what COBOL can and cannot do. As a
language it can do most of what C, C++, and Java can do. It does have some
weakness in doing bit manipulations compared to those languages. Maybe the
2002 COBOL standard addresses that, but having a standard is a far
different thing from having a working compiler. However in the OO area
there are differences between the various compilers and I think OO came
late to COBOL. But I still do not think this is the main shortcoming of
COBOL. All of the other languages have extensive standard libraries and
COBOL does not.

Some flavours do have libraries. Fujitsu provides some very good OO
libraries for COBOL. Of course, if you use them, your COBOL is not
transportable... :-(

But I don't disagree with your statement,, as a general rule.

Even C which is not OO has a standard library. I think the OO paradigm
encourages and promotes the building of these libraries. There is no
inherent reason why COBOL could not have standard libraries that perform
the same functions that other languages have, but for the most part it
does not. On the IBM mainframe we have Language Environment but it does
not provide things like TCP/IP or XML processing.

Well I am sure someone will chime in and say just call the other
language's library functions from COBOL. Yes, but on the mainframe Java is
done under Unix Systems Services so you have to know something about that
as well as know about Java.

I should think that by now people in mainframe environments are getting to
grips with Java...?


In the floating point area mainframe COBOL uses hexadecimal floating point
and Java uses IEEE floating-point.

Well, you got me there :-) I used floating point (COMP-1 and COMP-2) for
many years on the mainframe and always considered it to be binary; not sure
what you mean by Hex floating point. (Hex is simply a shorthand
representation of binary...). On the PC I've used long and double types with
Java and VB and never worried about what the underlying format is, other
than "it's floating point...". I'm not sure what the significance of your
statement above is, Charles.


With all the other differences and incompatibilities not yet mentioned,
overall it is a steep learning curve that most people are unwilling to
attempt. Mixed language applications are more complicated and harder to
maintain. It is better if the standard library is in a language that you
already understand and even better if it is OO so that you can override
methods when you need to do so, and as Pete Dashwood would say even better
if you can just cobble together components.


If you are going to use standard libraries the last thing you would do is
maintain them. (If you do, they aren't standard anymore...) It comes back to
my point about code not being maintained. So, the language the standard
library is in, doesn't really matter. I have used MFC from COBOL on the PC
and didn't care that the functions are written in C or whatever... (I DID
care that using this tied my application to the Wintel platform, and that is
the main reason I don't do it anymore, but that is a separate issue...)
Actually, whatever I do (in COBOL) ties my code to the Wintel platform,
because that is what my development environment is targetting, so it isn't
really a major issue :-) The only exception to this is if I develop an
ActiveX or COM component which CAN be run on other platforms by a broker
such as CORBA. This is one reason why I am so passionate about component
solutions. You can run them anywhere; on the desktop or on a web page,
locally or remotely.

It seems the COBOL standards people would rather add XML verbs to COBOL
syntax than add a standard XML library to COBOL. With no standard library
for the language as a whole we then get nonstandard, fragmented and vendor
specific solutions/offerings.

I agree 100%. I said as much here some time ago. It is as if people believe
that adding "XML processing" verbs to COBOL will make it more attractive or
desirable. It doesn't. I believe it has exactly the opposite effect, for
precisely the reasons you described. We don't do it for SQL (and nobody
thinks any the less of COBOL for that); why embed other functions into the
langauge when they are best served by remaining outside it. (And this
doesn't even begin to address the physical work for vendors in doing this,
and whether or not it is so important that they can expect to sell more
copies of the compiler if they undertake it.)


The Java community has a process for developing these libraries (JSR)and
they are working together in that regard. The COBOL community is not
working together.


I thought about this for quite a while. :-) I have come to the conclusion
that there is a different cultural "attitude"between these two communities.
As my stock here is already pretty low, I won't elucidate :-) All I will say
is that reading the Java forums and reading this one is an "interesting"
exercise, not from the point of view of language content, but from the point
of view of attitude, particularly with regard to "new" ideas... :-)


The power of the Java libraries is evident. Don Higgins has developed a
shareware mainframe assembler project named Z390. He has done similar
things before using Cobol and Assembler, but this time he is using Java
and he told me how impressed he is with its power. He has programmed the
same functionality in far fewer lines than before and I believe it is due
to the power of the Java libraries. Parsing is hard if everyone always
reinvents the wheel but if you have a library which does regular
expressions so everyone can do it then it is easier.

Speaking of regular expressions, I spent a delightful couple of days last
week learning to decipher them and looking at open source from SourceForge
for their Okapi offering. I downloaded Rainbow and had hours of fun trying
different regular expressions with it... During the course of this, I came
to understand why people who don't know COBOL say it is lacking in string
handling. They are used to creating a regular expression object and letting
it do everything they want and then some.

I was stunned by how powerful these expressions are, once you get past the
mysterious and arcane cloak they are shrouded with. I needed something that
would search free format text and find case insensitive matches on phrases
and words, returning the context in which they occurred (from the start of
the sentence they occured in, to the end of the sentence they occurred in.)
Yes, you could write it in COBOL with several complex INSPECTS with POINTER,
and you would need reference modification to pick up the context once you
had identified it; say, 20 lines of (fairly complex) code? Using a regular
expression it is one line of code. (2 if you count instantiating the RegExp
object.) Granted, to the uninitiated it is an incomprehensible line of
code, but once the scales fall from your eyes it is simply elegant. These
expressions are currently being standardised by W3C for all languages and
character sets and Okapi is already using them to do language translation.

VB provides a standard library for Regular expressions and so does Java.
Even JavaScript and VBScript get to play in the same playground.

The kind of thing you can do is: " Tell me if there is a match for the
phrase "Show me the money!" (as written, with initial capital), but only if
the name "Jerry Maquire" precedes it in the text, and only if there is no
four letter word that starts with "F" following it anywhere in the text."
One line of code; a regular expression.

I think we should have a regular expression interface for COBOL. The power
of this for string searching and matching is phenomenal.

As you mentioned, Charles, when it comes to parsing free format input, this
is superb.


The same is true of Collections. How many times on this list has someone
said that linked lists are hard or that they do not belong in a COBOL
program, yet Java programmers use ArrayList and HashMap and other similar
functions all of the time.


Exactly. However they don't fit "What we do now..." :-)

Pete.


"Alistair" <alistair@xxxxxxxxxxxxxxxxxxxxx> wrote in message
news:1141483031.975503.245880@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Sergey Kashyrin wrote:
Howard,

As opposed to which language that does every task efficiently?

It's not only about languages of course.

Well-known phrase (I don't know the exact one - translating back to
English
from Russian :-)):
Programming of inefficient algorithms in assembler will not give you any
sufficient advantage.


Programming of inefficient algorithms in Assembler gives a significant
speed and size advantage over programming the same algorithm in Cobol,
or any of the other 3/4 GL languages. There are algorithms that could
not be programmed in Cobol (we had Assembler routines accessing VSAM
files in a manner which Cobol could not do).

So, of course it's only "some tasks" which Cobol was not designed for.

Unlike Java? A language that has had functionality bolted on in so many
places that no one man can be deemed to be an expert in the entire
language?


For example I'ld like to see the Cobol source of dynamic hashtable or a
relatively simple syntax parsing.
I know it is doable, but my feeling is that this code will be hard to
read.

No. Easy to do and read. I have written a parser in Cobol and a
colleague wrote a hash table in Natural (similar to Cobol and which
could easily be translated into Cobol vitually verbatim). The code is
easy to understand.


IMHO you can do everything (including Financial programming) efficiently
in
C++ ,

Except for ease of maintenance. A previously used quote:
<QUOTE>
It has been said of languages like C, C++, and Java that the only way
to modify legacy code is to rewrite it - write once and write once
again; or write once and throw away. On the other hand, it has been
said of COBOL that there actually is one original COBOL program, and it
only has been copied and modified millions of times.
- Wikipedia entry for Cobol.
</QUOTE>

but you have to desing the system

A good design makes for a good start. (aye, and why am I beginning to
sound like DD?)

It's
all about quality of checking for possible bugs in a early stage.
Cobol never had that and none has been introduced so far for that in any
Cobol-2010 ...

Checking for possible bugs is something that can precede the design
stage (start with the project initiation document). Cobol has always
allowed that. I presume you are referring to data typing, something at
which Cobol does have some (but minimal) capability (try adding ABC to
123).

It would be a morceaux de gateaux to write C++ poorly. Cobol can also
be written and designed poorly. However, beautifully crafted functional
Cobol code is a joy to behold.





.

Relevant Pages

  • Re: Cobol2Java: a Cobol to Java source code converter is available for evaluation
    ... If you were suggesting to use a C/C++ to Java tool that I may agree ... better because of being translated to a different language. ... Cobol is far from OO. ... many printers and page format as need at any time. ...
    (comp.lang.cobol)
  • Re: I wish to learn Ruby ,can anyone teach me???
    ... First, let's get the FUD out of the way: Ruby comes with a lot of libraries, ... Here's the biggest problem I have with Java: Right there, ... Now let's try that in Ruby: ... and I would call it the perfect beginner's language. ...
    (comp.lang.ruby)
  • Re: Java equivalent of C++ Spirit or Boost Graph Library ?
    ... Chris warns me about the difficulty of learning Java. ... The posters are generally far more familiar with the language, and more accomplished in their fields. ... management techniques in C versus using a standard garbage collector. ... regular-expression libraries or scanners (such as ...
    (comp.lang.java.programmer)
  • Re: Reddit Guys on the Pros and Cons of Lisp
    ... >> I never have to do that with Java. ... > language features, etc. ... They either have the feature or they don't. ... > libraries doing almost the same - for those languages. ...
    (comp.lang.lisp)
  • Re: Java is becoming the new Cobol
    ... """If you're a Java developer, now's the time to invest in new ... It is even truer for COBOL developers. ... The question then is: Is Java just another fad language in the range: ... Sometimes it appears they'll use whatever the Fad Language Of The Month Club sent last ...
    (comp.lang.cobol)