Re: COBOL and Java Relative Perceived Power

Charles Hottel wrote:
See comments interspersed below.

"James J. Gavan" <jgavandeletethis@xxxxxxx> wrote in message
news:x3d8m.11614$nL7.6305@xxxxxxxxxxxxxxx
docdwarf@xxxxxxxxx wrote:
In article <6e6dnUXtGYIweP3XnZ2dnUVZ_r2dnZ2d@xxxxxxxxxxxxx>,
Charles Hottel <chottel@xxxxxxxxxxxxx> wrote:

A Java programmer and a COBOL programmer meet in a bar. The Java
programmer says : "Java has more than 35,000 methods listed in 4100
classes in the current Javadoc library of API's. What does COBOL
have to offer that is equivalent to that, that would make me want
to use COBOL instead of Java?".

If you are the COBOL programmer what would your answer be?


My answer would be ''He who thinks all fruits ripen at the same
time as strawberries knows nothing of grapes' was said by
Paracelsus in the 16th century.'

DD


Doc you really should try drinking, it might make a normal man out of
you. One whose communication I might have a hope of understanding ;-)

In answer to the original question I don't know. What follows is
specifically Net Express V.3.1. We have since gone through V 4, 5 and
5.1 - so it wouldn't be unreasonable to make an assumption that over
time thee might be an increase of 10%. Rough count on following for
N/E 3.1 :- - 039 classes for Base
- 121 classes for GUIs
- 050 classes for OLE
- 007 classes for OLE Auto
- 004 classes for Java Domain
- 003 classes for Java Support
- 010 classes for Dialog System
---------
234

I've got to do a Gartner now, and extrapolate :-). Can't tell you
without a very exhaustive analysis exactly how many methods. One
class might have only 10 another perhaps 30. So (hit and miss),
going with an average of 20 per class :-

234 classes X 20 methods = 4,680.

Who said big was beautiful. (Bear in mind I have the source of those
4,680 methods, should I want to take a look see and get a handle on
M/F's approach).


The Java source code is also available.

This might seem like a really stupid question, but I have never
delved into Java. Does Java act as a replacement for Windows, i.e. a
replacement OS - in which case, sure it would require considerably
more classes and methods.

The Java virtual machine (JVM) that runs byte code is a separate
entity from the Java language/compiler. The classes and methods
referred to are a huge resource available to anyone coding in Java. I do
not know if the JVM or parts of it are written in Java. At the
lowest level when communication with the operating system is required
I believe the Java Native Interface (JNI) is used probably calling C
or C++ programs.
Now years ago, when a COBOL programmer using Java
jumped in with, "I don't believe much in inheritance classes", Pete
Dashwood replied he agreed. Certainly hierarchical classes were
central to Smalltalk, culminating in Smalltalk 80. Micro Focus paid
the compliment of copying Smalltalk concepts, possibly dropping some
classes and adding new ones applicable to COBOL. Hitachi did the
same thing I believe - but not much help unless you are proficient
in Japanese. I think at first stab, IBM may also have followed the
Smalltalk model, (that I gleaned from Arranga and Coyle with
diagrams comparing, at the time, Hitachi, IBM and Micro Focus. Along
later comes Fujitsu and I don't know what their model was.


Java supports inheritance. Each class can 'extend' a single class. This
is referred to as implementation inheritance. Also each class
can impement as many interfaces as necessary. This is referred to as
interface inheritance. Java does not support mutiple implementation
inheritance in the way that C++ does, but you can do a lot of the
same things with less of the problems of multiple inheritance. In
addition to the above every Java class implicitly inherits from the
Object class.
Inheritance can be useful but it can also be overused. Inheritance
breaks encapsulation. One of the general rules in the book
"Effective Java" is to favor composition over inheritance where
possible. It kind of boils down to the ideas of "is a" and "has a".

I don't think inheritance breaks encapsulation, necessarily. The base class
is still encapsulated. Extending it makes its methods "visible" but that
doesn't,of itself, violate encapsulation. Overriding a super class method in
a subordinate class doesn't violate encapsulation in either of the two
classes, because both the current override and the super class are still
intact and available for legitimate use.

I've never really thought about that.It seems to me more academic than
important. Even if you're right and encapsulation is technically broken by
inheritance, I don't think it is important enough to make me NOT inherit, if
inheriting was the obvious best path... I agree that inheritance can be
overused, but there are times when it is obviously the right way to go, too.



Now an interesting thing about Java from a Smalltalk programmer. He
had switched to Java 'cos that's where the money is, but given is
druthers would much preferred to have continued in Smalltak where he
claimed he could achieve the same in much more concise coding.


Everyone has their preferences. I am biased toward COBOL and enjoy
coding it much more than Java, but from what I have seen of OOCOBOL
it is much too wordy compared to Java. The idea of perceived power
of course is a whole different thing.


I think that's fair comment. We do all have preferences. I too enjoy coding
COBOL, but I have come to enjoy coding C# more. The fact that COBOL can
support OO is one of the things keeping it alive at the moment. For around a
decade I coded OO COBOL and found it very useful. BUT, the other OO
languages do it better (and slicker, leaner, and meaner...) so it makes it
hard to justify using OO COBOL, once the decision is taken ot move to OO and
knowing that the language for OO Environments like .NET is really pretty
irrelevant. If the source code doesn't matter, it is sensible to choose
whatever is quickest and most comfortable to write. If I can write 300 lines
instead of 2000, then that's a no-brainer (at least as far as I'm
concerned). (I believe this is a major factor in the success of scripting
languages like PHP and Python. They are quick to write and they are
powerful.)


Of course as a total topic, we are completely screwed with the
J4/PL22.4 approach, producing the barest essentials for
Collections/Dictionaries - and it appears to me a la Fujitsu style,
pioneered by Thane and I think the current head honcho who replaced
M/F's Don Schrickner is also a Fujitsu user - but can't be sure. The
whole exercise totally ignored the fact that the
Collection/Dictionary classes are at the bottom rung in an
hierachial tree, drawing off various forms of arrays, down to bits
and bytes. Now as to my own usage I can achieve all I want from the M/F
set of
OO classes, bearing in mind I've never looked at Webbing etc.,
promising myself I would get around to it some day. I can honestly
say, with but one exception, I can do it all in M/F OO COBOL. The
exception - using RGB values to get beyond the ugly 16 prime colours
in DOS Screen Sections. Without go ape over Technicolor, I can
generate pastel colours for combo dropdown lists. I got a routine
from Newbury which invoked Windows APIs. Worked fine with only one
Dropdown in a Dialog but went belly-up when it had two or more
Dropdowns, (say the first was pastel blue, and the second, pastel
yellow (more like 'Wheat').

Well many of the business applcations today are all about the web. The
question is not whether OOCOBOL's "all" is equivalent to Java's
"all". It certainly is possible to code classes equivalent to Java
in OOCOBOL, but the point is the Java programmer already has this
huge, powerful library at his disposal. Someone already used to that
will look at COBOL and see it as very far down the power curve. Not
saying it is true but it is a perception.


The number of classes available is only one measure of power. .NET 3.5
offers around 80,000 classes. They certainly do make life much easier and
increase productivity. You can bet that whatever you want to do there is
probably a class that does it.

When it comes to doing your thing with M/F OO - we aren't just
talking about Debits and Credits or Inventory Control. My
application was, (dropped it now), Corrosion Testing at oil/gs
plants. I would probably need to be mad but the classes do allow me
to get into pens, drawings, shapes (simple methods to draw a circle
for instance, then subsequently colour it - but definitely, rather
than re-invent the wheel invoke a separate Graphics package, from
people who have put a lot of resources into developing it).

Intellisense with dotNet is great and probably with not too much
effort both F/J and M/F could have done the same thing, building
dictionaries to cross reference methods. Being seduced by Microsoft,
Fujitsu jumped in with both feet and to be competitive, M/F had to
do the same. Not much point them duplicating Intellisense.

Now I'll ask Charlie a question. As a result of a comment you made in
another thread about Java, and it appeared to me, Pete concurred,
were you making the point that Java is a dead duck. A Wiki entry
appeared to confirm what I thought you were saying.

Jimmy, Calgary AB

Java is far from being a dead duck. It is however not a silver
bullet. Recoding COBOL functionality manually in Java is a great
opportunity for introducing new bugs. Also being somewhatt base upon
C syntax Java is harder to read and maintain than COBOL, at least in
my experience. Of course I have much more experience with COBOL than
with Java.

That is the general reaction when COBOL people encounter Java. It really
comes down to practice and learning curve. As experience grows, so does
facility and what once seemed "hard" becomes second nature. I agree that
there is not much point in recoding COBOL in Java. The two fundamental
paradigms are different. If you are committed to OO and therefore using
Java, it would still make sense to refactor your COBOL code into OO COBOL
rather than Java. (it is simpler to keep the COBOL than to translate it,
although there are some very good programs that can convert COBOL to Java.)

Encapsulate it, wrap it and forget about it. Carry on with Java development.

In the component based world, once a component is wrapped, the language it
is written in is really irrelevant. I'm generating a Data Access Layer
comprised of OO COBOL components for someone at the moment. These
components will be used to manage and provide separation for a DB with a
couple of hundred tables on it. The interesting thing is that the DAL
components (in OO COBOL) will be used by SQL stored procedures and by VB
application code, and possibly, by COBOL. Client knows the components are
written (generated) in COBOL and has no problem with it. He doesn't care,
and neither should he. The components expose methods and functionality
which he needs, and those are invocable from any language which implements
the COM interface. VB does, so that's all right then... :-)

I do plan to have the Toolset generate this code in C# at some future date,
but right now, it generates around 3000 lines of COBOL which encapsulates
all possible access ( backward and forward sequential and skip-sequential,
and random, for GET, and Insert, Update, and Delete for PUT) to a given set
of related, normalized tables. (A component is generated to support and
manage each given Tableset. These components do construction and
deconstruction of application buffers, type conversions between database
types and COBOL (especially dates...), handle database connections, and
manage multiple instances of themselves running GET and PUT threads... it is
all really good fun... :-)

I don't really think arguments about programming languages mean much any
more.

It is all about functionality, and encapsulating it so it can be deployed
anywhere, and used by anything.

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: COBOL and Java Relative Perceived Power
    ... offer that is equivalent to that, that would make me want to use COBOL ... 003 classes for Java Support ... Smalltalk, culminating in Smalltalk 80. ... Java supports inheritance. ...
    (comp.lang.cobol)
  • 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 need help!!
    ... trying to use the java based record editor program on sourceforge to ... Most COBOL environments have utilities available to create standard ... Write a small COBOL program to convert all the packed fields to ... Do you think my Java decimal package will help more people use Java on ...
    (comp.lang.cobol)
  • Re: Believe me, you WANT to read this!
    ... This is a success story - but it is still PROMOTING Microsoft as the sloution:- ... for them to have gone in the first place, sraight from mainframe thinking into, shhh..., OO-techniques via Java. ... COBOL for the .Net ".. ... As for finding the link and wading through umpteen screens, with very discernible pauses, said "Done", the progress bar at the bottom is ...
    (comp.lang.cobol)
  • Re: COBOL and Java Relative Perceived Power
    ... What does COBOL have to offer that is equivalent to that, that would make me want to use COBOL instead of ... 003 classes for Java Support ... Certainly hierarchical classes were central to Smalltalk, ... Now as to my own usage I can achieve all I want from the M/F set of OO classes, bearing in mind I've never looked at Webbing etc., promising myself I would get around to it some day. ...
    (comp.lang.cobol)