Comments on Java is Object-Oriented COBOL, page 3 of 4
Re: Java is Object-Oriented COBOL
Steve Holden · 2004-04-06T10:42:00
> Isn't it amazing that it's so popular despite all these > drawbacks? > > Why are the technically bad solutions so often more > successfull than the technically good solutions?
Superior marketing (cf. Windows)
Re: Java is Object-Oriented COBOL
Wim Ahlers · 2004-04-23T05:28:00
For those who are interested: I have written a 70+ page PDF document describing object-oriented and object-based techniques using COBOL-85. This document also contains an extensive chapter on JAVA in respect to COBOL.
Interested? Send mailto: ahlers_wim@hotmail.com
Re: Java is Object-Oriented COBOL
Peter da Silva · 2006-03-15T12:08:00
> The type at the start of the declaration is there [...]
The type at the start of the declaration is there for two reasons.
First, the designers of Java thought that they would have to determine all types at run-time if they allowed late binding, despite the fact that Smalltalk was able to use type inferencing in the late '70s.
And the lack of late binding means you have to have wrapper classes all over the place... which add all the overhead of naive late binding and can't be optimised nearly as easily.
If they'd done that, the declaration would simply be:
aThing = new Thing();
Second, the designers didn't take the next logical step:
Thing aThing = new();
Something about Java
piglet · 2006-03-16T09:19:00
There must be something about Java if "everybody" is screaming about it these days. "Everybody" seems to agree that Java is verbose, and "everybody" cites as the prime example of this terrible verbosity the fact that variable declarations are preceded by a type name. Wow, that's really an atrocity worth writing countless pages of angry screming hysteria! The average Java coder spends about 57% of their job time writing out those darn type declarations. Programming would be sooo much easier, faster, more productive if just we could leave them out. Never mind that the resulting code would be way more difficult to read - surely programming is about typing code as fast as paossible, not about reading it afterwards, so Perl is doubtless a much better language, QED.
The other "argument" mentioned in the blog - "Java is drowning in the complexity of its APIs", "In terms of learning curve, of course, this makes Java a little like Everest", is plain ridiculous. If Java were so difficult, we wouldn't be in a situation where just about everybody is programming in Java (including many who lack a proper CS background, which is a drawback of any popular language).
I have challenged the "Java is verbose" mantra time and again. Among the most outrageous examples is Steve Yegges insinuation (http://opal.cabochon.com/~stevey/blog-rants/lisp-wins.html ) that you need 24 lines of Java code (rather than two or three) to print out the first 5 square numbers. Yegge's justification is that the Java solution needs to copy in every detail the language constructs used by his Perl example code, and that it must copy the output format built into Perl rather than using the equivalent but not identical format built into Java. If you compare language A with language B based on features contingent on A rather than on a neutral specification, then B will obviously lose, whatever language you chose for your comparison.
If only we could focus on what needs to be done (I mean, in real world software engineering) and how best to do it, and then see what different languages have to offer.
Re: Something about Java
robert young · 2006-03-18T07:31:00
nice to see this thread come back. almost April Fool's day again, too.
after this thread began, i ran across a quote which i can't find so i won't attribute it, that was about: do you really want to be the next COBOL programmers? i wrote back that they already were.
Stroustrop, Arnold, Holub, Meyer, Pragmatic Programmer Crowd at least have written that java in the wild is really just procedural programming wrapped up in fancy clothing. the promiscuous spread of the Bean Paradigm is the best example.
java is just COBOL; not even OO. the syntax of OO is a necessary, but is not itself sufficient, to make a languages use OO.
for an example of how java can do an OO job, see Holub's "Bank of Allen". it may make you angry. but prove him wrong.
Re: Java is Object-Oriented COBOL
Elizabeth Wiethoff · 2006-03-18T20:44:00
> Perhaps the language is the way it is to allow for the possibility that one day some daring soul will write: > Thing aThing = new NotThing(); > and a new metaphor will be born.
Ahh. Have you never seen? InterfaceImplementedByClassThing aThing = new ClassThing();
This is part of what's known as "programming to an interface, not an implementation."
Re: Something about Java
piglet · 2006-03-20T06:27:00
"do you really want to be the next COBOL programmers? i wrote back that they already were."
I think I read that too, and somebody answered correctly: the next COBOL programmers will be COBOL programmers. Because like it or not, they are going to stay around, perhaps longer than the rest of us ;-)
"Stroustrop, Arnold, Holub, Meyer, Pragmatic Programmer Crowd at least have written that java in the wild is really just procedural programming wrapped up in fancy clothing. the promiscuous spread of the Bean Paradigm is the best example. (...) the syntax of OO is a necessary, but is not itself sufficient, to make a languages use OO."
If you mean to say that any Java can be (ab)used procedurally by programmers who don't understand OO, we have no disagreement here, but this is true for any OO language. I would even go further and state that not everybody pretending to be a Java programmer has a sufficient understanding of procedural programming. As I said before, popular languages always suffer from the drawback of being ... popular. As we all know, there are two kinds of languages ;-)
Re: Java is Object-Oriented COBOL
nes · 2006-03-20T13:16:00
What COBOL got right for a language specialized in business apps was fixed length char and decimal variables vs. strings, integers and floats. Fixed length types are still used in most databases and are one of the reasons for the app-DB mismatch.
As far as Java goes I personally enjoy the size of the API. It upped the bar as far as what amount of library support is required for a new language to be acceptable for development. I would not like to work in a language where I have to recreate things like an efficient hash table implementation or XML parser for instance. Granted there are ugly corners but I learned to live with it.
Where Java as language failed was in requiring explicit static typing in all the code. A lot of architecture in Java exists just to work with (or around) its type system. All interesting modern languages since C++ are either:
** dynamically typed for smaller size and complexity of the language implementation and faster compile, execute, debug turnaround.
** use type inference for faster executable speed and additional compile time checks.
Typing has its benefits but it is a tricky beast for most programmers to understand well. The complexity of templates in C++, generic type signatures in Java 1.5 and cryptic type errors in Haskell and Ocaml are proof of that.
Re: Java is Object-Oriented COBOL
robert young · 2006-03-20T17:23:00
> What COBOL got right for a language specialized in > business apps was fixed length char and decimal variables > vs. strings, integers and floats. Fixed length types are > still used in most databases and are one of the reasons > for the app-DB mismatch.
- COBOL was invented to support BCD arithmetic (comp-3). - the IBM (and other) mainframes were invented to do BCD arithmetic. - current microprocessors don't do BCD arithmetic so programmers either have to use comp-5, or the compiler does it for them (see MicroFocus docs). in other words, COBOL doesn't have any advantage off the mainframe. - databases don't store in BCD, except mainframe DB2 if you want to. they store in native numeric datatypes, which is what the processors use. - the achilles heel of COBOL is the copybook; which is what 's been described. "interfacing" with COBOL code in an OO manner is a nightmare. on the other hand, there's not a lot to distinguish a copybook from a bean. - *nix databases that i've used since about 1990 all use variable length data storage, no matter what you define in the DDL. mainframe DB2 still uses VSAM services for storage, so is confined to that structure. - COBOL was/is/always will be a sequential batch processing language at its core. if that's what you value, then COBOL might be the best answer. - Jim Gray, and some of his friends at M$, have been making noise that the trend in the differential cost of disk density and disk heads means that we should abandon random access and go back to sequential processing. if you believe that, then cut out the middleman and just do COBOL.
Re: Java is Object-Oriented COBOL
nes · 2006-03-21T10:03:00
Advertisement
> - current microprocessors don't do BCD arithmetic so > programmers either have to use comp-5, or the compiler > does it for them (see MicroFocus docs). in other words, > COBOL doesn't have any advantage off the mainframe. > - *nix databases that i've used since about 1990 all use > variable length data storage, no matter what you define in > the DDL. mainframe DB2 still uses VSAM services for > storage, so is confined to that structure.
I was thinking more about the abstract concept of non-infinite data types enforced at the user input/output level. Types like short, int, long, float and double, commonly used in the industry, do not map well to the business domain. In business applications no one cares what the internal representation of a number is. The real estate on screen and printed output is more important.
In the business language of my dreams there would be only Dates (and time), UnicodeStrings and BigDecimals. The compiler would automatically optimize those types internally for best performance based on the values they contain. It would validate the input and it would convert and truncate strings, round fractional values and print * (for numbers that are too big) on output, based on the specified format and size.
In that sense Java is a step backwards and closer to garbage collected C++ than OO COBOL, in my opinion anyway. My wrestling with some legacy COBOL happened over 10 years ago and it was a small project, so my memory is a bit rusty.
Re: Java is Object-Oriented COBOL
Steve Holden · 2004-04-06T10:42:00
> Isn't it amazing that it's so popular despite all these> drawbacks?
>
> Why are the technically bad solutions so often more
> successfull than the technically good solutions?
Superior marketing (cf. Windows)
Re: Java is Object-Oriented COBOL
Wim Ahlers · 2004-04-23T05:28:00
For those who are interested:I have written a 70+ page PDF document describing object-oriented and object-based techniques using COBOL-85. This document also contains an extensive chapter on JAVA in respect to COBOL.
Interested? Send mailto: ahlers_wim@hotmail.com
Re: Java is Object-Oriented COBOL
Peter da Silva · 2006-03-15T12:08:00
> The type at the start of the declaration is there [...]The type at the start of the declaration is there for two reasons.
First, the designers of Java thought that they would have to determine all types at run-time if they allowed late binding, despite the fact that Smalltalk was able to use type inferencing in the late '70s.
And the lack of late binding means you have to have wrapper classes all over the place... which add all the overhead of naive late binding and can't be optimised nearly as easily.
If they'd done that, the declaration would simply be:
aThing = new Thing();
Second, the designers didn't take the next logical step:
Thing aThing = new();
Something about Java
piglet · 2006-03-16T09:19:00
There must be something about Java if "everybody" is screaming about it these days. "Everybody" seems to agree that Java is verbose, and "everybody" cites as the prime example of this terrible verbosity the fact that variable declarations are preceded by a type name. Wow, that's really an atrocity worth writing countless pages of angry screming hysteria! The average Java coder spends about 57% of their job time writing out those darn type declarations. Programming would be sooo much easier, faster, more productive if just we could leave them out. Never mind that the resulting code would be way more difficult to read - surely programming is about typing code as fast as paossible, not about reading it afterwards, so Perl is doubtless a much better language, QED.The other "argument" mentioned in the blog - "Java is drowning in the complexity of its APIs", "In terms of learning curve, of course, this makes Java a little like Everest", is plain ridiculous. If Java were so difficult, we wouldn't be in a situation where just about everybody is programming in Java (including many who lack a proper CS background, which is a drawback of any popular language).
I have challenged the "Java is verbose" mantra time and again. Among the most outrageous examples is Steve Yegges insinuation (http://opal.cabochon.com/~stevey/blog-rants/lisp-wins.html ) that you need 24 lines of Java code (rather than two or three) to print out the first 5 square numbers. Yegge's justification is that the Java solution needs to copy in every detail the language constructs used by his Perl example code, and that it must copy the output format built into Perl rather than using the equivalent but not identical format built into Java. If you compare language A with language B based on features contingent on A rather than on a neutral specification, then B will obviously lose, whatever language you chose for your comparison.
If only we could focus on what needs to be done (I mean, in real world software engineering) and how best to do it, and then see what different languages have to offer.
Re: Something about Java
robert young · 2006-03-18T07:31:00
nice to see this thread come back. almost April Fool's day again, too.after this thread began, i ran across a quote which i can't find so i won't attribute it, that was about: do you really want to be the next COBOL programmers? i wrote back that they already were.
Stroustrop, Arnold, Holub, Meyer, Pragmatic Programmer Crowd at least have written that java in the wild is really just procedural programming wrapped up in fancy clothing. the promiscuous spread of the Bean Paradigm is the best example.
java is just COBOL; not even OO. the syntax of OO is a necessary, but is not itself sufficient, to make a languages use OO.
for an example of how java can do an OO job, see Holub's "Bank of Allen". it may make you angry. but prove him wrong.
Re: Java is Object-Oriented COBOL
Elizabeth Wiethoff · 2006-03-18T20:44:00
> Perhaps the language is the way it is to allow for the possibility that one day some daring soul will write:>
Thing aThing = new NotThing();> and a new metaphor will be born.
Ahh. Have you never seen?
InterfaceImplementedByClassThing aThing = new ClassThing();This is part of what's known as "programming to an interface, not an implementation."
Re: Something about Java
piglet · 2006-03-20T06:27:00
"do you really want to be the next COBOL programmers? i wrote back that they already were."I think I read that too, and somebody answered correctly: the next COBOL programmers will be COBOL programmers. Because like it or not, they are going to stay around, perhaps longer than the rest of us ;-)
"Stroustrop, Arnold, Holub, Meyer, Pragmatic Programmer Crowd at least have written that java in the wild is really just procedural programming wrapped up in fancy clothing. the promiscuous spread of the Bean Paradigm is the best example. (...) the syntax of OO is a necessary, but is not itself sufficient, to make a languages use OO."
If you mean to say that any Java can be (ab)used procedurally by programmers who don't understand OO, we have no disagreement here, but this is true for any OO language. I would even go further and state that not everybody pretending to be a Java programmer has a sufficient understanding of procedural programming. As I said before, popular languages always suffer from the drawback of being ... popular. As we all know, there are two kinds of languages ;-)
Re: Java is Object-Oriented COBOL
nes · 2006-03-20T13:16:00
What COBOL got right for a language specialized in business apps was fixed length char and decimal variables vs. strings, integers and floats. Fixed length types are still used in most databases and are one of the reasons for the app-DB mismatch.As far as Java goes I personally enjoy the size of the API. It upped the bar as far as what amount of library support is required for a new language to be acceptable for development. I would not like to work in a language where I have to recreate things like an efficient hash table implementation or XML parser for instance. Granted there are ugly corners but I learned to live with it.
Where Java as language failed was in requiring explicit static typing in all the code. A lot of architecture in Java exists just to work with (or around) its type system. All interesting modern languages since C++ are either:
** dynamically typed for smaller size and complexity of the language implementation and faster compile, execute, debug turnaround.
** use type inference for faster executable speed and additional compile time checks.
Typing has its benefits but it is a tricky beast for most programmers to understand well. The complexity of templates in C++, generic type signatures in Java 1.5 and cryptic type errors in Haskell and Ocaml are proof of that.
Re: Java is Object-Oriented COBOL
robert young · 2006-03-20T17:23:00
> What COBOL got right for a language specialized in> business apps was fixed length char and decimal variables
> vs. strings, integers and floats. Fixed length types are
> still used in most databases and are one of the reasons
> for the app-DB mismatch.
- COBOL was invented to support BCD arithmetic (comp-3).
- the IBM (and other) mainframes were invented to do BCD arithmetic.
- current microprocessors don't do BCD arithmetic so programmers either have to use comp-5, or the compiler does it for them (see MicroFocus docs). in other words, COBOL doesn't have any advantage off the mainframe.
- databases don't store in BCD, except mainframe DB2 if you want to. they store in native numeric datatypes, which is what the processors use.
- the achilles heel of COBOL is the copybook; which is what 's been described. "interfacing" with COBOL code in an OO manner is a nightmare. on the other hand, there's not a lot to distinguish a copybook from a bean.
- *nix databases that i've used since about 1990 all use variable length data storage, no matter what you define in the DDL. mainframe DB2 still uses VSAM services for storage, so is confined to that structure.
- COBOL was/is/always will be a sequential batch processing language at its core. if that's what you value, then COBOL might be the best answer.
- Jim Gray, and some of his friends at M$, have been making noise that the trend in the differential cost of disk density and disk heads means that we should abandon random access and go back to sequential processing. if you believe that, then cut out the middleman and just do COBOL.
Re: Java is Object-Oriented COBOL
nes · 2006-03-21T10:03:00
> programmers either have to use comp-5, or the compiler
> does it for them (see MicroFocus docs). in other words,
> COBOL doesn't have any advantage off the mainframe.
> - *nix databases that i've used since about 1990 all use
> variable length data storage, no matter what you define in
> the DDL. mainframe DB2 still uses VSAM services for
> storage, so is confined to that structure.
I was thinking more about the abstract concept of non-infinite data types enforced at the user input/output level. Types like short, int, long, float and double, commonly used in the industry, do not map well to the business domain. In business applications no one cares what the internal representation of a number is. The real estate on screen and printed output is more important.
In the business language of my dreams there would be only Dates (and time), UnicodeStrings and BigDecimals. The compiler would automatically optimize those types internally for best performance based on the values they contain. It would validate the input and it would convert and truncate strings, round fractional values and print * (for numbers that are too big) on output, based on the specified format and size.
In that sense Java is a step backwards and closer to garbage collected C++ than OO COBOL, in my opinion anyway. My wrestling with some legacy COBOL happened over 10 years ago and it was a small project, so my memory is a bit rusty.
Older comments · Page 3 of 4 · Newer comments
Back to post