Slashdot Mirror
The Coming War Over the Future of Java
snydeq writes "Fatal Exception's Neil McAllister writes about what could be the end of the Java Community Process as we know it. With the Apache Software Foundation declaring war on Oracle over Java, the next likely step would be a vote of no confidence in the JCP, which, if the ASF can convince enough members to follow suit, 'could effectively unravel the Java community as a whole,' McAllister writes, with educators, academics, and researchers having little incentive to remain loyal to an Oracle-controlled platform. 'Independent developers could face the toughest decisions of all. Even if the JCP dissolves, many developers will be left with few alternatives,' with .Net offering little advantage, and Perl, Python, and Ruby unable to match Java's performance. The dark horse? Google Go — a language Google might just fast-track in light of its patent suit with Oracle over Android."
Reader Revorm adds related news that Oracle and Apple have announced the OpenJDK project for OS X.
They are the one and only company that can pull this thing straight. They have the money, they have proven their commitment to OSS, so I sincerely hope they step in and fix this. It's too important to let Oracle mess everything up.
You know, this is very puzzling. Why hasn't FOSS come up its own managed runtime+language stack?
It's certainly not for a lack of engineering talent.
Procrastination? Lack of vision? Or is open source just too tribal and fragmented to coordinate on something so big and cross-disciplinary?
Maybe I'm being naive, but right now C# looks fairly tempting. MS aren't pulling strange "premium VM" tricks, Mono is well developed and generally works as expected, and it's not a huge leap in terms of language. Many libraries in Java have C# equivalents (Bouncy Castle, iText, etc.). If we were going to leap from Java, C# would definitely be top of my likely destinations.
But no, obviously we're more likely to jump to a language I've never heard of before, with none of the libraries we use, and no experience base to pull from...
Really? As competition to Java it is fairly comparable. It has some features that, used improperly will lead to slower code (though, they are nice as a convenience), it is missing some features, has some features that Java is missing, and the free version of Visual Studios, at least in my opinion, is a nicer IDE than Eclipse, Netbeans or Anjuta. And it's not being used in a bunch of lawsuits by it's owner.
As a point of reference as to where I'm coming from with this post - Sysadmin + Java programmer at work, C/C#/Python Programmer at home.
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
So assuming the JCP does dissolve, I fail to see why folks couldn't find a way to fork Java. Are there patents in place that would completely moot any such effort? What about clean-room reverse-engineering of the JVM, wouldn't that open some doors?
Confused by the summary's lack of options,
"What in the name of Fats Waller is that?"
"A four-foot prune."
It's too bad that some of the most promising new languages (Scala, Clojure) are JDK based. What we need is a modern lingua-de-franca, a language that's structured enough, with modern features, a good standard library, and that doesnt take 10 years to master. Go is still proprietary shite that will bite you after Google turns evil (and you know they will). Havent looked at D yet. Erlang maybe?
Is there any high-level, easy language today that's not threathened somewhow by f%^&%ng patents from the big guys?
-- Home is where you eat your heart out.
Not to mention that C# already has a ton of useful features that are, at best, planned for Java 7 and 8 (or later).
I've done significant cross-platform .Net/mono development and 99% of the stuff "just works". I'd argue that Mono is actually a better cross-platform development environment than Java *right now*. Java often requires tweaks because different builtins work differently on different platforms, even though they're not supposed to.
The open source weak spot has always been the infighting, eventual lawsuits, splitting and renaming, remember that old saying about too many cooks in the kitchen?
did you forget to take your meds?
Google is trying to force the legal issue and end this with a court battle.
Apache is trying to end it using the JCP
IBM is trying to be all chummy and get Oracle to support OpenJDK
If Google wins then Java is Free, if Apache wins then Java is Free, if IBM wins then Java is theirs.
They could have called it Goo. They just would have to be careful to never put "grey" in front of it.
Actually, thinking again, I guess they actually want it to behave like grey goo: Eat up market share from any other language until everyone writes his code in Goo.
The Tao of math: The numbers you can count are not the real numbers.
If Perl, Python, and Ruby are unable to match Java's performance, I'll take their portability, ease of development, lack of overhead and succinctness over Java any day.
Rich And Stupid is not so bad as Working For Rich And Stupid.
to Open JDK.
http://blogs.sun.com/theaquarium/entry/the_story_of_a_tweet
Basically, the original news about Oracle splitting the JVM to open/free but crippled and premium/fast commercial one were wrong and based on misinterpretation of a tweet.
Apple just today announced they are contributing their java/jvm implementation to the Open JDK project, so there will be JDK for OS X in the future as well.
So, everyone calm down and enjoy JVM + your favourite language (Scala, Clojure or what ever else you like).
As the island of our knowledge grows, so does the shore of our ignorance.
I understand the need to drive page hits by claiming, "In this bad situation $LANGUAGE could step in and fill the void", but Go seems like an odd choice. It's not that I don't like it: I've written some pet projects with it and it's a fascinating language that I doubt I'd mind having to code in as a full-time job, but they're not similar languages at all, it's an apples-and-oranges comparison
Java is interpreted, Go is compiled. Go lacks inheritance, generics, huge backing libraries, and a bunch of other things that Java programmers rely on. Basically, Go is not an application language, it's a systems programming language that happens to have garbage collection; it's closer to a replacement for C++ than one for Java.
In any event, I just don't see people abandoning Java en masse because of this Oracle spat. There's just too much legacy code out there, and too many programmers fluent in Java and nothing else.
Dislike the Electoral College? Lobby your state to join the National Popular Vote Interstate Compact.
Perl, Python, and Ruby unable to match Java's performance
I don't know about Ruby, but Perl has damn good performance, such that it still runs a number of major web sites, including this one. The ONLY reason Java is as popular is because Corporate America loves a corporate solution and Java was being sold as a solution by major vendors(think IBM, Sun and for a while Microsoft).
You cannot really sell Perl, or Python, or Ruby as a corporate solution because they cannot hijack a version, edit it and claim it is special. Hell, Perl runs on EVERYTHING what more can IBM add to it? This is really why good open source languages are neglected by large companies, they cannot charge anything for it.
It might be worthwhile to explore what it would take to make some variation of Lisp (*cough*sbcl*cough*) a workable choice for modern software developers. My own sense is that the major things lacking are a modern, powerful, cross-platform GUI and a general "lack of polish" (for lack of a better term) when it comes to interfacing with the rest of the world, but perhaps there are other fundamental issues? This seems appropriate:
We were not out to win over the Lisp programmers; we were after the C++ programmers. We managed to drag a lot of them about halfway to Lisp.
- Guy Steele, Java spec co-author (http://www.paulgraham.com/quotes.html)
Maybe it's time to drag them the rest of the way?
"I object to doing things that computers can do." -- Olin Shivers, lispers.org
Apple will contribute [to OpenJDK] most of the key components, tools and technology required for a Java SE 7 implementation on Mac OS X, including a 32-bit and 64-bit HotSpot-based Java virtual machine, class libraries, a networking stack and the foundation for a new graphical client. OpenJDK will make Apple's Java technology available to open source developers so they can access and contribute to the effort.
Understanding that the entire toolchain and widespread adoption is the most important part of getting it. We all (at least, if we were there for it) know how Java happened - the short version is that Sun positioned it as an alternative to the MS Borganism that many companies were rightly afraid of back then.
I still think Java pretty much sucks. But it has the tools, and perhaps more importantly, a huge number of able bodied code monkeys who can write it.
Enter Oracle. The entire strategy that they've pursued forever is not much different than what Microsoft tried - build or buy essential parts of the stack, and then march up and down it to dominate your category, then extract as much rent as possible. It works better in the enterprise space and is bloodier because there are fewer players. (Microsoft's ecology was too varied with too many players to really dominate like Oracle can.)
So, Oracle's strategy is obvious. They own Java, and thus indirectly can manipulate the terms of output of thousands of developers. They don't care about people liking them, and inertia means they can extract rent for a long time (Even if a second Sun/Java moment happened - say, Parrot v. Java, ramp-up for Parrot to fill the niches, get solid, debugged libraries for everything, get widely deployed, and get thousands of developers up to speed takes how long?)
They don't give a shit about Apache, or developer goodwill. The for-profit players like IBM have different strategies, but keep in mind that their goals are profit maximization, too.
So there are some potentially interesting strategic plays to be made between the various players, but anyone with a bit of experience with the business side of the industry has seen this show before.
I forget what 8 was for.
I'm sick of reading slashdot stories and comments that compare dissimilar languages with Java. What makes Java interesting, useful, and modern is the JVM; these comparisons between language features alone are ridiculous. Most of the languages suggested as alternatives in Java-related posts in the last month are merely interpreted. Python, ruby, perl, etc. are all modernish, high-level languages with dynamic typing. They all run (primarily) on their slow, crippled interpreters. This has numerous drawbacks including problematic multithreading (c.f. the arguments about python's GIL and workarounds over the years), if it's even attempted (in perl, separate processes are the only reliable way to do concurrent programming).
And now Slashdot compares Go to Java. Go is certainly interesting, but it's not in the same space as Java. Java is a portable, networked, object-oriented *application* language. It removes a lot of hassles not necessary to tinker with when writing applications. It has useful, established APIs (servlets, EJBs) for building large-scale enterprise applications. Go compiles to machine code and is therefore not portable. Go doesn't allow inheritance. Go is a language that tries to solve a different problem than Java has solved. Go is no replacement.
Java is by no means the end of all languages and runtimes, but it has set the bar pretty high. It would be wonderful for other projects to adopt Java's features and improve and extend them. It'd be awesome if such an efforts weren't completely nullified by having Microsoft as its boss.
For the naive (and the dude who argues that python is a suitable replacement for Java), below is a list of features Java provides:
Java's JVM does true multithreading. The memory model is tight, efficient, and predictable. The language includes useful mechanisms for writing for concurrency (everything from traditional locking mechanisms to concurrent data structures and the convenient "synchronized" keyword). Productive, predictable concurrency is possible in Java and not in many other languages.
The JVM offers other benefits, including security. The class verifier can sort out malicious code before it's executed. The class loader can check roles granted to a piece of code and a cryptographic signature and decide not to run code on that basis. Even if a piece of code gets loaded and executed, it's sandboxed. Talking about these features is usually relegated to discussions about java applets, but their relevance to other applications is noteworthy.
Java includes a lot of well-organized, stable libraries for doing everything from handling HTTP requests and crafting responses to doing cryptography. Its collections API has many data structures that just aren't present in other languages without looking to a third party.
Finally, the JVM makes naive code fast. One can write reasonably expressive, straightforward code and expect that the hotspot compiler will optimize it. It's a boon for getting maintainable, quality code out-the-door quickly.
I too am bothered by Oracle's litigiousness, but running away from Java isn't a solution. We need alternatives, that's for sure, but the availability of such is a lot more limited than the average slashdotter seems to think.
C++ is every bit as portable as assembly. All you need to know is what parts fail on which platforms, compile 15 different ways, and pray it all works after someone upgrades something.
You do not have a moral or legal right to do absolutely anything you want.
Objective C is associated with Apple but it's not an apple exclusive. It has the late binding attraction of Java, but the speed of C. It simplifies objects and is easier to write than C++.
Outside of assembly is there anything that isn't easier to write in than C++? Real question.
grape - the GNU free, open source rape
that was meant to be a joke right? i've written wxPython scripts, and even perl with wxWidget extensions, specifically to replace sluggish memory guzzling java "gui applications". an example of java app actually outperforming perl, python, and ruby (like google apps for java vs. google apps for python) should be a standard link on such claims.
Having to work for a living is the root of all evil.
While Sun may not have had a stellar track record (e.g. their alleged mismanagement of OpenOffice.org), at least they were not trying to actively sabotage things.
I think LibreOffice has a reasonably clear path forward independent of OpenOffice.org/Oracle, but I am still concerned for the future of MySQL and VirtualBox. At least MySQL has the MariaDB fork (and maybe we'd all be better off migrating to PostgreSQL anyhow). I am not aware of an active VirtualBox development community outside of Oracle though; they're probably at risk if Oracle decides to shake things up.
I saw a comparison a while again of 3 sites implementing identical functionality in PHP, Python, and Java, and the performance characteristics were nearly identical, assuming that none of them were interpreting on the fly. (ie, php had a bytecode cash that was hot for the purposes of the test, etc.)
If anything, I'd say that while runtime speed might be similar, Java uses more memory per connection.
Sooo... since when?
Not really. By itself C++ is more portable than Java et al. In fact, the problem is rather that C++ is too portable (ie general)!
For example, for I/O there is the basic notion about files for example, but anything more specific (like, directories or how to get a list of files etc. And don't even mention graphical thingies!) the standard is completely silent, precisely too keep things as portable as possible.
That means if one wants non-general things, one has go outside the C++ standard. Preferably there is some other standard to follow then, such as POSIX, or maybe QT.
"Give me six lines of C++ code written by the most competent programmer, and I will find enough in there to hang him."
I'm a big Objective-C fan, but running against you are the fact that most of the modern features that give it some parity with Java -- like the GC and the functional programming features -- are only supported by one extremely mercurial vendor that has a nasty tendency of making no 5-year roadmaps. Also the framework and libraries just don't offer the same coverage as Java. A lot of people at the turn of the century bet on WebObjects, which was a serious platform at that time, and now it's abandonware. Nobody wants to get burned like that again.
What was I saying about abandonware?
Don't blame me, I voted for Baltar.
Indeed. VB6 is still one of the greatest RAD for GUI building suites that has ever existed.
Sure, the interfaces you can trivially build are looking dated now (and even did so 8 years ago), but its still got all the UI functionality a business/enterprise application requires.
Thats why the move from VB6 to VB.NET is taking so long. Its not nearly as trivial in VB.NET to make the same things as you were in VB6.
"His name was James Damore."
The language is portable to any platform, very powerful, and isn't at-risk of suffering the same fate as Java.
The criticisms of it are mostly fluff in my opinion...people trying to say that their personal stylistic perferences should be industry standards, or justifying their own lack of skill by saying C++ makes things harder than they should be, etc.
C++ is not an application-level programming, but a systems-level one. Java plays both roles. Furthermore, it is not the language that is of value, but the enormous (and standard) class library; a defined component model standard for distributed computing; a defined component model standard for thin-client development; a defined standard for persistence; a defined transactional model; etc, etc, etc.
Many of the things mentioned above (sans the hiccups and false starts) have been refined, tested and tried on the field for a decade now. That is what's lacking in C++ (a language that I like more than Java... and I work on Java for a living mind you.)
There are no comparison between the two languages because they are incomparable; defined and designed for two completely different niches and roles. It's not about replacing one language with another, but about replacing an entire ecosystem with another one.
Having worked on both, worked on Java for the last 12 years (on both application and system development) and about to work again in C++ and C (embedded stuff), I can tell you this:
C++ (or the lack of equivalent enterprise/distributed plumbing) makes it unsuitable for the roles fulfilled by Java (or .NET). And vice versa, Java (despite having a shitload of de-facto and de-jure standard plumbing) is unsuitable for the roles filled by C++.
When you work with both languages and when you work on both application and system development, you very quickly how different they are; how silly is to compare them; and how impractical (if not impossible) is to consider using one in place of the other.
Not really: they also solve the problem of delivering compiled code in a form that can be easily sandboxed
Sandboxing is the job of the OS. Every program that runs is isolated from others and from the hardware by the OS. Every interaction with anything outside of its address space has to go via the OS.
Take a look at the list of security vulnerabilities in the JVM, CLR, Mono, or any JavaScript implementation. These bits of code are all incredibly complex - they have to be to get good performance - and small bugs in them can allow malicious code to escape. The operating system's protection, in contrast, is provided by the MMU, which is a relatively simple bit of hardware. You don't need some restricted subset of C, the language is entirely irrelevant. The CPU runs the binary in non-privileged mode and the program can only escape from the CPU-provided sandbox by going through the OS.
I am TheRaven on Soylent News
C++ has an astonishingly complicated grammar, which means that compilation takes forever and other tools don't work as well as they do for languages with simpler grammars, like C or Java.
C++ doesn't really have compile-time encapsulation: if you add a private member to a class, you need to recompile everything that uses that class even though the class's public interface didn't change. That woudn't be so bad in and of itself except that C++, again, takes forever to compile.
C++ also doesn't have run-time encapsulation or really any serious run-time error checking that you don't do yourself. Yes, it's for performance reasons, but some people are working on problems that aren't performance-critical and would prefer a language that doesn't pound nails through our dicks. (if it doesn't have encapsulation, why do they call it "object oriented?")
C++'s exception support is hilariously broken. 1) If you've allocated some memory for an object, and then you throw an exception, you don't have that pointer anymore, and because C++ doesn't have garbage collection you've just leaked memory. The only way around this is to implement garbage collection yourself; C++ weenies call this "RAII" and if they're really far down the rabbit hole they sometimes don't even realize that it's just them implementing shitty reference-counting garbage collection. 2) You can't throw exceptions in destructors. Well, you can, but when an exception is raised, all the destructor for objects on the stack are called, and if one of them throws an exception while you're already handling an exception the program terminates. Seriously, that's what the standard says, I'm not making this up. So you can't throw exceptions in destructors, or call any function that might throw an exception. 3) In every major compiler I've used, exception handling support is implemented in such a way that it slows down every function call you make. Yes, it's only slightly, but it means if you really care about performance, you can't use exceptions, and if you don't care about performance why the hell are you using C++? And even if you want to use them they're almost worthless; I mean you can't even get a goddamn stack trace out of them. You can throw arbitrary objects, but the catcher can't figure out what the hell the object is because of C++'s lack of reflection. Etc.
C++, in an effort to be sort-of compatible with C (except where it's not compatible with C, which makes you wonder why they bothered in the first place) keeps all of C's features while creating duplicate features with their own new, horrifying problems. So you have C++ templates, but you still need to deal with C macros. You have std::vectors, but you still need to deal with arrays. You have std::string and char*, and neither is particularly good. Making things even funnier, C++ doesn't like to use its new features and prefers the C stuff: a string literal is a char*, not a std::string, the arguments to main() are int argc, char** argv, rather than something sensible like std::vector args, iostream does not take std::string for its filename arguments, etc.
While we're on the subject, the standard iostream is pants-on-head retarded. The streams are stateful, which means that std::cout foo; depends not only on the values of cout, foo, and the overloaded left bit shift operator, but also on whatever's been sent to cout in the past. You send values like std::hex or std::setw(int) to set parameters, so when you grab a stream you don't really know what the fuck will happen. This is supposed to be an improvement over printf? They're verbose as hell, too: say you're printing some hex numbers. In C, you'd use "printf("0x%08xn", x);" for int x. In C++, you use "std::cout std::hex std::setfill('0') std::setw(8) x std::dec std::endl;" It's absurd.
The standard library is completely anemic. I'm not even talking about GUI stuff, here: there's no platform-independent way to do some really basic stuff like pausing for a length of time, or starting a new thread. You can use so
I've upped my standards, so up yours.
Indeed. C++ lacked a big marketing department ;)
Religion is regarded by the common people as true, by the wise as false, and by rulers as useful.
Honestly? You're better off abstracting off all of your business logic into the library of your choice (as long as there are hooks on each platform - C is dead safe, almost anything would work if you did it as a little 'server' type application and communicated over sockets, your choice). Then write your GUI, from scratch, for each platform.
Why? For one thing, design guidelines are different on every platform. An OSX app, a Linux app, and a Windows app shouldn't use the same controls in the same places to do the same things. They should look, think, feel, and be usable as native platform applications doing things the native platform way. This is the problem that every "cross platform" GUI development system - that I've seen at least - fails to address. You don't want your app to feel like a Windows app running on a Mac, even if the menus are positioned at the top of the screen (hello, Eclipse). Or a Mac app running on Windows (hello, iTunes). Bleah.
So when you get down to it, it has nothing to do with the language you choose. Make your GUI do GUI things and do them well, and do them natively. Its not that hard to write uncomplicated GUIs on each platform, it will take a few days to digest the style guides for OSs you're not very familiar with. But the end result will be a far superior end product.
You're special forces then? That's great! I just love your olympics!
C++ has an astonishingly complicated grammar
You could have stopped here and avoided a lot of TL;DRs, but I must say I agree with everything you wrote.
In the 1980s I started programming in C and fell instantly in love with it. It's still my favorite today, even if I use a lot of Python where it can do the job.
Imagine my disappointment when I first met C++. I had heard people mention this "improved" C and was curious to use it. I got a book named "Turbo C++ Disk Tutor" which came with four 5.25" floppies with the compiler included. The book itself was rather good, a good book about a bad subject.
In C, you'd use "printf("0x%08xn", x);" for int x. In C++, you use "std::cout std::hex std::setfill('0') std::setw(8) x std::dec std::endl;" It's absurd.
You know what worries me? Take a look at Python 3, they have deprecated the *excellent* C standard formatting method for a new way that's about as complicated and absurd as the C++ way.
Another Python "improvement": deprecated popen. This means that the nice, clean, easy to understand Unix command
output=`dmesg | grep hda`
has been replaced by:
p1 = Popen(["dmesg"], stdout=PIPE)
p2 = Popen(["grep", "hda"], stdin=p1.stdout, stdout=PIPE)
output = p2.communicate()[0]
WTF???
Today I use Python a lot, but if this trend goes on, by Python 5 or so I'm willing to bet that I'll be back to using C exclusively for my programs.
I agree emphatically with everything you said.
I'll add one more thing: debug performance. Most C++ libraries (certainly the STL) are written for prettiness more than performance and thus rely heavily on compile-time optimizations. Now, it's true, a fully optimized iterator generates the same code as a raw pointer, but that's irrelevant when you've got a debug build that runs several orders of magnitude slower than a release, and the bug you're tracking down is on the third pass over vertex 892,472 of a 2,000,000 triangle mesh.
I mean, yeah, I could rewrite the standard containers and algorithms (etc) into a form that doesn't require heavy inlining to be even remotely performant, but then what was the point of using C++ in the first place?
C++ has an astonishingly complicated grammar, which means that compilation takes forever and other tools don't work as well as they do for languages with simpler grammars, like C or Java.
Modern c++ compilers are extremely fast; not as fast as Java compilers, but considering they do much more many things (templates for example), then they are quite fast. They are so fast that compiling large code bases with them is extremely viable, and it's a task done everyday by millions of developers.
C++ doesn't really have compile-time encapsulation: if you add a private member to a class, you need to recompile everything that uses that class even though the class's public interface didn't change. That woudn't be so bad in and of itself except that C++, again, takes forever to compile.
How is that a big problem? you make it sound like it's a colossal problem, but in reality, it's not. Unless your class is used by every other class or function, the recompilation is minimal. The benefit of this is that you can use value classes in c++, whereas in Java you can't, every class is by reference, which is stupid.
C++ also doesn't have run-time encapsulation or really any serious run-time error checking that you don't do yourself. Yes, it's for performance reasons, but some people are working on problems that aren't performance-critical and would prefer a language that doesn't pound nails through our dicks. (if it doesn't have encapsulation, why do they call it "object oriented?")
If you refer to arrays, vector::at() is your friend. If you are not disciplined enough to use it, then you don't belong in programming. You can even use smart pointer classes that throw a null pointer exception, if you really want it. In any case, it's not anything like you say it is.
1) If you've allocated some memory for an object, and then you throw an exception, you don't have that pointer anymore, and because C++ doesn't have garbage collection you've just leaked memory. The only way around this is to implement garbage collection yourself; C++ weenies call this "RAII" and if they're really far down the rabbit hole they sometimes don't even realize that it's just them implementing shitty reference-counting garbage collection.
RAII is actually superior to Java's garbage collection. It's much more critical for big applications to release as much memory as possible upfront.
2) You can't throw exceptions in destructors. Well, you can, but when an exception is raised, all the destructor for objects on the stack are called, and if one of them throws an exception while you're already handling an exception the program terminates. Seriously, that's what the standard says, I'm not making this up. So you can't throw exceptions in destructors, or call any function that might throw an exception.
How is that even a problem? Java's unpredictable finalization order is way more of a problem.
3) In every major compiler I've used, exception handling support is implemented in such a way that it slows down every function call you make. Yes, it's only slightly, but it means if you really care about performance, you can't use exceptions, and if you don't care about performance why the hell are you using C++?
Read this first: http://www.open-std.org/jtc1/sc22/wg21/docs/TR18015.pdf Exception handling has a cost only if there are non-trivial destructors to execute. Since C++ allocates most objects statically, the performance cost is factored into the program as if no exception was thrown. On the other hand, in Java, you pay the price in garbage collection.
And even if you want to use them they're almost worthless; I mean you can't even get a goddamn stack trace out of them.
True, but you can have other meaningful information, such as the file
Modern c++ compilers are extremely fast; not as fast as Java compilers, but considering they do much more many things (templates for example), then they are quite fast. They are so fast that compiling large code bases with them is extremely viable, and it's a task done everyday by millions of developers.
That depends on who's header files you have to include. Often someone's API will be so template-heavy that it takes a full minute (per compilation unit) just to parse their silly headers. Which is sad because I've never had the same issue with enormous C headers or when referencing a good half of the .NET runtime in a C# compilation.
And yeah, that's a minute on a modern compiler on a fast machine.
How is that a big problem? you make it sound like it's a colossal problem, but in reality, it's not. Unless your class is used by every other class or function, the recompilation is minimal.
The real problem there, which the GP missed, is the fact that every type must include the header of every type it contains a value member of in its own header. So if I want to keep d3d11.h out of my UI code, then my bridge renderer classes must either dispatch through virtuals, a tedious PIMPL, or not actually use any D3D types as value members, complicating other code for no good reason.
The benefit of this is that you can use value classes in c++, whereas in Java you can't, every class is by reference, which is stupid.
Java is stupid, agreed. But C++ is retarded too. Link-time code generation is old news, object sizes could be resolved then.
RAII is actually superior to Java's garbage collection. It's much more critical for big applications to release as much memory as possible upfront.
Superior? With GC I pay a fixed performance cost (and not even a very large one on modern VMs) upfront for the whole project and start writing code. With RAII I have to go around making sure everyone is actually using shared_ptr (or whatever) at every single call site.
Now Finalization, I agree, isn't the most amazing thing, but I've spent no more time chasing down finalization bugs than I have going after people who use a raw fopen despite having a nice file class with a destructor available. Depends on what you're used to, I suppose.
Exception handling has a cost only if there are non-trivial destructors to execute.
Leveraging RIAA kind of demands that such destructors exist.
C++0x will have this.
Sure, if they don't delay it another five years while all the compiler vendors run off and implement incompatible subsets of the proposals because they're tired of waiting for the committee to stop bickering.
ACE? what, are you stack in 1999? you know the Boost libraries, don't you?
Boost? I thought we were being careful about what we include so as to keep compile times down.
Templates are, for me, the single reason I prefer c++ over Java. Java's generics are stupid.
Templates are useful, until someone goes nuts with traits types and multiple levels of tag-type-param-to-overloaded-function and your debug build ends up six or more orders of magnitude slower than your release because inlining is off.
Yes, I use them, but the time spent making sure they aren't being misused is non-trivial and needs to be counted against the time saved by using them.
Funny that you say that, because I've worked on million lines of code c++ codebases that didn't have any memory leaks or other problems. But that's because we used the right libraries.
So have I. But don't forget the bit where someone spent countless hours making sure everybody else was following the rules and sticking to those libraries, rather than wandering off into std:: or inventing their own little subdoma
Often someone's API will be so template-heavy that it takes a full minute (per compilation unit) just to parse their silly headers.
Simply not true. I use boost heavily on a 120 kloc project, and it takes under a minute to compile everything from scratch. And I use quite a lot of boost features.
Which is sad because I've never had the same issue with enormous C headers or when referencing a good half of the .NET runtime in a C# compilation.
You are comparing apples with oranges. Neither C or C# have templates.
The real problem there, which the GP missed, is the fact that every type must include the header of every type it contains a value member of in its own header. So if I want to keep d3d11.h out of my UI code, then my bridge renderer classes must either dispatch through virtuals, a tedious PIMPL, or not actually use any D3D types as value members, complicating other code for no good reason.
It's not a problem at all. First of all, the compiler will only parse a header once, if guarded by #ifdef. Secondly, you can use precompiled headers.
Link-time code generation is old news, object sizes could be resolved then.
The number of things that can be done in link time is limited. Object sizes play a big role in optimizations, and you can't do some of them at link time.
With GC I pay a fixed performance cost
The cost of the GC is not fixed in any meaning of the word 'fixed'. It depends on the complexity of the graph. If your graph is very complex, the GC might take a lot of time to do its job.
With RAII I have to go around making sure everyone is actually using shared_ptr (or whatever) at every single call site.
How is that a problem of the language? it's a problem of your development team, not the language. If you have a shitty development team, they can easily mess up a Java program as well.
Leveraging RIAA kind of demands that such destructors exist.
You mean RAII obviously (I understand why you wrote RIAA though; it's customary to read something against RIAA at least once per day on slashdot). Yes, RAII demands destructors, and stack unwinding demands destructors to be invoked, but you are in control of it: if your loop is time-critical, then you can get raw and avoid them.
Sure, if they don't delay it another five years while all the compiler vendors run off and implement incompatible subsets of the proposals because they're tired of waiting for the committee to stop bickering.
No compiler vendor has implemented a subset incompatibly. The only thing that is left is to clear up move semantics. Other than that, c++0x is ready. I am already using it in GCC 4.5, with exceptional results in code clarity.
Boost? I thought we were being careful about what we include so as to keep compile times down.
It's not so bad as you make it to be. Even using boost::bidirectional_map takes very little time to compile on modern machines.
Templates are useful, until someone goes nuts with traits types and multiple levels of tag-type-param-to-overloaded-function and your debug build ends up six or more orders of magnitude slower than your release because inlining is off.
Show me a case such as you describe.
Yes, I use them, but the time spent making sure they aren't being misused is non-trivial and needs to be counted against the time saved by using them.
Bullshit. You are just quoting something you read over the internet. Show us a such a case.
So have I. But don't forget the bit where someone spent countless hours making sure everybody else was following the rules and sticking to those libraries, rather than wandering off into std:: or inventing their own little su