Andrew Lentvorski wrote: > Christopher Smith wrote: >>> You described Java. :D > Not really. He described something more like Lisp or Erlang that is > compiled down to machine code and has an FFI.
Well, most Lisp these days is compiled down to machine code, but Lisp still isn't the same thing as C++ (much to the relief of Lisp coders everywhere ;-). What little I've done with Erlang to date does suggest it has a lot of the key features for this, but I don't know it well enough to make that call. >> Java lacks from that list: >> 1) overloaded operators > > I'm torn. On one hand they are sometimes useful. On the other hand, > unless you have actual access to the abstract syntax tree, they tend to > be suboptimal. Yup, there is a clear trade off. No wrong decision really, just a design decision. >> 3) destructors, and lexically scoped resource management in general > > Sorry. Unless you are doing embedded software, this is bad. It is the > source of 80+% of all bugs in C/C++ programs. The fact that you said "C/C++" kind of screams that you aren't getting the point here. C most definitely does not have destructors, and in fact most resource management related bugs in C++ can be traced back to failing to apply C++'s semantics for avoiding these problems. One of C++'s greatest strengths (C compatibility) really turns out to be a short coming in this regard: programmers code C++ programs like they are C programs. > I might concede this if you threw around a lot of sockets. However, I > tend to throw around a lot of sockets in Java and have yet to bump into > a time when I ran into a limit because the garbage collection wasn't > efficient enough. Garbage collection doesn't manage sockets at all. That's the problem. > Garbage collection is good. Try it ... you'll like it ... ;) Garbage collection only manages one resource: memory, and it does it based on a specific set of assumptions that are plugged in to the runtime. They allow for some fairly lame parameterization of these assumptions, but there really isn't a helpful way to define your own policy for how memory gets managed (Java's saving grace is that it turns out that for memory management it is possible to define a sufficiently sophisticated policy that handles the 90% case quite well). If you want to define a policy for any other resource, you are truly up a creek without a paddle, and in fact garbage collection actually makes it harder. There are certainly classes of programs where this stuff doesn't matter, particularly with building a simple prototype. If you are trying to claim that this isn't an issue for a lot of Java programs, check out how man serious projects don't have a "finally" clause in them. ;-) >> 4) multiple inheritence > > Toss-up. I find that the more programming experience I get, the less I > use inheritance, period. IsA generally isn't. I agree that multiple inheritance is, in general, a trade off that is questionable. I'd also agree, that there are a lot of languages where unfortunately a deep hierarchy does more harm than good (and I'd put both Java and C++ in that boat). My point is merely that combining multiple inheritance with these other features allows a unique and useful capability. > I have the same opinion about the Collections interface in Java. I use > the concrete interface rather than the Collection interface. Use the > richest interface that makes sense. "concrete interface"? > I do find the fact that I can't create a default action for interfaces > in Java to be annoying. If you use factories and dynamic proxies you can build a framework that will do it for you. You can probably do something similar with attributes as well. >> 5) fairly well defined performance costs > > Unless you are in embedded, I find this to be a red herring. In fact, > the last couple of Java programs I wrote outperformed their C++ > counterparts by a good margin. I wasn't trying to suggest that Java was inherently slower than C++. Indeed, I've worked on projects where I was able to tune Java to achieve equivalent or better performance than C++. It's actually pretty easy to write fast code in Java. It's a little trickier to write efficient code, particularly generic and efficient code, because the overhead of the runtime is deliberately left as very ill defined. While this is pretty much a non-issue for applications, it is often an issue when defining reusable components. > The memory allocator in Java 1.5 is > quite good and does a nice job of balancing against small vs. big > objects and maintaining memory pools. If malloc() matters, Java is > going to kick C/C++ all over the room. This is a totally different point, but the difference is that in C++ you can allocate objects and arrays on the stack, which really makes a huge difference (so much so that the next Java runtime is going to have escape analysis so that it can finally allocate on the stack... and the performance win from this is huge). > Most programmers are not that good at manually managing resources. Agreed. This is exactly why one would want to have a declarative approach to managing resources. It avoids that whole manual management mess. >> On top of that, it's support for generic programming is limited enough >> that it's hard to use it effectively outside the context of collections. > > That I might agree with. However, have the new generics in 1.5 > addressed this for you? No, they are severely crippled. --Chris -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
