[DMcCunney]

Originally Posted by Ralph Sir Edward

I am a dinosaur programmer (COBOL). I took a Java course about 2 years ago, thinking about retreading. Here is the performance differences, both from Object Oriented, (all O O languages) and Java, per se.

O O - How do you change an object? Well... the object has the code that made it embedded as part of the object. You end up re-executing the code to get at the data, change the data, and re-encapsulate the data with the code. You think that isn't overhead? In a non O O language, you read the data raw, in your own data layout (or existing file layout you reuse), mod the data, and write. An order of magnitude less machine use. (But you have to know your data! (i.e. you have to know what you are doing.))

You have to know what you're doing in an OO language, too.

And the object orientation is a feature. Data in an object is operated on by methods. Objects are accessed through an API. The whole idea is that you can change the methods (code) or the data the methods operate on, without any other part of the application knowing or caring. The object is a black box. The calling process issues calls in a particular format and expects to get results back in a particular format. How the object does it is the object's business. As long as call and response is unchanged, the calling process neither knows nor cares.

The big question is not how you change an object, but why you do so. And part of the skill required is understanding the problem you are trying to solve and designing objects that you are less likely to need to change down the road.

Java - an Interpreted language. Any interpretive language is an order of magnitude slower that a compiled language. (Sometimes more that one order of magnitude). A compiler writer is a special breed (I know just one.), who makes the compiled code efficient. Very efficient.

Not quite. Java compiles to bytecode. Bytecode is object code targeted at the Virtual Machine Java implements.

Other current languages like Python and Ruby use a similar design. The concept goes back to the UCSD P-system, which was used by the IBM Displaywriter and showed up in other places like the Apple II. You wrote in Pascal, but it compiled to P-code interpreted by the underlying P-system.

Garbage collection...Jeez, I thought that went out with BASIC in the early 1980's! IBM solved that problem back in 1975!!! (Had to! How else could you run 5,000 interactive terminals simultaneously on a machine the power of a Intel 486. One machine, 'cause it cost over a million dollars then!)

IBM didn't solve the problem for anything save a particular limited set of cases.

One of the biggest problems in programming has been the need to allocate memory used by your application, and free it again once done. In C, for example, you use malloc to do it, and it's on you to handle the case where there isn't enough memory available and fail gracefully. It's also on you to make sure the memory you allocated is properly freed when you're done with it, and "memory leaks" because this didn't happen are probably the single biggest headache for programmers. You did put in a "free" call to free the memory, but something happened and it never got executed....

In a language like Java, those details are handled for you. You can concentrate on the logic of the application, not the housekeeping required to make it work.

If you want to get rich as a programmer, figure out how to write a Java compiler that writes out non O O efficient code. Sell to the cloud world, where efficiency save the company money, unlike today's paradigm, where efficiency means nothing, because somebody else is paying for the hardware...

There have been tremendous advances in compiler technology since Java was first developed, and documented cases where a Java application runs faster than the same thing done in C.

Different languages evolved to solve different problems, and languages designed for a particular kind of problem get the nod as the best fit for the job. It's why we got things like Fortran, COBOL, BASIC, and C and very few people code in assembler any more.

Forget OO for a moment. Java has several compelling advantages.

1) It's cross platform. Java Virtual Machines exist for just about everything, including smartphones.

2) It's "write once, run anywhere." Java compiles to tokenized binary form called bytecode, targeted at the underlying virtual machine implemented by the JVM. The bytecode is the same, regardless of what you wrote it on. So you can take a well written Java program created on a Windows PC, compile to bytecode, and run that bytecode on a Mac, expecting it to look and behave the same.

3) Java runs by design in a sandbox, with a feature being that it can't easily affect the underlying system. You don't worry about rogue code running amok and doing Bad Things to the machine it's run on.

One of the things I'm playing with here is Eclipse, an IBM written programmer's IDE that they made open source and has contributions from developers around the world. Eclipse has a syntax highlighting editor, class browser, hooks to compilers, debuggers, libraries...everything a programmer needs to develop code. And it's extensible to handle new languages and tools.

It's written in Java. The same bytecode that implements it on my Windows PC is also running on my Linux based notebook. Just unpack the archive to the desired location and create a shortcut to run it.
______
Dennis