[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Article for Slashdot: Oracle for Java



Hi,

On Mon, 7 Sep 1998, Stanislav Malyshev a.k.a Frodo wrote:

> > As compared to my experience in past serious C++ projects, I have found
> > that
> > programming in Java tends to CUT my programming time by one-third.
> 
> I suppose you didn't use CASE tools with C++? And not, Visual C++ wizard
> is not a CASE tool. And a good CASE tool can immensely reduce amount of
> dirty work needed, and keep you object model as clean as your mind allows
> ;) Except this, I don't see how Java enhances programmer's work. From my
> (though limited) experience programming on Java it never was
> programmer-friendly. And fatal error "unreachable code" still drives me
> crazy... Java debugger also wasn't the best tool on Earth.

You're talking about your programming environment, not the language
itself. It is true (IMHO) that coding in Java is indeed faster than coding
in C++, when you use equally powerful tools for both languages, or don't
use ones at all.

> > >From the Linux standpoint, this could be a rather rich source of programs
> > that
> > originate in Win95/NT and run without problem in Linux. (It is rather sad
> > though
> 
> I have yet to see one. I know one that does run - Java ICQ. Pardon my
> french, but it's shit. It dumps core on me regularily. Yes, it's "secure"
> Java.
> 
> I say more - I have yet to see one useable Java standalone, except Java
> compiler itself. By useable I mean being able to run on my P133/64M
> taking less memory that netscape and emacs together, and not dropping dead
> twice a day.
> 
> This has nothing to say about Java being good or bad as a language, but
> says much for it being ready for industrial-strength projects as a tool.

Again, what you're saying is that today's JVM implementations are
seriously flawed. I couldn't agree more, but then again, it's not the Java
compiler. The bytecode it generate is perfectly working, if you could only
find a decent JVM. And as for memory usage, again, it's the JVM's need to
keep tons of data when interpreting bytecode (variable tables, call stacks
and other structures).

Shachar Tal
-------------
Taub Computer Center, Technion, Israel Institute of Technology
KeyID 0481FEF1 fingerprint = 52 1B 97 6A F2 77 AE C6  64 B6 5A 5E 14 28 8E 7E