The Artima Developer Community
Sponsored Link

Weblogs Forum
Java is Object-Oriented COBOL

35 replies on 3 pages. Most recent reply: Jun 1, 2011 8:25 AM by Larry Jackson

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 35 replies on 3 pages [ « | 1 2 3 | » ]
Adam Connor

Posts: 12
Nickname: adamconnor
Registered: Jan, 2004

Re: Java is Object-Oriented COBOL Posted: Apr 5, 2004 5:07 AM
Reply to this message Reply
Advertisement
> "Do we really have to design our languages with execution
> efficiency as a foremost consideration in the twenty-first
> century?"
>
> No. See http://www.paulgraham.com/arc.html for a language
> being designed awith quite the opposite in mind.

Or just use Common Lisp...

Malte Finsterwalder

Posts: 20
Nickname: jufoda
Registered: Aug, 2003

Re: Java is Object-Oriented COBOL Posted: Apr 5, 2004 5:28 AM
Reply to this message Reply
> As type systems go, Java's is right out of the stone ages
> (along with its loop constructs, static methods that are
> really functions, classes that aren't objects, primitive
> types, arrays different from collections, StringBuffers
> that aren't Strings, and a whole host of other poorly
> thought out idiocies).
>
> Java is gratuitously complex in a lot of areas - clearly
> the whole thing was a low budget rush job.

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?

Todd Blanchard

Posts: 316
Nickname: tblanchard
Registered: May, 2003

The Kids are Alright Posted: Apr 5, 2004 7:38 AM
Reply to this message Reply
"Why are the technically bad solutions so often more successfull than the technically good solutions?"

During an interview with Pete Townsend of The Who, he remarked "The average person is a bit thick and wouldn't know quality if it smacked him upside the head. If you steer clear of quality, you're alright."

The average programmer would write a bubble sort to manage a million records simply because its the only sort algorithm he can remember how to code.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: The Kids are Alright Posted: Apr 5, 2004 3:25 PM
Reply to this message Reply
> The average programmer would write a bubble sort to manage
> a million records simply because its the only sort
> algorithm he can remember how to code.

I believe this is why we should continue to differentiate between programmers and software engineers. There truely is a difference that becomes apparent when you experience this kind of software development activities.

Engineers attempt to do it right no matter what. Only when the cost exceeds the budget do they get the project taken away from them and the programmers get it.

Engineering often employs brute force simplicity.

Programming often employs brute force complexity.

Gregg Wonderly

Posts: 317
Nickname: greggwon
Registered: Apr, 2003

Re: Java is Object-Oriented COBOL Posted: Apr 5, 2004 3:40 PM
Reply to this message Reply
> I'm no Java fanatic, but I'm not sure Java's API is more
> bloated than that of any other general purpose language.
> You might argue that C and C++, with their standard
> libraries, have relatively modest APIs, but this ignores
> the fact that the standard libraries are inadequate for
> most real-world applications -- the developer will have to
> write his own APIs, or go out and find a third-party API
> to fill in what's missing. You have to put all that
> functionality somewhere, either in libraries or (ugh) in
> the language proper. (Maybe APL junkies would favor the
> latter approach, but I suspect most programmers would
> not.)
>
> What matters to me is not so much the size of Java's API,
> but how well it is implemented. I can't say much
> about that, except to note that many of Java's classes
> have a bad case of memberitis. Maybe that's what
> you were talking about in the first place, so now I'll
> shut up.

There are actually two completely separate issues here. One is the Java Language which is covered by the Java Language Specification. It determines the syntax and semanics of the language.

Then, there are several platforms that utilize the Java Language to provide a set of features for a particular use.

The J2EE platform is the most verbose, expensive and outright over programmed platform of all.

The J2SE platform is what most people mean when they say "Java is ...".

The J2ME platform is what runs on phones, PDAs, and many small platforms including micro processors such as the aJile aJ-100, the Dallas Semicondutor TINI hardware etc.
J2ME has something called profiles that allow the addition of features. J2ME+MIDP provides the Mobile Information Device Platform that you see on phones and other graphically interactive J2ME devices. There is J2ME CLDC (Connected, Limited Device Configuration) and the J2ME CDC (Connected Device Configuration) differentiation as well.

All of these things are separate and part of the overall Java platform definition. It's much more extensive than any other programming language based platform definition. This is the factor that I believe drivers the interest. You can in fact, find Java 'anywhere' that you need it. This means that you can develop and test code on a PC, a farm of PCs, servers etc., with easy to replace stubs. Then you can plug that code into the target environment and only have to worry about the implementation details on that platform.

The other side of this is that when you have a core algorithm, such as a network centric application, you can take that code and develop it and target it to a single Java platform, and then later plug it into another Java platform. Because Java is Object oriented, and it uses interfaces for defining responsibilities, you can create the new interface implementations for that platform and be done.

You really have to look at all the details and all the real engineering of the platform to appreciate the potential.

Granted, there are all kinds of ugly things that you can find and rant about. But, guess what, humans are imperfect and make mistakes! Funny how that keeps affecting our world...

Kim

Posts: 4
Nickname: kmarius
Registered: Oct, 2003

Re: Java is Object-Oriented COBOL Posted: Apr 6, 2004 6:25 AM
Reply to this message Reply
What we really need is a more flexible "new".

Example:

Thing aThing = new ();

or with arguments:
Car c = new ("Honda","blue");

The compiler should fill in the necessary information

Steve Holden

Posts: 42
Nickname: holdenweb
Registered: Apr, 2003

Re: Java is Object-Oriented COBOL Posted: Apr 6, 2004 10:42 AM
Reply to this message Reply
> 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)

Wim Ahlers

Posts: 3
Nickname: wahlers
Registered: Apr, 2004

Re: Java is Object-Oriented COBOL Posted: Apr 23, 2004 5:28 AM
Reply to this message Reply
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

Peter da Silva

Posts: 1
Nickname: argent
Registered: Mar, 2006

Re: Java is Object-Oriented COBOL Posted: Mar 15, 2006 12:08 PM
Reply to this message Reply
> 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();

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Something about Java Posted: Mar 16, 2006 9:19 AM
Reply to this message Reply
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.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Something about Java Posted: Mar 18, 2006 7:31 AM
Reply to this message Reply
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.

Elizabeth Wiethoff

Posts: 89
Nickname: ewiethoff
Registered: Mar, 2005

Re: Java is Object-Oriented COBOL Posted: Mar 18, 2006 8:44 PM
Reply to this message Reply
> 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."

piglet

Posts: 63
Nickname: piglet
Registered: Dec, 2005

Re: Something about Java Posted: Mar 20, 2006 6:27 AM
Reply to this message Reply
"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 ;-)

nes

Posts: 137
Nickname: nn
Registered: Jul, 2004

Re: Java is Object-Oriented COBOL Posted: Mar 20, 2006 1:16 PM
Reply to this message Reply
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.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Java is Object-Oriented COBOL Posted: Mar 20, 2006 5:23 PM
Reply to this message Reply
> 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.

Flat View: This topic has 35 replies on 3 pages [ « | 1  2  3 | » ]
Topic: ScalaTest 1.6.1.RC1 for Scala 2.9.0 Released Previous Topic   Next Topic Topic: Programming Summer Camp: July 25-29 2011, Crested Butte, Colorado

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use