Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

Journal random_static's Journal: the problems of Java

okay, my first exposure to the basics of Java is beginning to sink in, and this is some prewriting / random-thoughts about what i feel about the language... not a finished essay by any means.

Java has a split personality. it doesn't know whether it wants to be high-level enough to manage your memory and collect your garbage so you don't have to worry about it, or whether it wants to be low-level enough to force you to dick around with variable types and worry about the differences between a char and a Character. it should pick one or the other, and then throw out the cruftiness of trying to support the other half.

Java is verbose. verbose verbose verbose verbose. also it forces you to type too much. that might be somewhat acceptable in a low-level, close to the metal, systems language where you really do want to specify exactly what you want to happen to precisely which part of the machine...

...but Java's "machine" is the JVM. why should i care if some detail of what i'm doing is suboptimal for it? it's a software abstraction, it's not something real. people! if you're gonna design a p-code interpreter and a language to compile down to that p-code, you could at least make sure they're both smart enough so you don't have to fret the small stuff all the time like that. i know it's possible, after all, that's how come there's Jython.

Java suffers from an edit-compile-run cycle. well, that's not a huge complaint, because so does any language that has such a thing. it's just that, well, that's yet another indication that this doesn't want to be a truly high-level language where you can spend your time thinking about the problem and dinking around with possible solutions to it, testing them out as soon as you type them in. instead, languages like these are low-level ones where you write out a whole program, run it through an entire toolchain, then see if it'll make the iron glow red or not. which isn't necessarily a fatal flaw, if there's a real need to pander to the idiosyncracies of the iron and you really want to make it glow as bright red as you can, even at the expense of trainwrecking your thinking a lot...

...except that java doesn't go to the damn iron, does it! it goes to a p-code midlayer! if you're gonna go impose that sort of overhead on me anyhow, why can't you at least give me an interactive toplevel to offset it at least somewhat? since i'm obviously not gonna be making any circuits smoke here anyway, so low-level bare-metal performance clearly can't be the main objective, now can it? besides, if that were the objective, wouldn't we be coding in C or assembly like performance freaks have done since the beginning of time anyway?

it's a featureful enough language to drink the OO kool-aid and do the memory management mambo, yet it's not a featureful enough language to have any more complicated a datatype than an array built-in. want a list? go look in the standard library for a class that implements something like it. if you find something useful there, you have to use verbose verbose verbose function-call syntax to interact with it that makes your list feel like anything but a natural, first-class feature of the language.

...which is yet another worry which the language refuses to handle for you, forcing you to think about one more petty detail that's nothing to do with your problem at hand or the solution you're writing for it. i can do high-level, or i can do low-level; Java tries to make me do both, and it's making me feel schizo...

you can't pretty up the syntax, because the language doesn't let you overload operators - much less define your own. apparently, that'd be too much power for regular programmers to handle. unlike the programmers who wrote the java standard library; they overloaded operators when they damn well felt like it. what i feel is that there's some sort of deep, damning fundamental disconnect there - that there's something Just Plain Wrong(tm) about a language whose standard library cannot be readily written in the language itself. its power, such as it may be, is distributed somehow wrongly, leaving it lopsided in some curious but probably significant way which i do not like, sam i am.

a high level language will - for example - not force me to worry about whether a number is an integer, a rational, a float, or some truly ginormously-sized version of one of the above; it'll just do math on numbers, and insulate me as far as possible from implementation details of the bare-naked machine. that way, i can think about the math my program is doing, instead of worrying about how the math is carried out. a low level language forces me to think about how the machine is running, instead of merely what it's running, and will frequently force me to write my own implementation of any feature i want to use which the machine can't do more or less directly. Java hasn't picked sides yet. maybe we should leave it to brew another ten years, see if it's done by then.

This discussion has been archived. No new comments can be posted.

the problems of Java

Comments Filter:

There is one way to find out if a man is honest -- ask him. If he says "Yes" you know he is crooked. -- Groucho Marx