COBOL....

I've finally stopped retching enough to type again...

brings back memories of card stacks and big iron.

 

Maybe that is why people use Java. The longer it takes to accomplish a task, the longer you are employed. I'm sure they will soon come out with a program language that never completes the task. It will be the new hit of the industry.

 

Hey -

COBOL saved a lot of asses during the Y2K non event.

 

Hehehe... Well, as old school, I guess, as I can be.

I was using C in college in the early '80s. It's closer to 30 years old.

I actually did use Cobol, FORTRAN, even PL/1 and gobs of assemblers in my career, but C has been the one constant. It's old school when you compare it to Java or C++ or C# or whatever you like.

I like C++, by the way, but most people abuse it.

 

Interesting stuff

 

Java has the real advantage of running on anyone's processor hardware. Although, that distinction is rapidly becoming less interesting since the Intel architecture essentially dominates the world these days.

The sad thing to me is that a lot of people who learn to write software these days have little understanding of what the processor is doing underneath their work to get the job done. That's where this whole discussion hits home. I've spent my career getting better/faster/cheaper hardware out to the business world, but so much gets wasted by the application developers that it's sad. Microsoft is a big offender in this area.

 

If it's spending most of its time doing memory management then I'd suspect that the problem is in the program design -- not in the language that was used. Memory management can be an Achilles's heel for Java, but I wouldn't expect a number crunching application to do a lot of object allocations.

Still, I wouldn't choose Java for number crunching any more than I'd select an F-150 for its nimble handling.

 

It's still interesting to some of us. I work with a product that's written in Java. Windows is the most common environment our product gets installed in, but it's still less than half of the total. We also need to support Linux on Intel, HP-UX, AIX, Solaris and z/OS. It's nice to know that the hardest thing about porting the product to a new platform is creating installers and instructions for that platform.

 

Yeah, fair enough, Traveler. My company uses Java too for a cross-platform management GUI. But, depending on what your product is actually doing (in Java), the underlying mechanism can/could be incredibly inefficient (i.e., BB's fast-Fourier example). A compiled language is usually a better-performing choice. I know you understand this.

If application developers don't understand this, then the leaps and bounds of progress in processor/memory/disk technology get wasted on inefficiency. I guess that's all I'm saying. It shouldn't take 30 seconds to open a spreadsheet on modern hardware. I don't care how "powerful" the spreadsheet/word-processor/gizmo is.

 

For most people, computing speeds are fast enough that efficiency is just not especially important any more. That's not true of intensive engineering/physics simulations, where jobs run for days on superclusters. But for most people, processing video is the most resource-intensive thing they do.