Slashdot Mirror
10 Reasons We Need Java 3
An anonymous reader writes "This article on O'Reilly Network (written by one of the most active Java book writers ever, Elliotte Rusty Harold) has some interesting points about the need for a new 'cleaned up' Java version, made to incorporate the advances in the last 7 years of its life and without the requirement to keep compatibility with old versions."
I always wondered why Sun didn't make compilers for the most common OS'es. So we'd have something like this:
.. or .. .. etc.
Java Source -> Bytecode -> Windows
Java Source -> Bytecode -> Solaris
Not only the source would be portable, but also the bytecode, as always. No changes, just a damn bytecode compiler. Of course, the java interpreter should still be included if you for some reason didn't want to run optimized code for your CPU or had a CPU that wasn't supported with specialized native code compilers.
The only thing that would mess things up would of course be if someone just distributed the native compiled code, but wouldn't that be just a brainless thing to do since if you included the bytecode everyone would be able to use it?
???
Beware: In C++, your friends can see your privates!
So I say the Smalltalk way is easier to use, there is only one integer type when doing computation, yet I can do I/O with integers in all formats I want (8-, 16-, 32-, or 64-bit, signed or unsigned, big-endian or little-endian). If high performance is required, maybe C-like types can be added too, used only in speed-critical things.
java allowed you to increase productivity, substantially?
according to this whitepaper, when developers are given their preferance of language to use to implement a solution, they're most productive. ie, someone who knows c++ and enjoys working in c++ will be just as productive as someone who knows java and enjoys working in java.
i'd be extremely interested to see some concrete independant studies showing otherwise.
> What you really need is generics (as in C++ templates).
>Java collections are vile, since they suffer from type loss
> even when used with "real" objects. I'm surprised that didn't
>come into this top ten; it's a major language deficiency.
I couldn't agree more. In fact, there is a proposal (from Sun in 2001 based on Generic Java) to do just this. I really hope it will find its way into Java soon, since Generic Java solves exactly the problem you are rightly complaining about.
Java does not need just to incorporate the advances in the last 7 years, but rather the advances (e.g. in type systems) of the last 20 years.
> > One word - ew!
:)
:))
> Why ew? Because of your limited programming
> experience with languages where this was
> eschewed?
Nope, just flamebait
> Explain? How can you write a Non-OO program in
> a Pure-OO language?
I'm not sure what your question really is here, and you seem to have answered it yourself. You can take your problem, use structured design / functional decomposition to come up with a solution circa 1980, then implement it in Java much as you would do in C. A single class, with many methods and members (hell, make 'em static while you're at it)... no polymorphism, no inheritence, no data hiding, no application-level abstraction.
You can go one step back up the ladder and pretend to be using Pascal/Modula2/Ada, using classes as abstract data types and providing simple access functions. Still not what most people would call an "object-oriented" program.
Remember, design *is* programming. A program which deliberately avoids the object-oriented features of its implementation language cannot be called OO just because it "contains objects". A good language is one which allows the programmer to express him/herself in the most suitable way for the problem being solved. If a developer has to find "ways around" a particular feature of the language, then that language is flawed.
Me? If I was asked "what is the most harmful programming construct", I would choose type casts every time - yes, even over gotos and pointers.
As you've probably guessed, I like C++. I tried Java and didn't like it. Therefore, I am just ranting bitterly and should be ignored at all costs.
These sigs are more interesting tha
Coming in J2SE 1.5, by all accounts. A "preview" compiler implementation is available from developer.java.sun.com.
Well, technically people are upgrading to VB .NET, which is wholly incompatible with VB 6.0. They are so different, and VB.NET is so unready as a passable alternative for application development, that I'm sure there's room in this space for somebody e.g. Borland to make a killing selling non-webservice, non-CLR based "Visual" development environments.
A few things I've "recompiled" into VB.NET (it really is recompilation, nothing looks the same as VB.NET is a real object oriented language, or as close as it comes from redmond's "think/market-tank") look nothing like the originals. Tight loops I spent hours optimizing run five times slower. Stuff I didn't optimize is even slower than before. But I can kind of sign off on this -- it's so nice to finally have real constructors, etc.
Hey freaks: now you're ju
Java isn't what is important, it is the write (bytecode) once, run (bytecode) anywhere that is important. Whether that bytecode is generated from Java, Python, Scheme, Ruby, or Joes New Language For His CS210 course, doesn't really matter.
.NET runtime. Any language that will work well on a stack-based architecture will compile very nicely to the JVM.
.NET.
I'm suprised that this fact just doesn't come up often when debating Java vs. the
Even though I really know nothing about C#, I suppose even it could be ported to the JVM, because C# is touted as a Java clone. Microsoft markets a "migration path" from Java to C#; does Sun do something similar for C# to Java? I have seen that there are Visual Basic to Java options.
Another interesting question is whether the GCJ implementation can handle non-Java bytecode. Imagine being able to write Java, Scheme, or Python source, distribute it as bytecode, and, if the end-user wants native binaries, they just run it through GCJ. JVM + GCJ has a lot of potential to be very formidable against
Healthcare article at Kuro5hin
I'd say his commentary ammounted to "The ratio of benefit to breakage seems far less than one." And, I agree with him. Most of the proposed changes are nitpicking -- which is to say the final distance between the originial language and the "overhauled" language is not very far, and for all that effort, you bought incompatability.
Give me templates and typedefs. Those are changes worth breaking the language over. Those are suggestions that can hold their weight in a "Top 10 Java 3" list.