A need? [LWN.net]

A need?

Posted May 13, 2005 13:57 UTC (Fri) by jonabbey (subscriber, #2736)
In reply to: A need? by ncm
Parent article: A new Harmony Project

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.

(Log in to post comments)

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...