Why Java sucks

[rizzix]

Zeroth you didn't mention libraries, but some have. That blurb wasn't only directed towards you.

As far as static typing is concerned, that article does not say much. Most of those arguments are wrong on so many ways. I'd love to point them out, but its really time consuming and I'm too darn lazy to even bother. Static typing provides a lot of benefits that unfortunately Java does not take advantage of fully. Nonetheless, I have to say I myself am probably addicted to static typing. I don't feel comfortable with dynamically typed languages, as I do with statically typed ones. If you'd like to learn about the true benefits of static typing (or learn about my addiction ) I suggest you give O'Caml, Haskell or Scala a look. They'll probably enlighten you on this path.

[matt271]

why cant you just write something to take code like that, and turn it into real java code. then pass the real code to javac? call it "prettyjavac" :]

[DtY]

I don't know if this has been brought up before, but :

"Non-void methods in a void context? "

I can see where it doesn't make sense to keep the result of some functions (like in the example), but not compiling if you don't (even warning you)? In Turing if you don't store the result of a function, it wont compile, which is irritating. I don't always want to use the output of a function.
I don't actually know Java, so I'll have to use a general example. Say you have a queue, and you want to do something to each item, but skip the first one.
In Java it would look something like this (I think)

//queue is an array object, or if Java arrays don't have a shift method, a specifically made queue object
queue.shift();
while (queue.length > 0) {
int a = queue. shift;
...
}
However, if you had to do something with the result of each function call:
int a = queue.shift;
while (...
Which makes it look worse, because that implies you actually want to use the first item in the queue, when you don't

[wtd]

Then your Queue class should have a method which can do what you want. Perhaps:

code:

class Queue {     // ...     public void throwAwayFirst() {         // ...     } }

[rizzix]

Then your class has unnecessarily too many methods.

Allowing for semantics that let you ignore return values one can easily reduce the number of redundant methods in the class.

[rizzix]

Even haskell implements such semantics with the (>>) operator:

code:

bar = do     return "123" foo = do     bar     putStrLn "Hello World!"

Calling foo will discard the value of bar and print ``Hello World''

You can think of (>>) as an operator that only evaulates the side-effects of a monadic function.

[DtY]

Yeah, it's a bit much to have two methods to do everything, many C functions (similarly in Java?) return an error code, or 0 if they worked. Of course, you don't want to check the return value of every function call to see if something went wrong, but you might want to check one that you think might not work, and needs to do something else if it doesn't work.

[matt271]

i use that alot in java

i make methods that return something thats only useful sometimes

and i call it as if its void for all the other times

i figured all languages could do that?

[DtY]

matt271 @ Wed Jun 17, 2009 5:45 pm wrote:

i use that alot in java

i make methods that return something thats only useful sometimes

and i call it as if its void for all the other times

i figured all languages could do that?

As far as I know, every language except Turing. I'm sure Turing inherited that from somewhere though

[wtd]

Reading material on the subject.

[wtd]

rizzix @ Thu Jun 18, 2009 3:59 am wrote:

Then your class has unnecessarily too many methods.

Perhaps "pop" should be the void method? Certainly a Queue class should have a non-destructive way to access the topmost value, and if we can get it that way, and can then remove the topmost value via "void pop()" then we're all set without adding an extra method.

[rizzix]

By that logic, reading input from the terminal should have two separate methods:

1) Read input from terminal.
2) Return the read input.

Clearly including them both in a single function voids referential transparency.

Now how practical is that?

[wtd]

Not impractical at all. Of course, that has no place in any number of highly dynamic programming languages, but Java is very static, so I don't see a cognitive mismatch between the idea and the language.

[rizzix]

wtd @ Thu Jun 18, 2009 12:12 am wrote:

Not impractical at all.

I'll give you a counter-example and demonstrate its impracticality: Since there exist two methods to perform the operation of reading from a terminals, the following is possible:

code:

foo(); readInput(); bar(); input = getInput();  .  .  .

It is now possible to write code as above!

Now if bar() calls readInput(); the result of getInput() is not what the programmer expects. By defining two separate methods for a single operation (which intuitively should be atomic) you've introduced a whole new class of bugs in your code. Thus the idea is terribly impractical.

[wtd]

It's not a single operation at all, though. It's two distinct operations.

1. Read line from input stream.
   
2. Get last line read in from stream.

Nothing currently prevents some random method from modifying state.