begin quoting Christopher Smith as of Tue, May 23, 2006 at 12:38:44PM -0700: > 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.
"On the one hand, it's really powerful, and cool, and nifty. It lets you do all sorts of amazing things. On the other hand, it's trivially abused, makes code hard to read, harder to understand, and very difficult to debug trivial errors analytically." Not all design decisions have no right answer. With C++, however, many of the design decisions were forced by previous choices. Those decisions were the best decision, given the circumstances, language goals, and previous decisions. (Once upon a time I was walked through the chain of design decisions in C++. It was ... a revelation. Didn't make me like the language any better, however.) [snip] > 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. ;-) ...or a consistent coding style, reasonable variable names, an ability to run in a restrictive sandbox (no custom classloaders!).... I've been evaluating Java source for three months. I need a stick. One with a nail in. Apropriate use of "finally" didn't even make the guidance, and it should have. Dunno how much analysis _that_ would have required. > >> 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. Interfaces + composition do the same job, at the cost of a little more code (and a consequent minor performance hit). > > 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 think he meant "concrete implementation [of an 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. I know a really ugly hack for interfaces. I'm not so sure I want to see it used, however. ;-) [snip] > > That I might agree with. However, have the new generics in 1.5 > > addressed this for you? > > No, they are severely crippled. I'd like to hear your take on that. (So far, I just dislike the syntax. Haven't had a chance to play with it much beyond that.) -- _ |\_ \| -- KPLUG-LPSG@kernel-panic.org http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
