A need? [LWN.net]

A need?

Posted May 13, 2005 5:46 UTC (Fri) by ncm (subscriber, #165) [Link]

So, Jon, are you saying your software is an order of magnitude harder to make work than everybody else's? The Boost library provides all manner of encapsulation of the differences between various targets (file system, socket semantics, buggy-as-hell compilers), along with encapsulating facilities impossible to express in Java. I doubt you've looked at C++ since the mid 90s; things are much, much better now.

For example, it's been, literally, years since I last coded a "delete" statement, or any semantic equivalent. Java's garbage collection would be not only useless to a modern C++ coder, but an active nuisance interfering with reliable encapsulation of resource management. (Not even world experts -- e.g. Hans Boehm, Herb Sutter -- can elucidate how finalizers might be written so as to be reliably safe to run.)

To claim an order of magnitude difference of effort between coding Java and C++ (for those tasks Java can address at all) is ludicrous on its face. It's common to claim that coding small programs in Python, and where performance doesn't matter, is three to five times quicker than in C++. That's not implausible. However, (1) Java is no Python, and (2) it's in the nature of easy problems to be easy. For hard problems you need a powerful, expressive language to encapsulate abstractions, and Java entirely fails in that. For what is Java the right language? For easy problems Python (or practically anything nimble) is right. For hard problems, C++, or ML, or even Common Lisp is right. Is there supposed to be a hair-thin sliver in the middle where Java fits, too weak and slow for big problems, too clumsy for small ones?

Take a look at Monotone for a substantial but not-incomprehensibly-large example of a cross-platform C++ program. See how much effort has really gone into porting it among Linux, Unixes, Win32, and Macosix.

No, C++ is no replacement for Java. C++ was here first. It graduated from mere "object-orientation" -- where Java remains mired -- in the mid-'90s. Rather: Java would be an entirely inadequate replacement for C++. The world does need a simpler but at least equally powerful replacement for C++, and will get one someday (certainly C++0x will come out first) but Java was never even in the running. (Java might, finally -- if it doesn't fade away when Sun gives up and drops it -- supplant COBOL; the user populations and application domains are similar.)

A need?

Posted May 13, 2005 13:57 UTC (Fri) by jonabbey (subscriber, #2736) [Link]

Does Boost provide a portable GUI? An RMI-like distributed object protocol with distributed GC? Thread safe libraries for absolutely everything? Does programming with Boost (including to the GUI layer) guarantee that I'll never have to see a pointer that might be mistargeted, allowing my encapsulation to be violated?

Does it protect me from all worries about memory ordering? Do the Boost memory management tools encapsulate calls to arbitrary libraries sufficiently that I get Java-like guarantees of memory management everywhere? Does Boost prevent me from ever having to worry about differences between operating systems? Does Boost guarantee that I'll never get a segfault or other low-level error that is not caught and processed by my defined exception handling mechanisms? Does Boost have a Java-like finally clause that is actually reliable?

I don't deny that programming in C++ has gotten more civilized since Java came out, and I don't deny that people are doing large, reliable programs in C++.

I still maintain, however, that our software could not have been done in C++ in the timeframe that it was written with the limited man power with which it was done.

And I wonder what people are talking about who claim that C++ is wonderful so long as you don't touch all of these pieces, and follow these high level coding principles without fail. I could say the same about Assembly, couldn't I? Talk about powerful..

In any event, if you are offering to personally rewrite our software in C++ so that we can be finally rid of the plague that is Java, please email me.

Otherwise, I'll maintain my position that there is a purpose and a role for Java, and I'l continue to insist that we are better off for having it.

Lock-in

Posted May 13, 2005 17:19 UTC (Fri) by ncm (subscriber, #165) [Link]

I know of several portable GUI packages for C++. Take your pick. Likewise, communications support. Thread-safety is the norm in C++ libraries. One doesn't encounter pointers much, so "mistargeting" that "breaks encapsulation" (whatever that means) has never been a problem.

I don't find myself worrying about "memory ordering" either. Fortunately, C++ offers much better than mere "Java-like" guarantees of memory management -- you get guarantees of general resource management that are impossible for Java to provide, even (or perhaps especially) with finalizers. No language can guarantee against failures, and no mere language can eliminate differences between operating systems. It is most fortunate that C++ lacks Java's "finally" clause: to my knowledge that is Java's greatest single failure. (Finalizers might be worse.) The whole point of exceptions is to allow error-handling code to be concentrated at choke points, minimized, and easily exercised. "Finally" clauses, instead, multiply it and distribute it throughout the program.

I don't hear anybody saying C++ is wonderful. Powerful, yes. Fast, yes. Standard, yes. Assembly language or, equivalently, Java, cannot become powerful by following coding principles. I expect Ganymede could have been written in C++ in much less time than it took in Java; I'd guess half.

The "purpose and role" of Java is lock-in. By that standard it is very successful. Many people cannot imagine any path by which their organization might break out of the Java orbit.

Lock-in

Posted May 13, 2005 17:37 UTC (Fri) by jonabbey (subscriber, #2736) [Link]

Do these GUI packages for C++ work on Mac (OS 9 and OS X), Linux, Windows, OS/2, AIX, etc.? We've run the Ganymede client on all of these systems, and more, without so much as a recompile.

By 'breaking encapsulation', I'm referring to the fact that, in Java, if I declare a variable private in a class, nothing outside of that class can ever touch it. It's impossible to craft a pointer to the private variable (on purpose or on accident), so it's impossible to read from it or write to it. There's no possibility of my encapsulation guarantees being violated. If that variable gets written, I know exactly where the code must be that did it. No chance of one portion of our large body of code accidentally scribbling on another portion, no matter how badly we try to screw things up in our human frailty.

Yes, Java has poorly thought out finalizers. The rest of these statements are off-target. No, Java can't guarantee against the power plug being pulled, the CPU glitching, or memory being exhausted, but it can guarantee that everything else will result in catchable exceptions.

And finally is enormously useful, especially in multithreaded code, in that it can provide guarantees that execution will not leave a block without releasing locks, and so forth. Finally is not about enabling sloppy exception management, and the fact that you believe that to be the case shows that you don't know Java as well as you appear to know C++.

My code runs for months on end. If I have made a mistake and a thread runs into an exception condition, that thread unwinds, the exception is logged, and the Ganymede server just keeps going. No seg faults, ever. No buffer overruns. None of that. Not ever.

I expect Ganymede could have been written in C++ in much less time than it took in Java; I'd guess half.

Being the author of Ganymede and knowing its code rather well, I don't see how that could possibly be true. Definitely not ten years ago when it was first written. Today, perhaps, the design could be reworked in such a way that comparable functionality could be layered on top of a whole variety of independent libraries, frameworks, and external services, but to claim that we could get the portability as well as the reliability that we get with Java with a comparable effort in C++ seems wildly unlikely.

Lock-in

Posted May 13, 2005 19:15 UTC (Fri) by ncm (subscriber, #165) [Link]

"if I declare a variable private in a class, nothing outside of that class can ever touch it"

... unless you call a library.

"Yes, Java has poorly thought out finalizers."

Worse. To this day nobody has figured out how to specify finalizers so they would not be poorly thought out.

"No, Java can't guarantee against the power plug being pulled, [etc.]"

More to the point, it can't guarantee that logic errors, infinite loops, rooted memory leaks, specification errors, or any of a host of other coding ills will result in a nice exception, any more so than in any other language. C and C++ code running for months on end is the norm.

"... finally is enormously useful, especially in multithreaded code, in that it can provide guarantees that execution will not leave a block without releasing locks,"

"Finally" is a failure precisely because you have no choice but to write it out everywhere there's something to clean up. Each place you write it out is a breeding ground for bugs, because each has to be exercised separately. In C++, destructors clean up, so there no need for "finally". Java lacks destructors, so must make do with "finally".

But we digress...

A need?

Posted May 21, 2005 9:22 UTC (Sat) by renox (subscriber, #23785) [Link]

> Does Boost prevent me from ever having to worry about differences between operating systems?

*Cough* Boost doesn't but Java doesn't either!!
WORA is a myth, the reality is write once, test anywhere.

As for the C++ vs Java, I hate C++ and I dislike Java (even Sun can't make fast Java apps: in Solaris9, the java tools used to managed the OS are 10 tomes slower than the tools that existed before), so..

A need?

Posted May 13, 2005 15:41 UTC (Fri) by tjc (subscriber, #137) [Link]

> For what is Java the right language?

Internal applications in larger companies and organizations. These apps are often quite large, and the business requirements may change frequently. And they're often written by programmers with modest skills. Java works quite well for this sort of thing.