Computer Science Canada

Why Java sucks

Author:  wtd [ Sat Oct 08, 2005 1:49 pm ]
Post subject:  Why Java sucks

Why does Java suck?

A few notes before I dive in:

Some of these points I care about more than others. They are not necessarily in order of perceived importance.

None of these flaws, by themselves are "deal breakers". I enjoy using languages which make many of these same mistakes. However, when you put all of these together they become overwhelming, in my opinion. Fixing even a few of these flaws would go a long way toward making Java more pleasant to work with.

I believe this document serves an important purpose. There are many programmers who may not have realized that there were alternatives to the way Java does things. If these complaints serve only to point that out, then it has accomplished a great deal.


  1. Where are my lists and arrays?

    Everyone uses lists. We use them everywhere.

    How do you create a list in Java?

    Java:
    ArrayList lst = new ArrayList();
    lst.add(new Integer(42));
    lst.add(new Integer(27));
    lst.add(new Integer(12));


    Things got a little better in Java 1.5.0.

    Java:
    ArrayList<Integer> lst = new ArrayList<Integer>();
    lst.add(42);
    lst.add(27);
    lst.add(12);


    But why can't Java have some kind of literal syntax for lists or arrays? Plenty of other languages do just that and it is most definitely not considered wasteful syntactic sugar.

    code:
    lst = [42, 27, 12]

  2. Why can't functions return multiple values?

    Yeah yeah... in Java they're called "methods".

    Why can't they return multiple values?

    Because C and C++ can't isn't a good reason, but it's the one that we're given. Instead we have to add extra classes to the library, or return a list.

    That second option seems nice, but it means we have to create a list (using the tedious syntax listed above), return it, assign that return value to an array or list variable, then manually grab each element in that list and assign it to some other variable.

    What's wrong with being able to just return more than one value?

    Python:
    def foo():
       return (1, 2, 3)

    a, b, c = foo()

  3. Where are the tuples?

    This one's related to the previous question.

    Simple support for tuples would ease programming tremendously. Where is this concept that so many languages have gotten right? It's missing entirely.
  4. For-each and modification?

    For-each loops make it possible to avoid off-by-one errors when iterating over collections. But this only works when we're reading the value of the elements in the collection.

    If we want to modify those elements, we cannot use the for-each loop.
  5. Where are the lambda functions?

    Instead of:

    Java:
    JButton  helloButton = new JButton("Say Hello");
    helloButton.addActionListener (new ActionListener() {
       public void actionPerformed(ActionEvent ae) {
          System.out.println("Hello");
       }
    });


    Why would it be so awful to allow something like the following?

    code:
    let hello-button :: <button> = make(<button>, text: "Say Hello");
    add-action-listener(hello-button, method (ae :: <action-event>) format-out("Hello\n") end);


    There's no needless naming. Really, does anyone care about "ActionListener" or "actionPerformed"? No, we only care about the fact that we have a method taking one argument that performs some action.

    Yes, the anonymous inner class can provide flexibility, particularly when you want persistent state. However, the vast majority of the time it is complete overkill, and a bad cludge for an important missing feature.
  6. Where are the argument labels?

    Let's say I have a method or constructor which takes several arguments. Which argument does what? Okay, I'll guess. Oops, I got it wrong and the program didn't compile.

    Hmmm... a little editing and voila! It compiles. Now let me run it. Oh... weird... I got some odd logic error. Oh, after half an hour of searching for the bug, it was because I had the right types for the arguments, but i mixed up two of them. Let me go consult the API reference.

    Why do we need to do this?

    Surely there's a better way. Many languages already know this.

    code:
    let win = window ~title:"hello" ~width:400 ~height:300 ()


    Do I need to remember if width or height came first in the argument order? Nope.
  7. Why do methods which take no parameters need parentheses?

    In C and C++, a function's name can be used as a pointer to that function. On its own, it's the address in memory of that function. It makes sense, therefore to have parentheses after the function as an indicator that it's been called.

    Java has no such concept. Nor does it have a delegate concept like D or C#. There is no way to use the name of a method outside of the definition of that method which isn't a method call.

    And yet, we still have to tack on parentheses, even when there's nothing for them to group. It adds noise to a program and forces countless extra keystrokes.

    Perhaps the rational is that, with method overloading, it's impossible to know if a method called without parentheses is a deliberate call without arguments, or a mistake. But in this case, why not assume the programmer knows what he or she is doing?

    While we're at it, why not remove the empty parentheses from method definition? Because it would cause confusion in the syntax?

    Surely there's no other place where we'd use curly brackets directly after a name.

    Java:
    String getName { return this.name; }


    The above can hardly be mistaken for anything other than a method definition.
  8. Why can't property access have syntactic sugar?

    So very many languages get it right that Java's "get*" and "set*" methods are a disgrace. Even the C and C++ derived C# gets this right.

    They add needless syntactic noise to a program and neglect the visual impact of the assignment operator.

    If I see:

    code:
    window.setTitle("hello");


    It certainly takes longer to read that and understand what's going on than it does if I have:

    code:
    window.title = "hello";


    The latter example has no superfluous "set" or parentheses obfuscating the purpose of the statement.
  9. Why can't methods be public by default?

    Certainly most methods in a class are public. Why then do they default to being private?

    Huffman coding principles say the most common code should be the most concise.

    Java:
    class Name
    {
       String first, last;

       Name(String f, String l)
       {
          first = f;
          last  = l;
       }

       String fullName()
       {
          return first + " " + last;
       }
    }


    Certainly that reads better than:

    Java:
    class Name
    {
       String first, last;

       public Name(String f, String l)
       {
          first = f;
          last  = l;
       }

       public String fullName()
       {
          return first + " " + last;
       }
    }


    There's less noise. Less to be confused about.
  10. Why do I need to use "return" so much?

    The "return" keyword is ultimately about control flow. It takes us from any given point in a method and skips right to the end, optionally yielding some value.

    Java:
    String fullName()
    {
       return first + " " + last;
    }


    Now look at this piece of code. Why do I need a "return"? I'm already at the end of the method. There's nowhere else to go.

    Java:
    String fullName()
    {
       first + " " + last;
    }


    There we go. We get to the end of the method, and there's a string. Hey... my method returns a string. Isn't that an incredible coincidence? Maybe my method should return this string.

    Less syntactic noise is good.

    But if I have a more complex method, "return" is clearly necessary, right?

    Java:
    String fullName()
    {
       if (first.equals(""))
       {
          return last;
       }
       else
       {
          return first + " " + last;
       }
    }


    Hmmm... actually, when I look at this, I realize something. The conditional is the last thing in the method. There's nowhere else to go.

    Java:
    String fullName()
    {
       if (first.equals(""))
       {
          last;
       }
       else
       {
          first + " " + last;
       }
    }


    That looks nicer, doesn't it?
  11. While we're prettying things up, what's with the semi-colon?

    The curly brace is a darn effective piece of punctuation. So why don't we use it?

    Java:
    String fullName()
    {
       if (first.equals(""))
       {
          last
       }
       else
       {
          first + " " + last
       }
    }


    Clearly the curly brace indicates the end of the block. The extra semi-colon didn't tell the compiler anything useful.
  12. Multiple methods... same darn thing.

    Now, at some point I'm going to want to override the toString method so my Name class plays nice with the rest of the API.

    I'm already cheating a bit by using my nicer versions of things.

    Java:
    class Name
    {
       String first, last;

       Name(String f, String l)
       {
          first = f;
          last  = l
       }

       String fullName
       {
          if (first.equals(""))
          {
             last
          }
          else
          {
             first + " " + last
          }
       }

       String toString
       {
          fullName
       }
    }


    Even with the prettied up version, I'm still jumping through artificial hoops. Clearly fullName and toString do the same darn thing.

    Java:
    class Name
    {
       String first, last;

       Name(String f, String l)
       {
          first = f;
          last  = l
       }

       String fullName, toString
       {
          if (first.equals(""))
          {
             last
          }
          else
          {
             first + " " + last
          }
       }
    }

  13. Why must parameter types be separately specified?

    So, when I declare variables, I can specify the type once, then a list of variable names.

    And yet, I can't do the same with parameters.

    I can remove more syntactic noise with:

    Java:
    class Name
    {
       String first, last;

       Name(String f, l)
       {
          first = f;
          last  = l
       }

       String fullName, toString
       {
          if (first.equals(""))
          {
             last
          }
          else
          {
             first + " " + last
          }
       }
    }


    There is no conflict, since a subsequent type declaration would start a new set of parameters.
  14. Why must cases fall through?

    The fact that cases fall through in Java is only to maintain syntactic and semantic compatibility with C and C++, which are themselves limited by hardware considerations. Of course, the Java environment doesn't have those limitations, so maintaining compatibility with that restriction is just ridiculous.

    Cases falling through is created to address a lack of another feature. Let's look at a contrived example. We want to return true if a number is 2, 4, 6 or 8, and false otherwise.

    Java:
    switch (number)
    {
       case 2:
       case 4:
       case 6:
       case 8:
          return true;
       default:
          return false;
    }


    Now, let's look at an alternate that poses no syntactic problems.

    Java:
    switch (number)
    {
       case 2, 4, 6, 8:
          return true;
       default:
          return false;
    }


    But since this switch statement doesn't fall through, there's no need for a control flow break to prevent fall-through. So, if this switch is alone in a function, then there's nowhere else the control flow can go, and we can avoid the returns.

    Additionally, we can use the braces as punctuation.

    Java:
    boolean checkNumber(int number)
    {
       switch (number)
       {
          case 2, 4, 6, 8: true;
          default: false
       }
    }


    The syntactic noise is significantly lessened.
  15. Why aren't naming conventions enforced?

    Java, for all of the other nits it has which I can pick, has a decent naming convention.

    That decent naming convention isn't enforced by the compiler.

    There's no good reason for this. It is done only to appease C++ programmers who want to write code that violates the conventions.
  16. How do I create a constant?

    Oh, that's easy.

    Java:
    final int i = 42;


    I can't give a new value to "i", right? So, it's constant.

    Therefore, the following shouldn't compile.

    Java:
    class Foo
    {
       String bar;

       public Foo(String initBar)
       {
          bar = initBar;
       }

       public String getBar()
       {
          return bar;
       }

       public String toString()
       {
          return getBar();
       }

       public void setBar(String newBar)
       {
          bar = newBar;
       }
    }

    public class Test
    {
       public static void main(String[] args)
       {
          final Foo f = new Foo("bar");
          System.out.println(f);
          wooble(f);
          System.out.println(f);
       }

       public static void wooble(Foo f)
       {
          f.setBar("baz");
       }
    }


    This shouldn't compile, right? I mean, "f" is clearly a constant Foo object.

    Yet, it does, and it runs perfectly well.

    You see, the "final" keyword merely means that the variable can't point to another value. This works fine for simple immutable data, like integers, but for an object with mutable state, it doesn't prevent changes to the object at all.

    When we designate data as immutable, we give the compiler extra information. In this case we're telling it to stop us if we try to violate that restriction and make changes to a piece of data. With large APIs, this can be done quite unintentionally.

    But Java offers us no ability to check for such problems when the program is compiled.

    Of course, to make this work, we'd also have to be able to mark methods as being valid to call on constant objects. The other option is to assume that any method which returns "void" has side-effects and thus cannot be called on a constant object.
  17. Non-void methods in a void context?

    That might sound odd, but you've all dealt with this. It's possible to have something like:

    Java:
    f.getBar();


    Which simply returns the "bar" field of the object "f". There's nothing stopping you from having that as-is in a Java program. It serves no purpose, yet the Java compiler does not warn about this or prohibit it.
  18. Java needs a high-priority cast.

    The sheer ugliness of this makes it a point against Java.

    Java:
    ((Foo)bar).baz()


    You'd think we could write:

    Java:
    (Foo)bar.baz()


    ... but that's low-priority, so it translates to:

    Java:
    (Foo)(bar.baz())


    Instead, here's the perfectly reasonable:

    Java:
    (bar as Foo).baz()


    As I've said many times, less syntactic noise is a good thing, and this kind of code is common enough to warrant attention.
  19. Why can't Java do deeper code analysis?


  20. Why is switch limited to integers?

    It's be a piece of cake for "switch" to allow comparison of pretty much any types, using either == for primitive types, or the "equals" method for object types. This could greatly simplify a lot of code, and it'd be relatively easy. It wouldn't even change how switch works currently, but instead just add functionality.

    Why hasn't this been done? Oh, right, to not make C++ programmers feel out of place.
  21. Why can't I write stand-alone functions?

    The "static" context is just silly. It confuses the heck out of many people and accomplishes nothing in terms of code re-use that couldn't be achieved with stand-alone functions and a proper module system, mix-ins or multiple implementation inheritance.

    It makes sense for languages where classes are themselves objects, and are treated as such. In such a language, "static" methods and field are simply non-static fields and methods of the class object.

    Certainly:

    Java:
    void main(String[] args)
    {
       Foo f = new Foo();
       System.out.println(f);
    }

    class Foo
    {
       public String toString()
       {
          return "Hello";
       }
    }


    Makes more sense than:

    Java:
    class Foo
    {
       public static void main(String[] args)
       {
          Foo f = new Foo();
          System.out.println(f);
       }

       public String toString()
       {
          return "Hello";
       }
    }


    Which makes no sense from an OO perspective.
  22. Speaking of mix-ins...

    Why not implement this powerful and simple mechanism for code reuse?

    One of the primary uses of static methods is to provide a class full of utility methods for use on various types of objects which all implement some interface. Just look at the Collections class for an example.

    Quote:
    This class consists exclusively of static methods that operate on or return collections. It contains polymorphic algorithms that operate on collections, "wrappers", which return a new collection backed by a specified collection, and a few other odds and ends.


    By and large, these methods take a single collection of some sort (Lists, Sets, etc.) as their first argument. I know I've seen this pattern before...

    Oh yes, in Python, where the "self" object is passed as the first argument to every member function in a class. These member functions act as methods.

    So it's not too hard to see something like:

    Java:
    Collections.sort(someList);


    As:

    Java:
    someList.sort();


    Much nicer, eh?

    Except, of course, "sort" isn't a method of the List class, so that won't work.

    Let's look at the way it works in another language. In this case, Ruby.

    I want to be able to sort anything that implements a particular means of iterating over its contents (let's call this an "interface"), but I don't want to have to write all of the code for each of these classes, especially since I know it's going to be the same for each and every one of them. It simply depends on that iteration scheme, and nothing else about the state of the object.

    So I have a class Array. Array objects have an "each" method which handles the iteration. I then "mix-in" the module Enumerable, and among other things, I get the implementation of a "sort" method.

    What about not wanting to add those methods to an entire class? Just want them added for a single object? That's easy enough. The result is singleton.

    Even C#, not the world's most innovative language, is implementing mix-ins, including singleton support, though Microsoft prefers to call them "extension classes".

    Why has Java ignored such a source of power? Why does the language rob its users of such power?

    There can be no good reason for such a profound lack.
  23. What happened to compile-time code analysis?

    Clearly, at compile-time we can look at the following and realize that only one String object has to be created. Since Strings are immutable, there's no harm in this.

    Yet, via the "==" operator, which tests for referential equality, we can see that two different String objects have been created containing the exact same contents.

    Java:
    class Test
    {
       static String foo = "hello world";
       static String bar = " ";
       static String baz = "hello" + bar + "world";

       public static void main(String[] args)
       {
          if (foo == baz)
             System.out.println("true");
          else
             System.out.println("false");
       }
    }


    The fact that this level of simple compile-time analysis doesn't happen is troubling.

    Of course, if we write the following, it shows that they do point to the same object.

    Java:
    class Test
    {
       static String foo = "hello world";
       static String baz = "hello world";

       public static void main(String[] args)
       {
          if (foo == baz)
             System.out.println("true");
          else
             System.out.println("false");
       }
    }


    Thus, essentially what's happening is that the compiler is waiting until run-time to perform the string concatenation that could easily have been done at compile-time.
  24. Why can't we do some type-inferencing?

    C#, a language which shares much with Java in terms of design, is gaining a limited form of type-inferencing. Why doesn't Java employ such capabilities to make programming easier?

    Compare:

    Java:
    BufferedReader keyboard = new BufferedReader(
       new InputStreamReader(System.in));


    With:

    Java:
    var keyboard = new BufferedReader(
       new InputStreamReader(System.in));


    The compiler can easily figure out at compile-time that "keyboard" is a BufferedReader instance. Why should I have to tell it explicitly?

Author:  rizzix [ Sat Oct 08, 2005 5:39 pm ]
Post subject: 

i hope you're feeling better now... Laughing

for the most part i'd agree with most of the stuff... but with a few exceptions:

#1) the syntax you proposed as an alternative approach in some cases was really ugly (it just dosent feel right, but yea i know it can be improved)

#2) Java's switch statement does integers __and__ Enums

#3) lists are unnecessary.. you can just as well use the Arrays.asList() function. It serves the purpose.

#4) instead of implementing mix-ins.. i believe it would be best to implement AOP directly into the language.

#5) i don't like the way c++ implements immutability (i,e a special keyword)... infact i believe it is best that annotations are used to represent that as well as the other things such as the access restriction of methods classes etc (i.e public, protected, so on..), after all all that falls under the category of Meta-data anyways.

#6) none of those arguments above justify for the amount of bashing that java has received from you,, here in compsci ... Laughing

Author:  wtd [ Sat Oct 08, 2005 5:50 pm ]
Post subject: 

rizzix wrote:
#3) lists are unnecessary.. you can just as well use the Arrays.asList() function. It serves the purpose.


Well, I can deal with backing it as arrays, lists, arraylists... whatever, but some literal form would be nice.

Author:  wtd [ Sat Oct 08, 2005 5:59 pm ]
Post subject: 

rizzix wrote:
#4) instead of implementing mix-ins.. i believe it would be best to implement AOP directly into the language.


Aspect-oriented programming is a somewhat ambiguous term.

Perhaps some type inferencing (deeper than what I described in my original post) is what you're looking for?

Kind of Ruby-esque duck-typing, but enforced at compile-time.

You may wish to look at O'Caml for an example of this combined with objects.

code:
$ ocaml
        Objective Caml version 3.08.2

# let foo bar = print_endline bar#baz;;
val foo : < baz : string; .. > -> unit = <fun>
# class wooble = object end;;
class wooble : object  end
# foo (new wooble);;
This expression has type wooble but is here used with type
  < baz : string; .. >
Only the second object type has a method baz
# class ninja = object method baz = "hello" end;;
class ninja : object method baz : string end
# foo (new ninja);;
hello
- : unit = ()
#

Author:  wtd [ Sat Oct 08, 2005 7:52 pm ]
Post subject: 

rizzix wrote:
#5) i don't like the way c++ implements immutability (i,e a special keyword)


Ironically the same keyword that Java has reserved but unused. Wink

And at least C++ has immutability. Smile

Author:  wtd [ Sat Oct 08, 2005 9:29 pm ]
Post subject: 

rizzix, I'd like to thank you for the reasonable response. I was hoping leaving out particularly hot issues like performance and operator overloading would encourage that kind of response. Smile

Author:  wtd [ Sat Oct 08, 2005 9:58 pm ]
Post subject: 

Let me add another thing to wish Java had.

No, it's not C++ preprocessor directives, but it does pretty much the same thing at a much higher level.

D's "static if" allows for compile-time decisions.

Author:  rizzix [ Sun Oct 09, 2005 12:48 am ]
Post subject: 

actually by AOP i was refering to AspectJ. i just think it should be an integrated part of java.

Author:  wtd [ Sun Oct 09, 2005 1:11 am ]
Post subject: 

I can see the DbC stuff being useful, but I would make it an integral part of the language. To additionally encourage the use of such a technique, I'd make it as easy as possible.

I think that perhaps forcing programmers to write out an "if" statement to evaluate a condition and throw an exception is making them work too hard. Consider Eiffel as an example of what I'm thinking of.

code:
foo(x : INTEGER) is
   require
      arg_too_small : x >= 42
   do
      std_output.put_integer(x)
      std_output.put_new_line
   end


Certainly debugging aspects (no pun intended) of it are important as well. I've always liked D's "debug" keyword which just makes it so easy.

code:
debug
{
   writefln("We're debugging!");
}

debug (4) // we can have numbers to represent different debugging levels
   writefln("We can have the debug line apply to just one statement");

debug (hello):
   // we can have string labels for controlling debug blocks,
   // and the debug section can extend to the end of the current block

Author:  wtd [ Sun Oct 09, 2005 1:16 am ]
Post subject: 

For wrapping methods with pre and post actions... the pattern matching capabilities of AspectJ are interesting. Without them it'd certainly be tedious to have the same pre or post action for several different methods.

Author:  wtd [ Sun Oct 09, 2005 1:18 am ]
Post subject: 

I see little widespread future support for something like AspectJ, though, unless they dramatically improve the documentation. It's decent enough, but they go way overboard on the buzzwords. PHBs may love it, but programmers won't.

Author:  wtd [ Sun Oct 09, 2005 1:58 am ]
Post subject: 

Some Python code to tease your AOP-oriented mind. Smile

code:
>>> def pre(pre_f):
...    def decorate(f):
...       def x(*args, **kwds):
...          pre_f()
...          f(*args, **kwds)
...       x.__name__ = f.__name__
...       return x
...    return decorate
...
>>> def yo(): print "yo"
...
>>> @pre(yo)
... def hello(): print "hello"
...
>>> hello()
yo
hello
>>> hello.__name__
'hello'
>>>

Author:  wtd [ Sun Oct 09, 2005 2:12 am ]
Post subject: 

Also fun. Smile

code:
>>> def require(*types):
...    def decorate(f):
...       def x(*args, **kwds):
...          for n, (type_name, arg) in enumerate(zip(types, args)):
...             if not isinstance(arg, type_name):
...                raise TypeError("Type mismatch on arg %d.  Should be %s but was %s." % (n + 1, str(type_name), str(type(arg))))
...          return f(*args, **kwds)
...       x.__name__ = f.__name__
...       return x
...    return decorate
...
>>> @require(int, int)
... def foo(a, b):
...    return a + b
...
>>> foo("hello", "foo")
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "<stdin>", line 6, in x
TypeError: Type mismatch on arg 1.  Should be <type 'int'> but was <type 'str'>.
>>> foo(1, 2)
3
>>>

Author:  Naveg [ Sun Oct 09, 2005 12:27 pm ]
Post subject: 

wtd wrote:
leaving out particularly hot issues like performance and operator overloading


I don't completely understand this, but I think it talks about how poor java performance is an abused myth in some respects. Take a look.\

http://www-128.ibm.com/developerworks/java/library/j-jtp09275.html?ca=dgr-lnxw01JavaUrbanLegends

Author:  wtd [ Sun Oct 09, 2005 12:31 pm ]
Post subject: 

Yes, it does.

That's why I chose not to complain about Java's performance. I think there's enough to complain about with respect to the language, without touching the JVM.

Author:  rizzix [ Sun Oct 09, 2005 1:00 pm ]
Post subject: 

actually the jvm is ingeniously designed.. it can actually support all sorts of various syntax(es) very efficiently.. that is many different kinds of langauges can be implemented to run under the jvm.

SUN's jvm is fast. it's close to C in performance and at rare times it can even beat C. there really shouldn't be any complaints about the jvm though.. cuz the all the jvm is required to do is parse bytecode.. how it does it is up to the implementor.

as for operator overloading. Oh hell No. that's soo anti-java. Twisted Evil

Author:  wtd [ Sun Oct 09, 2005 1:06 pm ]
Post subject: 

rizzix wrote:
as for operator overloading. Oh hell No. that's soo anti-java.


It's just syntax sugar that makes code easier to work with.

Yes, it can be abused, but "with great power comes great responsibility". I think I'd rather have the power and take my chances on the responsibility. Smile

Author:  wtd [ Sun Oct 09, 2005 1:11 pm ]
Post subject: 

As for supporting multiple languages...

The only problem with that idea is that you have to support only a restricted subset of what different languages are capable of. If you support "exotic" features, you may have one language create code that another cannot understand.

But the whole reason many programming languages exist is that there's more than one way to get things done, and some programming languages offer features that make some/all tasks easier.

If you require adherence to one set of capabilities, you invariably bias the community towards a single implementation of those features.

I worry about this a bit with Parrot, but am reassured since the languages targetting it are generally speaking all very high-level and support a wide range of capabilities.

Author:  rizzix [ Sun Oct 09, 2005 1:14 pm ]
Post subject: 

ehm... what i meant is that the JVM can support a large variety of languages (and quite efficiently).. just cuz of the way it's designed (to parse bytecode).. it's quite remarkable.

Author:  rizzix [ Sun Oct 09, 2005 1:20 pm ]
Post subject: 

wtd wrote:
Yes, it can be abused, but "with great power comes great responsibility". I think I'd rather have the power and take my chances on the responsibility. Smile
I beleive it's best not to bloat the language.. keep it simple.. and coding will be done efficiently.

Author:  wtd [ Sun Oct 09, 2005 7:33 pm ]
Post subject: 

rizzix wrote:
ehm... what i meant is that the JVM can support a large variety of languages (and quite efficiently).. just cuz of the way it's designed (to parse bytecode).. it's quite remarkable.


Well, the JVM is essentially just a CPU in software. That compilers can be written which turn other programming languages into JVM bytecodes is no more surprising than that one can create native executables for physical CPUs in a number of widely differing programming languages.

The difficulty is interoperability.

If I write a program in Ruby that defines a module, and a series of classes, and mixs that module in, yes, I can compile that to the JVM and have it run and give me the result I expected.

But, can I use that code in Java code? How does the concept of mix-ins map to the Java programming language which has no such concept? Smile

Author:  rizzix [ Sun Oct 09, 2005 7:59 pm ]
Post subject: 

simple... turn those mix-ins into objects.. of a class called let say "Mixin".. now whether u use it or not in java is not important.. but it's now usable in both languages.. Ruby would just have a special syntax-sugar to it.

Author:  wtd [ Sun Oct 09, 2005 8:11 pm ]
Post subject: 

There would be no meaningful way to implement mixins as objects. Mix-ins add another is-a relationship to the object model.

code:
$ irb
irb(main):001:0> class Foo
irb(main):002:1>    def each
irb(main):003:2>       yield 42
irb(main):004:2>       yield 65
irb(main):005:2>    end
irb(main):006:1> end
=> nil
irb(main):007:0> class Foo
irb(main):008:1>    include Enumerable
irb(main):009:1> end
=> Foo
irb(main):010:0> Foo.new.is_a? Enumerable
=> true
irb(main):011:0> Foo.new.sort.reverse
=> [65, 42]


I demonstrate in Ruby just because Ruby happens to make mix-ins absurdly easy.

If you can't support them in Java, then there's no reason for anyone targetting the JVM to use them in their Ruby code. At that point you've lost one of Ruby's most important features, and one of the more convincing arguments for not just using Java.

In the end, I can't help but think that such limitations will make Java remain the dominant language on the JVM, and close most minds to alternative languages. Which is a shame, since being open-minded is the only way to make progress.

Author:  wtd [ Mon Oct 10, 2005 12:13 pm ]
Post subject: 

I suppose uou could model an entire Ruby environment as an object, but that doesn't make two languages equal peers.

Author:  rizzix [ Mon Oct 10, 2005 4:22 pm ]
Post subject: 

what are you talking about? AspectJ does it (but in a more typesafe manner).. why can't it be done otherwise.. geez.

Author:  wtd [ Mon Oct 10, 2005 6:43 pm ]
Post subject: 

rizzix wrote:
what are you talking about? AspectJ does it (but in a more typesafe manner).. why can't it be done otherwise.. geez.


AspectJ adds an additional "is-a" relationship to the object model?

I didn't see that in my research.

Author:  rizzix [ Mon Oct 10, 2005 6:50 pm ]
Post subject: 

yes through interfaces Wink

Author:  wtd [ Mon Oct 10, 2005 7:15 pm ]
Post subject: 

I'm quite aware of interfaces. But interfaces and mix-ins, while similar to some extent, are ultimately very different.

An interface abstracts all implementation details away, expecting the implementing class to write it all.

A mix-in, on the other hand can be used when one realizes the difference in implementation lies at a higher level. Thus a set of methods can be identically written, and depend only on the difference in implementation of a single or a few method(s). You get the implementation of all of the methods, so that

Something like the way an abstract class works in Java, but with the ability to use one or more as a base.

Author:  rizzix [ Mon Oct 10, 2005 7:25 pm ]
Post subject: 

yes.. but what i'm saying is you implement the interface.. and inject the code through aspectJ.. anyways.. but the point of the converstion is that mix-ins is very much possible in java.. and it will be compatible with the Java language.. so long as the mechanism involved in implementing the mix-in ensures that it implements the respective interface(s). thus defining the respective Type (and ensuring it's compatible with the Java lang)

Author:  wtd [ Mon Oct 10, 2005 7:28 pm ]
Post subject: 

Care to demonstrate an example of this?

I would find it genuinely interesting.

Author:  rizzix [ Mon Oct 10, 2005 7:33 pm ]
Post subject: 

ehm? how am i to do that?... i actually don't think you understood me.. when i said that mix-ins was possible in Java i was talking about the java platform.. (the jvm).. then i further went on describing how it can be made compatible with java "lang".... i.e the mechanism involved in implementing the mix-in also ensures to implement the respective interface..

and i said that you can mimic such behaviour in java (the lang).. using aspectj yea.. but it's just the same thing as implementing the interfaces and writing delegate methods to the class in question.. (well in effect anyways).. well basically your gool old wrapper class technique.

Author:  Martin [ Mon Oct 10, 2005 7:56 pm ]
Post subject: 

I remember in my CS134 class when they were talking about the features of Java and they listed (as features) that it didn't support operator overloading or multiple inheritance.

I have to say, Java's kind of boring to program in. If I want something similar, I'd go with C++ instead (PLEASE, WE NEED A PREPROCESSOR (or something similar)). Or for fun, I'd go with Perl. Or Scheme. Or Ruby. Nah, just Perl.

Author:  rizzix [ Mon Oct 10, 2005 8:01 pm ]
Post subject: 

operator overloading isin't all that cool.. so you took fancy for a new syntax... but just look at how it has been abused in C++... i see no point to it..

java isin't boring to program in.. specially when ur more worried about getting the job done rather than the crazy leet features that the language has in store for you..

i like java for what it is (i.e. simple).. i hate languages that are bloated.. (especially c++)

actually in that respect, even java has it's flaws.. but its much better than the rest.


PS: but when i'm in the mood of using the language for the sake of "features" i'm all ready for Perl6. Wink Nevertheless all my serious programming is only done in java

Author:  Martin [ Mon Oct 10, 2005 8:10 pm ]
Post subject: 

I'll give you that Java is simple, but really, operator overloading wouldn't be a bad thing. Yes, it'd let you write gross(er?) Java code, but you can do that anyway without it.

I don't see how C++ is bloated compared to Java though.

Author:  rizzix [ Mon Oct 10, 2005 8:20 pm ]
Post subject: 

Martin wrote:
I'll give you that Java is simple, but really, operator overloading wouldn't be a bad thing. Yes, it'd let you write gross(er?) Java code, but you can do that anyway without it.
what's the point of encouraging bad code? keep in mind that after operator overloading.. the code can literally get unreadable.. otherwise the worst it could get is "hard to read"

Martin wrote:
I don't see how C++ is bloated compared to Java though.
how can you NOT.. it's filled with useless grabage: direct raw-multiple inheritance, operator overloading, preprocessor directives, object-by-value, typedefs, structs, the void*, unions, bitfields, two different notations for initializations, awkward class member initialization rules, awkward template notations, implicit conversion (as in when you implement a conversion constructor, or whatever it's called), non-virtual methods, the extern keyword (which is actually completly redundant), static variables in methods, static file-scope methods (once agian it's completly redundant)...

and within it's operator overloading stuff you can actually overload the casting operator, the dereferencing operator, and even the new and delete operator... ack! ....total bloat! and heck yea there's a lot more..

Author:  Martin [ Mon Oct 10, 2005 8:47 pm ]
Post subject: 

Like I said, you can write bad code without operator overloading too.

In Java it's perfectly valid for me to give all of my classes and functions single letter names and write everything in one long line of code without comments. Bad code? Yes. Unreadable? Yes. Do you think that Java should stop that too? I don't.

Yeah, you can write bad code with operator overloading, but it can also make code a lot easier to read and a lot more intuitive too. It all depends on the developer. You can overload casting so that you can create say, an Integer class and have it so that it can be cast to an int. Hmm...

And you're calling the preprocessor and typedef useless? Are you kidding me? Structs are useless? Huh? void* useless? I'm not really following you here...

Author:  rizzix [ Mon Oct 10, 2005 9:02 pm ]
Post subject: 

Martin wrote:
In Java it's perfectly valid for me to give all of my classes and functions single letter names and write everything in one long line of code without comments. Bad code? Yes. Unreadable? Yes. Do you think that Java should stop that too? I don't.
Actually i think it should.. But how the hell can you ensure the programmer writes meaningful names..? besides when the programmer starts writting Japaneese or chineese character methods.. then it's a whole other story.. hence it's best the way it is..

Martin wrote:
Yeah, you can write bad code with operator overloading, but it can also make code a lot easier to read and a lot more intuitive too. It all depends on the developer. You can overload casting so that you can create say, an Integer class and have it so that it can be cast to an int. Hmm...

And you're calling the preprocessor and typedef useless? Are you kidding me? Structs are useless? Huh? void* useless? I'm not really following you here...
what can't you follow? it's useless.. or it simply clashes with other more dominating features... and void* only encourages bad code..

as for preprocessoer directive.. please.. it is soo totally pointless.. use inlines if you have to.. but seriously those perprocessor macros are useless.

Author:  wtd [ Mon Oct 10, 2005 10:50 pm ]
Post subject: 

rizzix wrote:
Martin wrote:
Yeah, you can write bad code with operator overloading, but it can also make code a lot easier to read and a lot more intuitive too. It all depends on the developer. You can overload casting so that you can create say, an Integer class and have it so that it can be cast to an int. Hmm...

And you're calling the preprocessor and typedef useless? Are you kidding me? Structs are useless? Huh? void* useless? I'm not really following you here...
what can't you follow? it's useless.. or it simply clashes with other more dominating features... and void* only encourages bad code..

as for preprocessoer directive.. please.. it is soo totally pointless.. use inlines if you have to.. but seriously those perprocessor macros are useless.


Preprocessor directives are a bad thing, but that's an issue of implementation, not a condemnation of the idea entirely.

As mentioned, look at D's static if.

Instead of something like (yes, incredibly simple):

code:
#ifdef 42 < 56

#else

#endif


You might have:

code:
static if (42 < 56)
{

}
else
{

}


The difference is deeper than syntax. In the former, we simply perform text manipulations on the source code without any regard to the semantics of the programming language.

Additionally, macros can be incredibly valuable, but they should be implemented at a higher level than text substitution. See Dylan's macros for an excellent example.

Author:  rizzix [ Tue Oct 11, 2005 1:55 pm ]
Post subject: 

yea static ifs can be usefull for languages like C++.. but they are not of much use in java..

Author:  wtd [ Tue Oct 11, 2005 5:09 pm ]
Post subject: 

Are you certain? More compile-time evaluation could be a very good thing for Java.

Author:  rizzix [ Tue Oct 11, 2005 5:44 pm ]
Post subject: 

yes... but static ifs? i can't see how that can be of much use.

Author:  wtd [ Tue Oct 11, 2005 6:03 pm ]
Post subject: 

Allowing compile-time resolution of platform-dependent issues, rather than forcing them to be evaulated at run-time? Admittedly, platform-dependencies should be avoided, but for optimization purposes they cannot always be.

Author:  rizzix [ Wed Oct 12, 2005 1:03 am ]
Post subject: 

ehm... distributing source files is less a fad in java than it is in c++... in java it's preferable to just distribute the .class files and the javadocs that come along with it.. (the sources may also be distribute optionally if it's opensource.. but no one is exptected to recompile the software to just run in on the different platform..)

permiting static ifs only break java's concept of Compile once Run Anywhere..

how platform-specific issues are resolved in java:
native or platoform specific stuff is distributed separatly from the primary .jar file. since the code is designed from the ground up to be polymorphic... the sytem simply works.. (for a good example look at the JOGL library of java)

we just work differently.. get used to it.. we prefer good design over unnecessary bloat.. don't try to change the language when it's already proved to be quite successful.. in it's own little way.

Author:  wtd [ Wed Oct 12, 2005 1:09 am ]
Post subject: 

rizzix wrote:
permiting static ifs only break java's concept of Compile once Run Anywhere..


I'm pretty sure J2ME did that perfectly well all by itself. Wink

Author:  wtd [ Wed Oct 12, 2005 7:58 pm ]
Post subject: 

I'd like to add continuations to the list of features that would make Java suck less.

Author:  rizzix [ Thu Oct 13, 2005 1:08 pm ]
Post subject: 

continuations in java can be handled through design... as an example check out the Dalma project

hence there's no need for a special syntax... etc.

Author:  wtd [ Thu Oct 13, 2005 1:12 pm ]
Post subject: 

Well, my view is that it should be exposed at the language level, rather than the library level. Having to deal with Yet Another API just doesn't encourage the use of continuations the same way a simple "yield" keyword does. Smile

Author:  rizzix [ Thu Oct 13, 2005 1:18 pm ]
Post subject: 

oh but it will if the JCP (java community process) accepts it into the Standard API. But for that to happen they need to propose to add it into the API.. as did Beanshell.org.

Author:  wtd [ Thu Oct 13, 2005 1:32 pm ]
Post subject: 

Will it be implemented as smoothly as it is in something like Python or Ruby, where programmers make great use of continuations... likely without ever realizing it? Smile

Imagine if reading a file were as easy as...

Java:
for (String line : fileHandle.readLines())
{
   // ...
}


...and this didn't involve the method simply returning a collection. After all, if the file is large enough, that collection could take up absurd amounts of memory. A continuation based approach would allow the file to be read one line at a time. Sounds crazy, doesn't it?

Python:
for line in file_handle:
   ...

Author:  wtd [ Thu Oct 13, 2005 8:41 pm ]
Post subject: 

Revisiting anonymous inner classes, I'd like to mention something, and in all fairness there may be some (I suspect it would be awkward) means of accomplishing it with the current language.

I've oft wondered how Java would handle the situation where you would want to use an anonymous inner class, but also want to inherit from a class. Or perhaps you want to implement more than one interface.

I wonder because O'Caml makes this relatively easy, at least as of 3.08.

Author:  wtd [ Fri Oct 14, 2005 3:40 am ]
Post subject: 

On the subject of simplicity in Java...

Why not simplify conditionals and loops by requiring curly braces?

Java:
for (int i = 0; i < 10; i++)
   if (i % 2 == 0)
      System.out.println(i);


Becomes illegal. Replace it with:

Java:
for (int i = 0; i < 10; i++)
{
   if (i % 2 == 0)
   {
      System.out.println(i);
   }
}


This would fit more consistently with the syntax for try...catch...finally constructs.

Author:  rizzix [ Fri Oct 14, 2005 10:36 am ]
Post subject: 

on the other hand i think it's even better if try-catch-final (and method definitions) permitted a single statement..

Author:  wtd [ Sat Oct 15, 2005 7:25 pm ]
Post subject: 

rizzix wrote:
on the other hand i think it's even better if try-catch-final (and method definitions) permitted a single statement..


That'd be reasonable, but seemingly contradictory to your desire to keepthe language simple. Wink

If you were to have methods with a single statement/expression... would you still require a "return"?

code:
int foo() return 42;


code:
int foo() 42;


Hmmm...

code:
Arrays.sort(objArray, new Comparator<SomeClass>()
   public int compare(SomeClass o1, SomeClass o2)     
      return o1.someGetter().compareTo(o2.someGetter())
)


Smile

Author:  rizzix [ Sat Oct 15, 2005 7:35 pm ]
Post subject: 

ic..

Author:  Ultra Jugulator [ Mon Oct 24, 2005 10:13 pm ]
Post subject: 

Well, it's my first year studying CompSci and Java is what I am learning. There are things that I am noticing in this programming language that makes me feel not really using it. The more I advance and learn from it, the more details I find. Confused

But it's like everything else, you obtain advantages and disadvantages.
I haven't seen perfect programming language yet. 8)

Besides, would any of you recommend any other better programming language? Question

Author:  1of42 [ Mon Oct 24, 2005 10:40 pm ]
Post subject: 

Psh, if you give him the chance, wtd will do nothing but recommend other programming languages.

Author:  [Gandalf] [ Mon Oct 24, 2005 10:44 pm ]
Post subject: 

Now, I'm going to have to use some quotes here... first, I take this quote from wtd (as I remember it): "The more programming languages you learn, the more you realize they all suck."

Some languages that might be recommended to you are:
O'Caml, Ruby, Haskell, Perl, Python...

Another quote (from somewhere): "The more you learn, the more you realize you don't know."

*edit* Also, please make your avatar smaller so that it does not interfere with the frames of the forums.

Author:  wtd [ Mon Oct 24, 2005 10:50 pm ]
Post subject: 

Ultra Jugulator wrote:
But it's like everything else, you obtain advantages and disadvantages.
I haven't seen perfect programming language yet. 8)


Keep in mind that "Java" is three things. It's a virtual machine, a library, and a language. I'm addressing failings in the language component.

Ultra Jugulator wrote:
Besides, would any of you recommend any other better programming language? Question


Keeping in mind that a language recommended in place of Java should be functionally comparable, the list of options I would raise is somewhat limited. I would tend to require that replacements be capable of object-oriented programming in something other than a hack-ish fashion.

If static typing is vitally important, I would wholeheartedly recommend O'Caml. It's a fantastic language and address most of these shortcomings with the Java language.

Also in the static typing field, I'd recommend D and Dylan as superior programming languages, though their tools could use some serious help.

C# suffers from many of the problems which plague Java, but also improves on several points... especially C# 3.0. Just watch out for Microsoft lock-in. You may wish to use the open source C# tools, even if that means being slightly behind the Microsoft tools in terms of support for cutting edge C# features. (Martin: am I completely biased against Microsoft? Smile )

Eiffel is a fantastic statically-typed object-oriented programming language.

If dynamic typing is ok, I'd highly recommend Ruby. Aside from that I'd advance Python and gladly say both are superior languages to Java.

Author:  Ultra Jugulator [ Tue Oct 25, 2005 2:56 pm ]
Post subject: 

Thanks for the info, guys.

Very Happy

Author:  rizzix [ Tue Oct 25, 2005 5:03 pm ]
Post subject: 

oh btw i should also mention these shortcommings are really not so big a deal.. you can program just as well with them as you would without them..

Author:  Mr. T [ Wed Oct 26, 2005 2:50 am ]
Post subject:  Alex's Opinion

Ya, Turing's pretty solid too, as far as object orientation goes. I mean Mac-OOT; the name says it all. Drunk Hit Wall

Author:  rizzix [ Wed Oct 26, 2005 9:20 am ]
Post subject: 

No, actually turing is not so solid a far as Object Oriented programming goes..

Author:  Mr. T [ Wed Oct 26, 2005 11:48 pm ]
Post subject:  Alex's Opinion

I was being sarcastic...I thought the emoticons and my weak argument would give that away. Rolling Eyes Silly

Author:  rizzix [ Thu Oct 27, 2005 1:30 pm ]
Post subject: 

ah..

Author:  CloudOnFIre [ Mon Feb 20, 2006 8:39 am ]
Post subject:  Why Java does not suck

1. It just does not

This is mainly because you are an overrated bafoon. Your ackward behaviour results in certain unrelated actions from your overestimated mental status. And that fact that my response is not as lengthy as your rambling on about certain procedures and malious behaviours within the program.

Martin says.............
Holy banned, Batman!
Nobody likes you. Stop wasting our time. Watch the step on the way out, and maybe take an English course or two when you get to highschool. (search for this user's previous posts)

Author:  [Gandalf] [ Mon Feb 20, 2006 8:50 pm ]
Post subject:  Right...

1. Not only is your post offensive in nature, you are also reviving an old topic with no true input to add. This just might be ignorable, but looking at your previous posts...

2. I wasn't aware that "bafoon", "ackward", and "malious" were words...

How about saying something intelligent next time? If there is a next time...

Author:  Martin [ Tue Feb 21, 2006 1:55 am ]
Post subject:  Re: Right...

[Gandalf] wrote:
How about saying something intelligent next time? If there is a next time...


Yeah, I'm not so sure about that next time thing happening.

Author:  wtd [ Tue Feb 28, 2006 2:15 pm ]
Post subject: 

A fantastic article pertinent to this thread.

http://opal.cabochon.com/~stevey/sokoban/docs/article-java.html

Author:  rizzix [ Mon Mar 06, 2006 9:10 pm ]
Post subject: 

That article sounds soo biased.. They way he writes even the good points sound like he's just stating bad points.

Author:  Krabjuice [ Wed Apr 05, 2006 8:47 pm ]
Post subject: 

Question: Why does Java suck?
The answer is obvious: Holt.

Correction:
The answer is obvious: People like me.

Author:  Aziz [ Tue Sep 05, 2006 8:13 am ]
Post subject: 

wtd wrote:
# Why can't functions return multiple values?

Yeah yeah... in Java they're called "methods".

Why can't they return multiple values?

Because C and C++ can't isn't a good reason, but it's the one that we're given. Instead we have to add extra classes to the library, or return a list.

That second option seems nice, but it means we have to create a list (using the tedious syntax listed above), return it, assign that return value to an array or list variable, then manually grab each element in that list and assign it to some other variable.

What's wrong with being able to just return more than one value?

Python:
def foo():
return (1, 2, 3)

a, b, c = foo()


Remember when you said if the language doesn't have a feature, add it yourself? I know this is a little bit extra, but it's simple:

Java:
public class Tuple<A,B>
{
    public A a;
    public B b;
   
    public Tuple()
    {
       
    }
   
    public Tuple(A a, B b)
    {
        this.a = a;
        this.b = b;
    }
}


and a simple test:

Java:
public class TestTuple
{
    public static void main(String[] args)
    {
        Tuple<String, String> test = testTuple();
       
        Tuple<String, String> test2 = new Tuple<String, String>();
       
        test2.a = "Foo";
        test2.b = "Bar";
       
        System.out.println(test.a);
        System.out.println(test.b);
       
        System.out.println(test2.a);
        System.out.println(test2.b);

    }
   
    public static Tuple<String, String> testTuple()
    {
        return new Tuple<String, String>("FOOZ", "BAZZER");
    }
}


outputs:

code:
FOOZ
BAZZER
Foo
Bar

Author:  wtd [ Tue Sep 05, 2006 12:15 pm ]
Post subject: 

And if you want a tuple that contains three values? Four values? Five, six, seven, more? Smile

Author:  Null [ Tue Sep 05, 2006 3:47 pm ]
Post subject: 

Your argument stops attacking Java and starts asking why every language like it doesn't behave exactly like Lisp or Ruby. Not that there is a problem with that, but your title and intention is a bit misleading (in my opinion, anyways).

Different languages have different purposes. For example, one would not want C++ to have the extra overhead of dynamic typing.

Author:  Aziz [ Tue Sep 05, 2006 5:44 pm ]
Post subject: 

Null wrote:
Your argument stops attacking Java and starts asking why every language like it doesn't behave exactly like Lisp or Ruby. Not that there is a problem with that, but your title and intention is a bit misleading (in my opinion, anyways).

Different languages have different purposes. For example, one would not want C++ to have the extra overhead of dynamic typing.


Example, each language has its own perks and uses for different jobs. Java has its pluses as does any language. It probably doesn't return multiple values for the sake of organization. With only returning one value you can be sure you're not going to mix the two up, and same with multiple inheritence. Sure, there's ways to handle it, but Java is Java, and if it was like all the other languages then it wouldn't be java it'd simply be C++ or Ruby or O'Caml, there would be no need for a different type of language. Everyone has there own opinion of what the perfect language is (and the multitude of available languages provides access to the ideal tool for a job, sure a drill is a very effecient tool put not when you need to weld).

And idea wtd . . . make a "The perfect language" topic and devise everything that would make a programming language perfect. Then.....make it. I'd like to see how that turned out Smile wtd language.

Author:  fenixconnexion [ Thu Apr 12, 2007 7:30 pm ]
Post subject:  RE:Why Java sucks

wow i agree of alot of what you're saying, but it's better than turing!

Author:  wtd [ Fri Apr 13, 2007 3:47 pm ]
Post subject:  Re: RE:Why Java sucks

fenixconnexion @ Fri Apr 13, 2007 8:30 am wrote:
wow i agree of alot of what you're saying, but it's better than turing!


Not a particularly fantastic achievement.

Author:  PaulButler [ Fri Apr 13, 2007 5:39 pm ]
Post subject:  Re: RE:Why Java sucks

wtd @ Fri Apr 13, 2007 3:47 pm wrote:
fenixconnexion @ Fri Apr 13, 2007 8:30 am wrote:
wow i agree of alot of what you're saying, but it's better than turing!


Not a particularly fantastic achievement.


Laughing

Since this thread has been resurrected, here's my take: Java could be better, but it doesn't suck. In terms of the easy-to-code factor, Java does quite well. I would rather do a coding competition in Java than C/C++ any day. Also, I have yet to find an IDE I like as much as Eclipse, but it could be that I haven't been looking much. The CDT plugin is good for C/C++, but it is not as good as the native java support.

Author:  ericfourfour [ Fri Apr 13, 2007 7:40 pm ]
Post subject:  Re: RE:Why Java sucks

PaulButler @ Fri Apr 13, 2007 5:39 pm wrote:
I have yet to find an IDE I like as much as Eclipse

You should try NetBeans. It has a c/c++ plugin and it is getting support for ruby in 6.0.

Author:  bugzpodder [ Fri Apr 13, 2007 10:12 pm ]
Post subject:  Re: Why Java sucks

i dont see why java is compared to c++... they have similar syntax anyways. and i dont see how coding competition have anything to do with lang comparisons

Author:  wtd [ Sat Apr 14, 2007 1:40 am ]
Post subject:  Re: RE:Why Java sucks

PaulButler @ Sat Apr 14, 2007 6:39 am wrote:
wtd @ Fri Apr 13, 2007 3:47 pm wrote:
fenixconnexion @ Fri Apr 13, 2007 8:30 am wrote:
wow i agree of alot of what you're saying, but it's better than turing!


Not a particularly fantastic achievement.


Laughing

Since this thread has been resurrected, here's my take: Java could be better, but it doesn't suck. In terms of the easy-to-code factor, Java does quite well. I would rather do a coding competition in Java than C/C++ any day.


Again, not a stellar achievement.

I was not particularly thinking of C and C++ when I found shortcomings in Java. Smile

Author:  wtd [ Sat Apr 14, 2007 1:41 am ]
Post subject:  Re: Why Java sucks

bugzpodder @ Sat Apr 14, 2007 11:12 am wrote:
i dont see why java is compared to c++...


Perhaps because Java was explicitly created to appeal to C++ programmers, by programmers with a strong fondness for C.

Author:  PaulButler [ Sat Apr 14, 2007 6:09 pm ]
Post subject:  Re: RE:Why Java sucks

ericfourfour @ Fri Apr 13, 2007 7:40 pm wrote:
PaulButler @ Fri Apr 13, 2007 5:39 pm wrote:
I have yet to find an IDE I like as much as Eclipse

You should try NetBeans. It has a c/c++ plugin and it is getting support for ruby in 6.0.


Cool, I didn't realize that NetBeans has a C/C++ plugin. I've played with NetBeans and the mobile Java plugin, and I like it. I will check out the C++ plugin.

bugzprodder wrote:
i dont see why java is compared to c++... they have similar syntax anyways. and i dont see how coding competition have anything to do with lang comparisons


The majority of software developed in the last several decades has been in C or C++. They may have some syntax in common (as most curly-bracket languages do), but they are two very different languages.

My point about the programming competitions was that it is faster to code in Java than C++ since you don't have to worry about memory management, and you have access to lots of pre-made classes. This could be a bad thing for performance reasons, but if your goal is to create a program quickly, Java is a better choice than C++. Programming competitions aren't the only time you have to create code quickly, it was just an example. Of course, I am biased, because I have done more Java. Also, I may be biased to the different IDEs that are available (Eclipse > Eclipse w/CDT > Dev C++) which shouldn't matter if we are just discussing the merits of the language.

wtd wrote:

Again, not a stellar achievement.

I was not particularly thinking of C and C++ when I found shortcomings in Java. Smile


Yeah, most/all of the shortcomings you found apply to C++ as well. Maybe you should make a list of "Languages wtd prefers to Java/C++"... I know you like O'Caml, Scala, Haskell, etc. but a nice list would be handy for when I'm in the mood to try a new language.

Author:  wtd [ Sat Apr 14, 2007 10:07 pm ]
Post subject:  RE:Why Java sucks

COnsider also dynamically-typed languages.

Ruby, Io, Smalltalk...

Author:  Andy [ Sat Apr 14, 2007 10:13 pm ]
Post subject:  Re: RE:Why Java sucks

PaulButler @ Sat Apr 14, 2007 4:09 pm wrote:

My point about the programming competitions was that it is faster to code in Java than C++ since you don't have to worry about memory management, and you have access to lots of pre-made classes. This could be a bad thing for performance reasons, but if your goal is to create a program quickly, Java is a better choice than C++. Programming competitions aren't the only time you have to create code quickly, it was just an example. Of course, I am biased, because I have done more Java. Also, I may be biased to the different IDEs that are available (Eclipse > Eclipse w/CDT > Dev C++) which shouldn't matter if we are just discussing the merits of the language.


err ever heard of STL? I really doubt it takes longer to write algorithms in C++ than Java. Besides, the majority of time is used on developing the alogirthm, not coding it. Most competition solutions are only a couple of lines long.

Author:  wtd [ Sat Apr 14, 2007 10:19 pm ]
Post subject:  RE:Why Java sucks

If you have the STL then you don't have to do any work. Or at least not outside of main.

Author:  PaulButler [ Sun Apr 15, 2007 9:24 am ]
Post subject:  Re: RE:Why Java sucks

Andy @ Sat Apr 14, 2007 10:13 pm wrote:
PaulButler @ Sat Apr 14, 2007 4:09 pm wrote:

My point about the programming competitions was that it is faster to code in Java than C++ since you don't have to worry about memory management, and you have access to lots of pre-made classes. This could be a bad thing for performance reasons, but if your goal is to create a program quickly, Java is a better choice than C++. Programming competitions aren't the only time you have to create code quickly, it was just an example. Of course, I am biased, because I have done more Java. Also, I may be biased to the different IDEs that are available (Eclipse > Eclipse w/CDT > Dev C++) which shouldn't matter if we are just discussing the merits of the language.


err ever heard of STL? I really doubt it takes longer to write algorithms in C++ than Java. Besides, the majority of time is used on developing the alogirthm, not coding it. Most competition solutions are only a couple of lines long.


I guess I am just biased to Java because I have used it more. The more I think about it, my preference for Java over C++ for competitions is because of IDE features, not the languages themselves.

Heh, I never thought I'd be defending Java.

wtd, dynamically typed languages are great and I love Ruby, but isn't the performance worse than a statically typed language? I guess in most cases it wouldn't matter, but recently I have been doing things like rendering fractals and factoring numbers, which need good performance.

Author:  wtd [ Sun Apr 15, 2007 11:06 am ]
Post subject:  Re: RE:Why Java sucks

[quote="PaulButler @ Sun Apr 15, 2007 10:24 pm"][quote="Andy @ Sat Apr 14, 2007 10:13 pm"]
PaulButler @ Sat Apr 14, 2007 4:09 pm wrote:

wtd, dynamically typed languages are great and I love Ruby, but isn't the performance worse than a statically typed language?


Not necessarily. There are optimizing compilers for Scheme which can produce incredibly fast code.

Author:  tro [ Mon Apr 30, 2007 4:02 pm ]
Post subject:  Re: Why Java sucks

With respect to the original post, the main thing I was thinking while reading it is "explicit over implicit". Java sacrifices prettiness and syntactic sugar for being absolutely explicit and simple. The extra stuff you have to write when programming in Java is a bother if you're writing something small, but as you scale up, the extra explicitness helps not only make nice IDE features work, but also helps the programmer understand the execution logic better. With languages like Perl and sometimes even Python, if you don't know some subtleties of the language, a lot of code can make you go, "What the heck does this do?". Java is a lot more readable, IMHO.

Still, I think the switch statement and the low-priority casting is retarded.

Author:  wtd [ Mon Apr 30, 2007 9:11 pm ]
Post subject:  RE:Why Java sucks

I was not necessarily comparing it to Perl or Python. How do you feel if instead I compare it to a statically typed language with type inference?

Or perhaps a language with local type inference? Smile

Author:  gsquare567 [ Wed Sep 19, 2007 8:42 pm ]
Post subject:  RE:Why Java sucks

lots of stupid stuff in ur first post wtd.

1- meh, ok point but normal arrays can do that
2- would be cool, but u make an array
3- wats a tuple?
4- use a normal for loop
5- theyre both equally complicated
6- look at the constructor ur using, variable names or blocking notes usually say (if well-written)
7- that way u can have a variable with the same name as a method
8- looks nicer, security, but a good point

i didnt realize u had 24 answers. im not that bored. java is a great language to learn from; it's pretty basic and has all the complexities of every language in it. c and c++ may be faster, but are much less secure and harder to read. java's syntax is almost the same as php's, another useful language for coding on the web. java's platform is supported by most if not every system and is very universal. in my opinion, its a great learning tool and also an equally good choice of languages to learn as c or c++.

i also just realized that this is from 2 years ago. well, i hope u've changed ur opinion since then.

Author:  rdrake [ Wed Sep 19, 2007 9:07 pm ]
Post subject:  Re: RE:Why Java sucks

gsquare567 @ Wed Sep 19, 2007 8:42 pm wrote:
java's platform is supported by most if not every system and is very universal..
Oh wow, when I read that I just knew somebody has to link to this bash.org quote.

gsquare567 @ Wed Sep 19, 2007 8:42 pm wrote:
i also just realized that this is from 2 years ago. well, i hope u've changed ur opinion since then.
Guess again Laughing.

Author:  Tony [ Wed Sep 19, 2007 9:54 pm ]
Post subject:  Re: RE:Why Java sucks

gsquare567 @ Wed Sep 19, 2007 8:42 pm wrote:
in my opinion, [Java]'s a great learning tool and also an equally good choice of languages to learn as c or c++.

I suppose you're right. C++ is a horrible choice of a language to learn as well. Laughing

Your counter points (when they even work!) are just workarounds for Java's problems. The point was to not need to have those workarounds in the first place.

Besides
Quote:
1- meh, ok point but normal arrays can do that

No, you can't. Java's Array is not and ArrayList

Quote:
7- that way u can have a variable with the same name as a method

That's just stupid. To get this kind of a collision, you'd have to be naming something really really badly.

Author:  rav3n [ Sat May 17, 2008 9:57 pm ]
Post subject:  RE:Why Java sucks

I don't understand why people always have to complain about languages. If you don't like them why don't you write your own? Because you couldn't be bothered!

Author:  syntax_error [ Sat May 17, 2008 10:33 pm ]
Post subject:  Re: Why Java sucks

rav3n wrote:

I don't understand why people always have to complain about languages. If you don't like them why don't you write your own? Because you couldn't be bothered!


Please read the forum rules, do not re-start a 8 month old thread for something like that.

Author:  r691175002 [ Sun May 18, 2008 12:12 am ]
Post subject:  Re: RE:Why Java sucks

rav3n @ Sat May 17, 2008 9:57 pm wrote:
I don't understand why people always have to complain about languages. If you don't like them why don't you write your own? Because you couldn't be bothered!

Or because a language without developer backing and a large codebase is useless, and would take an incredible amount of time.

Author:  Euphoracle [ Sun May 18, 2008 12:17 am ]
Post subject:  Re: RE:Why Java sucks

rav3n @ Sat May 17, 2008 9:57 pm wrote:
I don't understand why people always have to complain about languages. If you don't like them why don't you write your own? Because you couldn't be bothered!


That is like saying "Don't criticize a movie if you can't make your own". Everyone is perfectly entitled to critic and complain about anything if they have a reason to.

Author:  Tony [ Sun May 18, 2008 1:16 am ]
Post subject:  RE:Why Java sucks

Besides, other languages have already been developed. It's not like we're coming up with brand new features that no one has yet. In fact, all of them have been implemented well, in multiple other languages.

Author:  Aziz [ Sun May 18, 2008 10:24 am ]
Post subject:  RE:Why Java sucks

I do love Java, but I've been learning Python lately and have come to hate-love situation for Java.

There's 3 reasons why I still love it and will still use it:

1) I grew up with it. Since my baby days of programming, Java's taken care of me.
2) javadocs. PHP and python have great documentation that I've seen, but nothing beats the standard api documentation and the java tutorials.
3) Community & support. Even here at compsci.ca, Java's one of the top languages supported.

Author:  Nick [ Sun May 18, 2008 11:01 am ]
Post subject:  Re: RE:Why Java sucks

Aziz @ Sun May 18, 2008 10:24 am wrote:
1) I grew up with it. Since my baby days of programming, Java's taken care of me.
2) javadocs. PHP and python have great documentation that I've seen, but nothing beats the standard api documentation and the java tutorials.
3) Community & support. Even here at compsci.ca, Java's one of the top languages supported.


you never said anything about the actual language

Author:  Aziz [ Sun May 18, 2008 12:48 pm ]
Post subject:  RE:Why Java sucks

Well, Java has a lot of great features, but if it weren't for those 3 points, there's other languages that can do the same

Author:  Hendo [ Fri May 23, 2008 10:49 am ]
Post subject:  Re: Why Java sucks

Java sucks because getting background music to work in my game is freakin impossible

Author:  haskell [ Fri May 23, 2008 3:14 pm ]
Post subject:  RE:Why Java sucks

Java sucks because you suck? Lol,,,

Author:  tenniscrazy [ Sun May 25, 2008 10:03 am ]
Post subject:  RE:Why Java sucks

just because you can't figure something out doesn't mean it sucks

Author:  Hendo [ Sun May 25, 2008 11:31 am ]
Post subject:  Re: RE:Why Java sucks

tenniscrazy @ Sun May 25, 2008 10:03 am wrote:
just because you can't figure something out doesn't mean it sucks

nah,i was being half saracastic, it's just java is so complex for playing sounds compared to everything else i have used (Turing is a beginners tool i know, but hey it was REALLY easy to play music Wink )
I know a little Objective-C but that also is not hard to play sounds because i use xcode to develop it and sounds are much easier to play. In reality, I don't mind Java, it has been fun learning it and is a good learners tool for OOP

Author:  tenniscrazy [ Sun May 25, 2008 4:25 pm ]
Post subject:  RE:Why Java sucks

i agree, it is more complicated to do most things...but i guess that means that you can customize more aspects of the code and change minute details...right?

Author:  wtd [ Sun May 25, 2008 4:50 pm ]
Post subject:  Re: RE:Why Java sucks

tenniscrazy @ Mon May 26, 2008 5:25 am wrote:
i agree, it is more complicated to do most things...but i guess that means that you can customize more aspects of the code and change minute details...right?


Java offers no particular advantages over other programming languages in this respect.

Author:  r691175002 [ Sun May 25, 2008 5:23 pm ]
Post subject:  Re: Why Java sucks

Java tends to be a little overengineered but in a lot of cases it means that you can mix and match the rest of the API to do far, far more than in other simpler languages. If you want something simple then you grab another library that wraps it or provides an alternative.

I just like Java, I don't need reasons for it. It is more fun working in Java, I like the syntax, I like the mindset (I especially like the IDEs). I am more productive in Java. I would take it over C++ any day and I've done a fair amount of C++.

Author:  Aziz [ Sun May 25, 2008 9:57 pm ]
Post subject:  RE:Why Java sucks

Razz we're not talking about C++ here. Java is more beautiful than C++, but throwing together elegant Python code that just can't be done so simply in Java is intoxicating.

You've heard that each language has it's reason to be used - and it's true. Java is more verbose and complex, and sometimes that's needed. I still love Java, like I said.

Oh, and r######, I assure you the IDE you're using can be used for other languages as well. That's assuming it's a great IDE like you say it is, I'm thinking like Eclipse, NetBeans, JCreator, etc. Don't come back at me with "Ready to Program doesn't understand Scala!" because I will slap you for liking it Very Happy

Author:  r691175002 [ Sun May 25, 2008 10:15 pm ]
Post subject:  Re: RE:Why Java sucks

Aziz @ Sun May 25, 2008 9:57 pm wrote:
Oh, and r######, I assure you the IDE you're using can be used for other languages as well. That's assuming it's a great IDE like you say it is, I'm thinking like Eclipse, NetBeans, JCreator, etc. Don't come back at me with "Ready to Program doesn't understand Scala!" because I will slap you for liking it Very Happy

Yeah, I use Eclipse. I tried it for C++ but it wasn't the same (No refactoring, Javadoc equivalents etc...). I've considered picking up Python for a while, but I shudder at a language where braces have been replaced with indenting (Or even worse, keyword counterparts like end). Yeah, I'm shallow, I know. I'm going to have to integrate a scripting language into one of my projects soon so I'll probably end up using Jython despite my reservations.

Author:  wtd [ Sun May 25, 2008 11:03 pm ]
Post subject:  Re: RE:Why Java sucks

Aziz @ Mon May 26, 2008 10:57 am wrote:
Java is more verbose and complex, and sometimes that's needed.


It's needed when you have programmers who don't know what they're doing, but that's a technological fix to a problem in human society, and thus... ultimately doomed to failure.

Author:  shadowman544 [ Mon Jun 02, 2008 8:52 am ]
Post subject:  Re: Why Java sucks

"Why do methods which take no parameters need parentheses? "

I believe methods that do not take parameters need parentheses for the simple reason that it creates a recognizable difference between the method and a class. I my self can not come up with any other reason than this.(also whats the problem with this its two keys, less if you have an IDE that is any good)

Author:  Nick [ Mon Jun 02, 2008 9:02 am ]
Post subject:  Re: Why Java sucks

shadowman544 @ Mon Jun 02, 2008 8:52 am wrote:
"Why do methods which take no parameters need parentheses? "

I believe methods that do not take parameters need parentheses for the simple reason that it creates a recognizable difference between the method and a class. I my self can not come up with any other reason than this.(also whats the problem with this its two keys, less if you have an IDE that is any good)


first of, you shouldn't be naming classes and methods the same at all. Methods should start lower case and classes uppercase.
secondly, IDE's don't make the language, personally, I don't use an IDE (except at school)

Author:  Aziz [ Mon Jun 02, 2008 9:08 am ]
Post subject:  RE:Why Java sucks

I think his point would've been better had he said to recognize the difference between method and variable identifiers. =/

Author:  Nick [ Mon Jun 02, 2008 9:28 am ]
Post subject:  Re: RE:Why Java sucks

Aziz wrote:

I think his point would've been better had he said to recognize the difference between method and variable identifiers. =/

if you mean so that you can have variable names and method names the same, I think Tony says it better than I:
Tony @ Wed Sep 19, 2007 9:54 pm wrote:
Quote:
7- that way u can have a variable with the same name as a method

That's just stupid. To get this kind of a collision, you'd have to be naming something really really badly.

Author:  Aziz [ Mon Jun 02, 2008 1:20 pm ]
Post subject:  RE:Why Java sucks

I agree. But I'll argue just because. What if you're implementing List, or something similar, and need to keep a track of the size of your list, and naturally you'd call that member 'size'. But you have to implement the size() method [url]http://java.sun.com/javase/6/docs/api/java/util/List.html#size()[/url]

Now, there's ambiguity (I misspelled it, I know). Sure, you could make it 'listSize' or something, but when you're maintaining the code somewhere down the line, and you come across this:

code:
if (size > newSize) //etcetc


Is it referring to the size method, or did you name a member 'size'? Sure, it's easy to check, and documentation can help, but it's a drawback.

Just arguing. I think the brackets are optional in these languages, right? So you could add them if you want.

Smile

Author:  Tony [ Mon Jun 02, 2008 1:54 pm ]
Post subject:  RE:Why Java sucks

the brackets are not optional, that's the problem.

And I don't think that example is valid. You would not normally do List.size() = n. List should figure out its own size, based on its elements. As such size only returns the value, and you shouldn't care if it returns it through a getter method or from an internal variable directly.

Author:  r691175002 [ Mon Jun 02, 2008 2:25 pm ]
Post subject:  Re: Why Java sucks

Whoa, are we arguing that brackets should be optional for methods?
Sorry, but that sounds like a really, really bad idea. The brackets let you know something is happening. I know that:

xml.parse();

Has just done something (Probbably parsed the contents). If I see:

xml.parse;

Is parse a flag telling me whether or not it is parsed? Is parse a method? Have I just done something? This kind of ambuiguity is the worst idea I have ever heard of.


I get the feeling I comlpetely missed something though, so you may disregard this post if I am being a moron.

Author:  Aziz [ Mon Jun 02, 2008 2:59 pm ]
Post subject:  RE:Why Java sucks

code:
xml.parse

code:
xml.isParsed


Parse is a verb. That's how you know it's a method. is parsed is a verb as well, so it 'does' something. That something is answered the question - is it parsed - and that's usually a boolean result. Wether its a method or variable in that case doesn't matter.

And Tony, no you're right, you wouldn't. But I'm talking about the specific case where you see this code (if brackets were optional:)

code:
if (size > newSize) //etcetc


And perhaps you do care if it's a variable rather than a method. Like I said, it'd probably be better to give a better name to the variable, but then you still have the possible ambiguity with the size method. Someone reading that code in a large file might second guess it. When looking for bugs, you don't want to be distracted needlessly.

What's the big deal about brackets anyways? It's an extra two keystrokes per method. Java does suck because you have to use brackets. Couldn't we argue about how properties and the lack of in Java? Then you wouldn't need so many damned method calls in the first place!

Author:  Tony [ Mon Jun 02, 2008 3:16 pm ]
Post subject:  Re: RE:Why Java sucks

Aziz @ Mon Jun 02, 2008 2:59 pm wrote:
What's the big deal about brackets anyways? It's an extra two keystrokes per method.

That might not seem like a big deal with one method per line code. When you chain them (passing method results to other methods), all of those brackets add up, and it becomes much less readable when you come across blocks of ())).

Author:  rizzix [ Mon Jun 02, 2008 3:37 pm ]
Post subject:  RE:Why Java sucks

That is not true actually. Having more brackets does not make code less readable. You may not like it, but that's your personal taste.

You need to learn to acquire the skill to read code that use brackets, especially nested ones. The trick is, always assume the right side matches and read from the left to figure out the meaning behind the code.

Try and practice that here.
code:
abc(def(ghi(abc(def(ghi())))))


Most Java programmers are used to this and have no problems what-so-ever. For a lisp programmer on the other hand,this is second nature. Actually on a similar note, I initially found it difficult to get used to the dotless notation of Scala's infix methods, i.e coming from a Java background. Now I have no problems with it. Smile

Author:  Tony [ Mon Jun 02, 2008 3:59 pm ]
Post subject:  RE:Why Java sucks

I was thinking of something more like this..

code:

_hash.put(c.get_key(), new Integer((Integer)(c.get_value()).intValue() + this.size()));


I guess it's simply more annoying than unreadable...

Besides, Java manages to tell me the length of a primitive array without unnecessary ()s.
code:

my_array.length;

vs.
code:

my_array_list.size();

Author:  wtd [ Mon Jun 02, 2008 4:01 pm ]
Post subject:  RE:Why Java sucks

I have to say, having experience with both, I prefer Io's method chaining to Scala's approach.

Author:  rizzix [ Mon Jun 02, 2008 4:12 pm ]
Post subject:  Re: RE:Why Java sucks

Tony @ Mon Jun 02, 2008 3:59 pm wrote:
I was thinking of something more like this..

code:

_hash.put(c.get_key(), new Integer((Integer)(c.get_value()).intValue() + this.size()));


I guess it's simply more annoying than unreadable...
I'm sure you'll find lisp unbearable. However, yes this again is just your personal preference.
Edit: I forgot to mention, but, as of Java 1.5+ you are expected to try and eliminate explicit casts like that as far as possible, using generics. Its just bad style and is probably what's throwing you off

Tony @ Mon Jun 02, 2008 3:59 pm wrote:
Besides, Java manages to tell me the length of a primitive array without unnecessary ()s.
code:

my_array.length;

vs.
code:

my_array_list.size();
One of the strengths of Java is that it is consistent, eliminating surprises. This philosophy is enforced throughout the standard Java libraries and in many other third party libraries. There are usually no unnecessary surprises, with the only exception (rooted into the language itself) are that array lengths are determined by accessing a variable rather than a method.

Author:  michaelp [ Mon Jun 02, 2008 4:17 pm ]
Post subject:  Re: RE:Why Java sucks

Aziz @ Sun May 25, 2008 9:57 pm wrote:
Razz we're not talking about C++ here. Java is more beautiful than C++, but throwing together elegant Python code that just can't be done so simply in Java is intoxicating.

More beautiful than C++!??!?! Surprised
From what I've seen in Java, it seems kinda ugly, compared to C++. Maybe that's because I'm used to the syntax of C++, because from what I've seen in other languages, I quite like the syntax of C++.


r691175002 @ Sun May 25, 2008 10:15 pm wrote:
Yeah, I use Eclipse. I tried it for C++ but it wasn't the same (No refactoring, Javadoc equivalents etc...). I've considered picking up Python for a while, but I shudder at a language where braces have been replaced with indenting (Or even worse, keyword counterparts like end). Yeah, I'm shallow, I know. I'm going to have to integrate a scripting language into one of my projects soon so I'll probably end up using Jython despite my reservations.

I've just started Python, and I think that it's just a small obstacle. Once you get over it, it seems fine. Still kind of weird though, but it sets indenting rules in place.

Author:  rizzix [ Mon Jun 02, 2008 4:19 pm ]
Post subject:  RE:Why Java sucks

C++ is definitely ugly. In lots of different ways. That's one view most Java programmers share in common.

Author:  wtd [ Mon Jun 02, 2008 4:32 pm ]
Post subject:  RE:Why Java sucks

And once again, C++ should not be the benchmark for beauty, conceptual or syntactic. Nor do I consider it acceptable to say, "well C++ sucks worse, so Java's great!"

Author:  Aziz [ Tue Jun 03, 2008 7:14 am ]
Post subject:  Re: RE:Why Java sucks

Edit: This post was made before I read the last page. It still stands though, but argues about past things.

Tony @ Mon Jun 02, 2008 4:16 pm wrote:
Aziz @ Mon Jun 02, 2008 2:59 pm wrote:
What's the big deal about brackets anyways? It's an extra two keystrokes per method.

That might not seem like a big deal with one method per line code. When you chain them (passing method results to other methods), all of those brackets add up, and it becomes much less readable when you come across blocks of ())).


We were talking about methods that take no parameters, right? This problem really doesn't come up in that case... at most you're going to save chaining one pair of brackets if you can leave those parameters out:

code:
abc(def(efg(xyz())))


becomes

code:
abc(def(efg(xyz)))


Most Java programmers will recognize xyz() as a value right away, rather than another chain in the method call.

No, for leaving parentheses out completely, I think that should be restricted to simple cases. I've never done much with it, but from my understanding I think it could get ugly:

code:
abc def efg xyz


What is that code doing, exactly?

code:
abc(def, efg, xyz)


or

code:
abc(def, efg(xyz))


or

code:
abc(def(efg, xyz))


or

code:
abc(def(efg), xyz)


or

code:
abc(def(efg(xyz)))


and are def, efg, and xyz methodsor variables, in the case were they aren't clear?

It would be best just to use that last version, would it not. Which presents the same problem. Wink

Author:  rizzix [ Tue Jun 03, 2008 7:45 am ]
Post subject:  RE:Why Java sucks

If you follow the Haskell convention it's really doing
code:
abc(def, efg, xyz)


However, if you pull in a language like REBOL or something into this, tough luck Razz

Author:  michaelp [ Tue Jun 03, 2008 7:37 pm ]
Post subject:  Re: RE:Why Java sucks

rizzix @ Mon Jun 02, 2008 4:19 pm wrote:
C++ is definitely ugly. In lots of different ways. That's one view most Java programmers share in common.

Crying or Very sad
C++ is still beautiful in my eyes. Mr. Green

Author:  wtd [ Tue Jun 03, 2008 8:50 pm ]
Post subject:  Re: RE:Why Java sucks

rizzix @ Tue Jun 03, 2008 8:45 pm wrote:
If you follow the Haskell convention it's really doing
code:
abc(def, efg, xyz)


No, it's more like the following. Razz

code:
((abc def) efg) xyz

Author:  Tony [ Tue Jun 03, 2008 8:53 pm ]
Post subject:  Re: RE:Why Java sucks

rizzix @ Mon Jun 02, 2008 4:12 pm wrote:
Edit: I forgot to mention, but, as of Java 1.5+ you are expected to try and eliminate explicit casts like that as far as possible, using generics. Its just bad style and is probably what's throwing you off

That is likely it. I'll look more into generics. On a similar note, I've also just realized that the for-each loops are also available as of 1.5. The two should clean up some of the annoyances Smile

Author:  Vermette [ Tue Jun 03, 2008 10:40 pm ]
Post subject:  RE:Why Java sucks

foreach has definitely improved the language, no need to work with messy Iterators for a List.

Author:  rdrake [ Tue Jun 03, 2008 11:41 pm ]
Post subject:  Re: RE:Why Java sucks

Tony @ Tue Jun 03, 2008 8:53 pm wrote:
rizzix @ Mon Jun 02, 2008 4:12 pm wrote:
Edit: I forgot to mention, but, as of Java 1.5+ you are expected to try and eliminate explicit casts like that as far as possible, using generics. Its just bad style and is probably what's throwing you off

That is likely it. I'll look more into generics. On a similar note, I've also just realized that the for-each loops are also available as of 1.5. The two should clean up some of the annoyances Smile
Generics in Java are just on the surface. They're there but it still doesn't make them good as you'll soon learn Smile.

Author:  rizzix [ Wed Jun 04, 2008 12:21 am ]
Post subject:  RE:Why Java sucks

Why? Is it because of type erasure? Type erasure is necessary for backward compatibility.

However, type erasure does not make generics any less useful. Generics is still a very useful tool in modeling code.

Author:  Aziz [ Wed Jun 04, 2008 8:03 am ]
Post subject:  RE:Why Java sucks

Generics are wonderful. And so are foreach loops.

But I must say, I hate Java for it's damn type erasure. I understand backwards compatibility, but we've got to move forward. The compiler can already compile using a previous version, and I think it's about type generics are overhauled. I recently tried to right a 2-dimensional container - using generics. The crazy casting I was trying to do didn't work well, and I gave up and went from Grid<E> to IntGrid.

Perhaps there is a way to do it, but it was way to damn complicated when it could be made to work, and I had spent enough time on that class when I only needed it for one thing.

Author:  Zeroth [ Thu Jun 12, 2008 4:10 pm ]
Post subject:  Re: Why Java sucks

Another reason Java sucks: no first class functions.

Which is prettier:

code:

static class MethodHolder{
     static randomMethodVerb(int n){
              return n*n;
     }
}


vs
code:

def randomFunctionVerb(n):
      return n*n



For every possible standalone function, you need to have a class act as its escort. Its very annoying when I just want to write simple text processing code. I need to wrap it in so much extra annoying syntactic... well, effluent would apply. Even in C++ functions are first class citizens. In Java, they are all "methods". Some people may see it as a feature, but really, how could you? [/code]

Author:  rizzix [ Thu Jun 12, 2008 5:30 pm ]
Post subject:  RE:Why Java sucks

That (example of yours) does not necessarily demonstrate first-class-functions.

Author:  DemonWasp [ Thu Jun 12, 2008 8:01 pm ]
Post subject:  RE:Why Java sucks

This, like a lot of the other "deficits" of Java, can be both: problem and feature. Yes, some abilities (operator overloading, first class functions, pointer arithmetic) can be very powerful when used correctly. They can make code more expressive, faster, or better.

However, all of these are easy to abuse. Operators can be overloaded in nonsensical ways (I've heard of the + operator meaning "next" in a List implementation). Pointer arithmetic can be buggy and incredibly difficult to fix. Functions outside of classes can devolve rapidly into the horrific world of C: where there's NO Object-Oriented programming (note: OOP isn't the be-all-and-end-all...it's just way better than the alternatives for a lot of applications).

What all this means is that the code is easier to maintain and to work on. The language denies you the use of some of the worst antipatterns and programming kludges. Yes, it also prevents you from using it in certain ways, but does so to prevent that idiot sitting next to you from using it incorrectly.

That said, operators should be overloaded for a lot of the basic classes. Integer, Double, Float, etc should all have the operators + - * / overridden (it only makes sense), much as String has + overridden. Not doing that makes no sense whatsoever to me.

Author:  Zeroth [ Fri Jun 13, 2008 9:52 am ]
Post subject:  Re: Why Java sucks

Maybe not neccesarily, but now, with that function, I can pass that around to other functions as variables, like:
code:

def iter(lst, func):
    for item in lst:
           print func(lst)


Of course theres this, which is gone in Python 3:
code:

map(func, lst)


The fact is, a first class function is one where you can refer directly to a function as if it were an object or variable, and even alter attributes of a function. But thats not my point. My point is that Java is so very paranoid of letting functions go around on their own. My friends and I joke that Java is "function-ist". Yes, not very funny. Its not necessarily that it prevents bad code. Its that it makes the code harder to read, since theres all that cruft surrounding static functions. I'm all for classes, but I don't use classes for every little thing I do. That is very much a case of, "If you only have a hammer, the whole world looks like a nail." Its also why I don't believe Java should be taught to first year students. It confuses the hell out of people when they get to C, or Scheme/Lisp, or anything where functions are very much first class citizens. Going the other way, however, is much better, in that the students recognize why certain things exist in Java, having been bit in the face by gotchas in other languages.

Personally, I prefer languages that don't nanny me in my coding. If I'm going to shoot my foot off, I'll find out in my unit tests I write before I do any code. Its just good common sense.

The problem with Java being "easy" to work on, is that it causes a kind of coding inertia, due to its verbosity. Someone writes 500 lines to do something it takes 10 lines to do in Python, Perl or Ruby. Now, when its discovered that theres a bug in the code, a severe one, or it doesn't work to specs, its a lot easier to throw out the 10 lines, vs the 500 lines. If there is a fundamental flaw of the logic or the interaction of the objects and methods, then it would take a lot of severe kludging to fix. You can see what'll happen from there. But that is personally my view. Everyone is entitled to theirs, and if you feel more productive and safer in Java, you are welcome to it. If that sounded snarky, I don't mean it as such.

-Zeroth[/b]

Author:  Vermette [ Fri Jun 13, 2008 11:17 am ]
Post subject:  RE:Why Java sucks

heh, you might like the following essay:

http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html

Author:  Zeroth [ Fri Jun 13, 2008 12:21 pm ]
Post subject:  Re: Why Java sucks

(I've read that before, but thanks. Its a brilliant essay, yes. Very Happy )

Author:  wtd [ Fri Jun 13, 2008 1:23 pm ]
Post subject:  RE:Why Java sucks

The other thing about short codebases as opposed to long ones...

You can throw it out and start again.

Author:  DemonWasp [ Fri Jun 13, 2008 2:24 pm ]
Post subject:  RE:Why Java sucks

There's nothing to say that you have to write ungodly amounts of Java to do stuff that can be done in 10 lines. You'll need more code, yes, but nowhere near 500 lines. And you may have less explicit error-handling, or be even further removed from the machine.

My preference is both for the language to "nanny" me, but also for it to do the same to other developers. I know I tend to write good code (provided I know how), but I don't trust most other developers to do so. After seeing some of the code other people release into production (and here I speak of Javascript, no less), I fear having to deal with other people's code written in C/C++.

I'd also agree that Java isn't a good choice for a first language, and perhaps not even a second language. It's very useful in the corporate environment, or when you're wanting to write larger projects on your own. A lot of the design decisions don't make a whole lot of sense until after you've learned a couple of other languages. It's probably a fantastic idea that UWaterloo is changing out Java in the first-year courses for Scheme and similar.

Perhaps a bigger problem than any language differences is developers who write bad code, or try to use the idioms of one language in another. They're altogether too prevalent, and it's impossible for the language to correct their incompetence - Turing, HTML/CSS/JS, Visual Basic, Java, C++...nothing can correct stupidity.

Some languages just do a better job of preventing it from becoming monumental.

Author:  Zeroth [ Fri Jun 13, 2008 3:43 pm ]
Post subject:  Re: RE:Why Java sucks

DemonWasp @ Fri Jun 13, 2008 11:24 am wrote:
[snip]nothing can correct stupidity.

Some languages just do a better job of preventing it from becoming monumental.
I had to quote that. That is so very true. Thats what Java does well, it keeps people from cutting off their feet without encapsulating the cutting verb in an Attacker object. Wink

I don't neccessarily think Java sucks, just that its way overused for its minor advantages. I just dislike that a much better designed language, which had a VM before Java did, has nowhere near the "popularity" of Java. The benefits of having a very large marketing budget, hmm? (Just for reference, the language I'm talking about is Python. Started in 1991, vs 1994 for Java!) But I guess thats a good thing. Typically experienced Python programmers are of higher calibre than "Java School" trained programmers, as you need to learn Python on your own, instead of it being crammed at you. That in turn indicates initiative, which is a good thing for a programmer to have. Wink

Author:  rizzix [ Fri Jun 13, 2008 4:03 pm ]
Post subject:  Re: Why Java sucks

Zeroth @ Fri Jun 13, 2008 9:52 am wrote:
Personally, I prefer languages that don't nanny me in my coding. If I'm going to shoot my foot off, I'll find out in my unit tests I write before I do any code. Its just good common sense.
Just because you don't like a language to "nanny" you around, does not mean the language sucks.

Zeroth @ Fri Jun 13, 2008 9:52 am wrote:
The problem with Java being "easy" to work on, is that it causes a kind of coding inertia, due to its verbosity. Someone writes 500 lines to do something it takes 10 lines to do in Python, Perl or Ruby. Now, when its discovered that theres a bug in the code, a severe one, or it doesn't work to specs, its a lot easier to throw out the 10 lines, vs the 500 lines. If there is a fundamental flaw of the logic or the interaction of the objects and methods, then it would take a lot of severe kludging to fix. You can see what'll happen from there. But that is personally my view. Everyone is entitled to theirs, and if you feel more productive and safer in Java, you are welcome to it. If that sounded snarky, I don't mean it as such.
First, I highly doubt you'll get a 50:1 (Java vs others) lines-of-code ratio, so there's a bit of over-exaggeration there. Unless of course you are an extremely naive Java programmer. Secondly, I'd like to say that Java enforces you to think before you code whereas other languages (like Ruby, Python, etc) do not enforce this for various reasons, including the ones I'm about to mention.

Java forces you to think before you code. It enforce this at least though two very effective ways I can currently think of: library design and strong static typing.

Most Python/Ruby programmers dislike Java due to its complexity of library design. That is, well, their opinion, but it would make sense coming from such a background. Java programmers do not find the design overly complicated. In fact we like Java for the fact that it is a simple language (and hope that it continues to remain simple), so the only thing we'd need to focus on is software design. The Java libraries (standard and others) are usually well designed and most of these designs have been studied and generalized as "design patterns" -- another word/concept most Java-bashers dislike. These "design patterns" are not a guideline that all Java programmers must follow but rather they are a guidelines for coming up with one's own innovative design. I would like to further add, that it would be naive to use Java as a scripting/agile language. The agile frame of mind does not work well with Java at all. If you did approach coding in Java from this perspective you would eventually end up rewriting large amounts of code from scratch, rather than simply refactoring it toward improvement.

I don't suppose I need to say much about static typing. Providing a degree of proof of correctness before execution certainly enforces the think-before-you-code principle.

Author:  rizzix [ Fri Jun 13, 2008 4:09 pm ]
Post subject:  RE:Why Java sucks

Languages like Ruby or Python do not nanny you around. Thus you are left alone to code naively or shoot yourself in the foot till you've realized what you've done. Which eventually leads to the rewriting from scratch nonsense.

Author:  r691175002 [ Fri Jun 13, 2008 4:31 pm ]
Post subject:  Re: Why Java sucks

I do agree that first class functions would be nice. Too often you have to wrap a single function in an inner class for an event listener/similar.

Author:  Tony [ Fri Jun 13, 2008 5:09 pm ]
Post subject:  Re: Why Java sucks

rizzix @ Fri Jun 13, 2008 4:03 pm wrote:
I don't suppose I need to say much about static typing. Providing a degree of proof of correctness before execution certainly enforces the think-before-you-code principle.

While better than no proof at all, static typing isn't much of a test. In fact, it could give a false sense of correctness. Static typing will say that the result of 2 + 2 is an integer, while a correct unit test of 2 + 2 = 4 (that would have to be written now anyway) would have the same implied.

Though in a corporate world run by business/management type of people who'd skip over testing in favour of deadlines, I suppose there's a certain advantage in forcing minimal testing via strong types.

Author:  rizzix [ Fri Jun 13, 2008 5:20 pm ]
Post subject:  RE:Why Java sucks

Static typing is not a test of values but a test of types. It provides proof of correctness for more abstract relationships.

Author:  Zeroth [ Sat Jun 14, 2008 12:36 am ]
Post subject:  Re: Why Java sucks

Rizzix, I never mentioned the libraries. I find the libraries to be very nice, well-organized, and well documented. However, I'm talking about the language itself, not the quite excellent tools, libraries, and documentation around the language.

Different types of programmers like different kinds of languages. If I'm doing an application, I may consider Java, but for most of my use, which right now is computer science research, Python works perfectly well. Its rapid development design allows me to sit down, code up an implementation, run it quickly through some peer-checks to make sure the code is right, which the designed in readability really helps with, then run the code. If I were to do this in Java, there would be discussions, and planning about the object model, about relationships... when I want to get some work done. No offense, but when I'll be hiring programmers, if you were to reach for Java as the first language to solve a problem thrown at you within time constraints, I'll shoot you in the foot. There are advantages and disadvantages to Java, and it has its uses.

But the point is, it can achieve its purported goals... and LOOK NICER while doing so! I think that was a lot of what wtd was trying to get at.(Correct me if I'm wrong, I'll retract that statement, lol).

Oh, and on the topic of "static checking", where I am not an expert in any way, I'll refer you guys to this superbly written blog post: http://www.coderoshi.com/2007/09/5-reasons-static-typing-sucks.html

Author:  rizzix [ Sat Jun 14, 2008 1:18 am ]
Post subject:  RE:Why Java sucks

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

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. Razz 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 Wink ) I suggest you give O'Caml, Haskell or Scala a look. They'll probably enlighten you on this path.

Author:  matt271 [ Sun Apr 05, 2009 2:04 pm ]
Post subject:  RE:Why Java sucks

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" :]

Author:  DtY [ Sun Jun 14, 2009 8:48 pm ]
Post subject:  RE:Why Java sucks

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

Author:  wtd [ Tue Jun 16, 2009 11:34 am ]
Post subject:  RE:Why Java sucks

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

code:
class Queue {
    // ...

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

Author:  rizzix [ Wed Jun 17, 2009 2:59 pm ]
Post subject:  RE:Why Java sucks

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.

Author:  rizzix [ Wed Jun 17, 2009 3:00 pm ]
Post subject:  RE:Why Java sucks

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.

Author:  DtY [ Wed Jun 17, 2009 3:38 pm ]
Post subject:  RE:Why Java sucks

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.

Author:  matt271 [ Wed Jun 17, 2009 5:45 pm ]
Post subject:  Re: Why Java sucks

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?

Author:  DtY [ Wed Jun 17, 2009 6:30 pm ]
Post subject:  Re: Why Java sucks

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

Author:  wtd [ Wed Jun 17, 2009 11:27 pm ]
Post subject:  RE:Why Java sucks

Reading material on the subject. Smile

Author:  wtd [ Wed Jun 17, 2009 11:33 pm ]
Post subject:  Re: RE:Why Java sucks

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.

Author:  rizzix [ Wed Jun 17, 2009 11:52 pm ]
Post subject:  RE:Why Java sucks

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?

Author:  wtd [ Thu Jun 18, 2009 12:12 am ]
Post subject:  RE:Why Java sucks

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.

Author:  rizzix [ Thu Jun 18, 2009 12:25 am ]
Post subject:  Re: RE:Why Java sucks

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.

Author:  wtd [ Thu Jun 18, 2009 1:48 am ]
Post subject:  Re: Why Java sucks

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.

Author:  Prabhakar Ragde [ Thu Jun 18, 2009 8:20 am ]
Post subject:  Re: RE:Why Java sucks

rizzix @ Wed Jun 17, 2009 11:52 pm wrote:
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.


I/O functions can't be referentially transparent.

Author:  DtY [ Thu Jun 18, 2009 9:29 am ]
Post subject:  RE:Why Java sucks

Those are separate though, but the first isn't a method. Try writing a program that will sit for a while, then read a line from std input. When you run it, enter something while it's just hanging, and it will still get that line. Standard input is just a file, you use the keyboard to write to it, and a method to read from it.

(This may not work in Windows)

Author:  wtd [ Thu Jun 18, 2009 11:01 am ]
Post subject:  RE:Why Java sucks

Some actual code where this is implemented.

code:
class TEST
create { ANY }
    make
feature { ANY }
    make is
        local
            line : STRING
            prompt : STRING := "Input something: "
        do
            std_output.put_string(prompt)

            std_input.read_line
            line := std_input.last_string

            std_output.put_string("You said: " + line)
            std_output.put_new_line
end

Author:  rizzix [ Thu Jun 18, 2009 12:22 pm ]
Post subject:  Re: RE:Why Java sucks

Prabhakar Ragde @ Thu Jun 18, 2009 8:20 am wrote:
rizzix @ Wed Jun 17, 2009 11:52 pm wrote:
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.


I/O functions can't be referentially transparent.


You're right, however under CQS style of programming, state mutating functions are separated from those that do not modify state. Hence within a currently mutated state, those non-mutating function are pure and referentially transparent. The only way to achieve that here is to sperate IO into two different methods.

However, I'm just arguing that such an approach breaks atomicity of certain operations (in this case IO) and hence is not the wisest style of programming.

Edit: A better approach to referential transparency is to enforce it through the type system itself. a la Haskell.

Author:  Analysis Mode [ Thu Jun 18, 2009 1:03 pm ]
Post subject:  Re: Why Java sucks

lol, nice topic.

Java sucks because it's not one of the languages allowed at the IOI.

Author:  x30Jx [ Thu Jun 18, 2009 4:15 pm ]
Post subject:  RE:Why Java sucks

what the flaming lasers is an IOI?
pardon my n00bage.

Author:  Analysis Mode [ Thu Jun 18, 2009 4:22 pm ]
Post subject:  Re: Why Java sucks

International Olympiad in Informatics, for high school programmers aroudn teh world.

and in case you're wondering, no, i've never been to the IOI before, i'm nowhere near as 1337h4x.

Author:  Forumer [ Wed Oct 28, 2009 12:38 pm ]
Post subject:  RE:Why Java sucks

it sucks but its still a good language to begin with

Author:  Prabhakar Ragde [ Wed Oct 28, 2009 1:00 pm ]
Post subject:  RE:Why Java sucks

It's a terrible language to begin with. It should be at least third on anyone's list.

Author:  bbi5291 [ Wed Oct 28, 2009 4:13 pm ]
Post subject:  Re: Why Java sucks

Analysis Mode @ Thu Jun 18, 2009 1:03 pm wrote:
lol, nice topic.

Java sucks because it's not one of the languages allowed at the IOI.

This kind of argument will only make everyone else hate us more than they do already.

Author:  A.J [ Wed Oct 28, 2009 6:03 pm ]
Post subject:  RE:Why Java sucks

By 'us' you are referring to IOI'ers?

damn you guys...

Author:  bbi5291 [ Wed Oct 28, 2009 6:30 pm ]
Post subject:  Re: Why Java sucks

Nope, when I said "we" it included Analysis Mode, so it doesn't specifically mean IOI people.
I meant people who lean strongly toward algorithm coding and away from development. (Language statistics on USACO and TopCoder are very revealing here.)

Author:  [Gandalf] [ Thu Oct 29, 2009 4:28 pm ]
Post subject:  RE:Why Java sucks

My fellow CompSci.ca posters, get back on topic or move your conversation elsewhere. Thank you.

For the record, I think the qualities of the teacher (whether this be a person, book, or yourself) are far more important than the qualities of the tool (ie. Java). Java won't teach you OOP, and it won't stop you from using lessons learned from FP in your code. It will probably annoy you in the process, but that's a useful experience too. Wink

Author:  speedyGonzales [ Thu Nov 18, 2010 10:13 am ]
Post subject:  Re: Why Java sucks

Java is excellent language for beginners and about competition programing. While C++ has next_permutation, we have BigInteger so it is up to you to decide which language to choose. If you have problems with TL (time limit) you can switch your code in C++ in order to pass, although core java programmers will prefer to make some optimizations that are almost piece of art. This is the main advantage of C++ coders, the speed of C++.
To post here some code snippets and say i hate java because of that, this is not my way to discuss topics.

Cheers,
the fastest mouse in java. BooHoo

Author:  DemonWasp [ Thu Nov 18, 2010 2:14 pm ]
Post subject:  RE:Why Java sucks

Worth noting: Java isn't slow. Please stop promulgating the myth that Java is necessarily slower than C++. There are some (albeit a little contrived) benchmarks that show Java being faster than compiled C++. Most benchmarks show the two languages being approximately the same speed, the difference being far less than the difference between one algorithm and another.

Author:  Prince Pwn [ Thu Jan 13, 2011 6:05 am ]
Post subject:  RE:Why Java sucks

Java is very CPU heavy. It's also very slow. Java is a fun language to use but both Java as a whole and Sun Microsystems the company and their Java fail when it comes to speed.

Author:  DemonWasp [ Thu Jan 13, 2011 10:51 am ]
Post subject:  RE:Why Java sucks

This is an old, tired argument, but here we go again: Java isn't slow. Go build a benchmark that uses equivalent code between Java and (supposedly faster language). Chances are good that Java's performance will be within about 5% of the reference implementation.

If it isn't, go get a JVM that's at least version 5 (1.5) or 6 (1.6). SUN's versioning system is dumb as anything, but that's a separate issue.

If it still isn't, please post code. Try not to make the usual "Java versus C benchmark" mistakes, like accidentally using synchronized collections, non-buffered or synchronized (or both) I/O, concatenating too many strings, etc.

If anything, Java is more guilty of being memory-heavy (30-60mb overhead, depending on launch configuration) than CPU-heavy. Even this is a minor issue, except at launch-time where the JVM has to be loaded before your program even starts to load.

Author:  2goto1 [ Thu Jan 13, 2011 11:07 am ]
Post subject:  RE:Why Java sucks

Java works great, countless companies big and small use it for everything from desktop to enterprise. It scales well on the enterprise side of things. This argument is definitely moot.

Like any development platform that uses a virtual machine, there are trade-offs. But they are largely negated since Java bytecode is compiled by the JIT compiler, into a lower level machine format.

Java has been owned by Oracle since acquiring Sun in 2009.

Author:  102jon [ Thu Feb 24, 2011 3:23 pm ]
Post subject:  Re: Why Java sucks

Java is plain dirt. C++ over java any day. But +1 for anyone who said python. If you're a very good programmer it is redundant to use a language that "nannies" you. Development speed for the win.

Author:  BigBear [ Sun Feb 27, 2011 1:26 am ]
Post subject:  RE:Why Java sucks

Back to original post has java adopted any of those features it didn't have almost 6 years ago

Author:  Tony [ Sun Feb 27, 2011 2:10 am ]
Post subject:  RE:Why Java sucks

Well the last major release was Java 6 and that happened in December 2006. So that's a no for most (all?) points, but it hasn't really been six years either. Lets see what's in Java 7's branch.

Author:  DemonWasp [ Sun Feb 27, 2011 11:24 am ]
Post subject:  RE:Why Java sucks

Java 7 has been released for preview. See here: http://jdk7.java.net/preview/

Author:  mirhagk [ Sun Feb 27, 2011 4:28 pm ]
Post subject:  RE:Why Java sucks

I heard a rumour recently that apple was going to stop supporting java on their machines, like they decided to not support flash. I was wondering if this is true or not.

Edit: Also I read something about success of competitions based on language, very interesting, C programs ran out of time and memory the least, C++ next, and Java and python last, but it really didnt make a difference, the biggest difference was in failure to compile, which is a reflection not upon the language, but rather on the fact that n00bs are more likely to get into java than C++ and especially compared to C. It was actually a very very interesting chart, and if anyone wants I can post the chart.

Author:  ProgrammingFun [ Sun Feb 27, 2011 5:24 pm ]
Post subject:  Re: RE:Why Java sucks

mirhagk @ Sun Feb 27, 2011 4:28 pm wrote:
I heard a rumour recently that apple was going to stop supporting java on their machines, like they decided to not support flash. I was wondering if this is true or not.

They still support Flash, they do not ship it pre-installed due to a serious loss of battery life: http://www.engadget.com/2010/10/22/apple-responds-on-missing-flash-in-new-macbook-airs-says-get-us/

mirhagk wrote:

It was actually a very very interesting chart, and if anyone wants I can post the chart.

Yes please... BooHoo

Author:  mirhagk [ Sun Feb 27, 2011 5:29 pm ]
Post subject:  RE:Why Java sucks

I meant like on iPod touch and iPad, where applications aren't even allowed to have it, like web browsers can't be made which support flash on ipod touch. (However cloud browse will decrypt flash and convert it at a server so that you can actually use it, its the most amazing app ever)

Author:  ProgrammingFun [ Sun Feb 27, 2011 5:51 pm ]
Post subject:  Re: RE:Why Java sucks

mirhagk @ Sun Feb 27, 2011 5:29 pm wrote:
I meant like on iPod touch and iPad, where applications aren't even allowed to have it, like web browsers can't be made which support flash on ipod touch. (However cloud browse will decrypt flash and convert it at a server so that you can actually use it, its the most amazing app ever)
So will SkyFire...
There is a Cydia flash available...but I don't think that counts...

Author:  huskiesgoaler34 [ Sun Feb 27, 2011 6:14 pm ]
Post subject:  Re: Why Java sucks

mirhagk, please post the chart. It seems to be very interesting.

By the way, I am starting to learn the basics of Java and it doesn't seem that bad, but yet again, I'm still on the basics Very Happy

Author:  mirhagk [ Sun Feb 27, 2011 7:29 pm ]
Post subject:  Re: Why Java sucks

Lang Total AC PE WA CE RE TL ML OL RF
C 451447 31.9% 6.7% 35.4% 8.6% 9.1% 6.2% 0.4% 1.1% 0.6%
C++ 639565 28.9% 6.3% 36.8% 9.6% 9.0% 7.1% 0.6% 1.0% 0.7%
Java 16373 17.9% 3.6% 36.2% 29.8% 0.5% 8.5% 1.0% 0.5% 2.0%
Pascal 149408 27.8% 5.5% 41.8% 10.1% 6.2% 7.2% 0.4% 0.4% 0.5%
All 1256793 29.7% 6.3% 36.9% 9.6% 8.6% 6.8% 0.5% 1.0% 0.6%

EDIT: sorry tabs don't work lol.

Here's a screencapture

Posted Image, might have been reduced in size. Click Image to view fullscreen.

Uploaded with ImageShack.us

Author:  huskiesgoaler34 [ Sun Feb 27, 2011 7:53 pm ]
Post subject:  Re: Why Java sucks

Thanks!

Author:  102jon [ Mon Feb 28, 2011 11:40 am ]
Post subject:  Re: Why Java sucks

So you mean pascal, not python.

Author:  ecookman [ Mon Feb 28, 2011 12:00 pm ]
Post subject:  RE:Why Java sucks

I do agree that Java does have flaws and is quite the speed hog and i don't really like it myself, but one word
Minecraft.

Author:  md [ Mon Feb 28, 2011 12:45 pm ]
Post subject:  RE:Why Java sucks

Minecraft is actually seemingly very poorly implemented. While I initially didn't like Java all that much it's grown on me and recently I've been working on a project that does 3D rendering in java and well... it blows Minecraft away performance wise.

Author:  DemonWasp [ Mon Feb 28, 2011 1:47 pm ]
Post subject:  Re: RE:Why Java sucks

md @ Mon Feb 28, 2011 12:45 pm wrote:
Minecraft is actually seemingly very poorly implemented. While I initially didn't like Java all that much it's grown on me and recently I've been working on a project that does 3D rendering in java and well... it blows Minecraft away performance wise.


This was also my feeling about Minecraft. Considering how simple the scenes are in Minecraft, they render amazingly slowly. There's no reason for a game like that to run as slowly as it does -- on my underpowered laptop (8400GS), Portal plays visibly better than Minecraft, despite being vastly more difficult to render.

Author:  mirhagk [ Mon Feb 28, 2011 9:09 pm ]
Post subject:  Re: Why Java sucks

102jon @ Mon Feb 28, 2011 11:40 am wrote:
So you mean pascal, not python.


Ya sorry, sometimes I'm dumb

Author:  mirhagk [ Mon Feb 28, 2011 9:11 pm ]
Post subject:  Re: RE:Why Java sucks

DemonWasp @ Mon Feb 28, 2011 1:47 pm wrote:
md @ Mon Feb 28, 2011 12:45 pm wrote:
Minecraft is actually seemingly very poorly implemented. While I initially didn't like Java all that much it's grown on me and recently I've been working on a project that does 3D rendering in java and well... it blows Minecraft away performance wise.


This was also my feeling about Minecraft. Considering how simple the scenes are in Minecraft, they render amazingly slowly. There's no reason for a game like that to run as slowly as it does -- on my underpowered laptop (8400GS), Portal plays visibly better than Minecraft, despite being vastly more difficult to render.


To be honest it feels as if notch doesn't really work on the game. Like not that much gets done in a weekly update compared to how much you could do in a week if it was your full time job (considering the fact he's making millions, he should be putting a full 40 hours a week into it).

He has to not be following proper OOP style if it takes him a while to incorporate new things, a proper OOP style game is very easy to add new creatures/blocks/items without having to do much work.

Author:  SmokeMonster [ Fri Jun 17, 2011 4:46 am ]
Post subject:  Re: RE:Why Java sucks

ecookman @ Mon Feb 28, 2011 12:00 pm wrote:
I do agree that Java does have flaws and is quite the speed hog and i don't really like it myself


It is 2011, can we please put this myth to rest? Look up the many benchmarks on the web and you'd see that Java is hardly "slow" or a "speed hog". For most of the software that gets written in the world the language speed is largely irrelevant, use common sense data structures and algorithms and make sure they are an efficient solution for the problem you are trying to solve. If a language is still slow than perhaps you are choosing the wrong tool for the job. Java can hold its own but is not as fast as C/C++, that's true but ask yourself the question- do you really the slight extra speed of c/c++ for the problem you are trying to solve? It's like a single guy who buys a 6 bedroom house just because it's bigger eventhough he's never going to use all of it. And even if Java was slow, speed is hardly an excuse to dismiss an entire language; Ruby is MONSTROUSLY slow yet it works perfectly fine within its domain.

Author:  Kharybdis [ Wed Jul 27, 2011 8:21 am ]
Post subject:  RE:Why Java sucks

i still like java. >.<

Author:  mirhagk [ Wed Jul 27, 2011 8:35 pm ]
Post subject:  Re: RE:Why Java sucks

SmokeMonster @ Fri Jun 17, 2011 4:46 am wrote:
And even if Java was slow, speed is hardly an excuse to dismiss an entire language; Ruby is MONSTROUSLY slow yet it works perfectly fine within its domain.


I would like to disagree with this last point. I'm not saying Java is that slow (It's obviously slower, but most of the slowness comes from bad programmers rather than a bad language), but I am saying that slowness is a reason to dismiss an entire language. There are certain applications where speed doesn't matter, and ruby excels at doing those tasks, which is why ruby gets off the hook, but look at a language like Turing. Turing is immensely slow, and some would argue that it's a easy syntax and what not, so it's good as a learning language, however that point is debatable in and of itself (as many more languages become much more beginner friendly, with some IDE's even letting you use a library perfectly fine, even if you never used it before, with things like autosense), so it leaves Turing completely in the dark. Yes there are other problems with Turing, of course, but the biggest issue is just plain speed.

Author:  Insectoid [ Thu Jul 28, 2011 9:32 am ]
Post subject:  RE:Why Java sucks

Well, Turing is obscenely slow, but I'd not say that's its biggest issue. It's got limits. It isn't multi-platform (except through Wine or equivalent), it is closed-source and only has one compiler (the most recent of which doesn't work right) and isn't even supported anymore except by this site. It does have very easy-to-use graphics though, which is nice. Most people don't care about easy graphics as much as the advanced features available in other languages though. Java sucks. I hate using it. But it provides very simple cross-compatibility, since the same compiled code will run on damn near any machine with a JVM. That alone is worth so much to developers (especially web developers) that they will forgo otherwise better languages in favor of Java.

Turing hasn't got this benefit. Nobody is going to use Turing in a professional setting, because it lacks a lot of basic functionality and support. Nothing could convince someone to use it over Java or Actionscript or C++ because there are no real benefits.

Speed is NOT an excuse to dismiss an entire language. Languages deprecate when the number of downsides grows too large and other languages become more advanced. It is the sum of the faults that decides if the fate of the language (though of course, much slower than Turing is indeed enough reason to not use a language).

I feel like I'm repeating myself, or taking a very long time to explain a simple idea, so...that's all.

Author:  mirhagk [ Thu Jul 28, 2011 12:51 pm ]
Post subject:  RE:Why Java sucks

What I mean is that speed can definetly be the deciding factor, and perhaps even the only factor, unless the language has something else to make up for it. For instance without Java's cross-platformness, it would probably be in big trouble.

If I wanted to make a video game, (not a web based flash one, or an indie one, but an actual video game), I would not use Java, mostly because of it's speed.

Look at minecraft as an example, fortresscraft (a minecraft rip-off built using XNA), is intensely faster, with better graphics than minecraft, and why is this? I would not say it's entirely the developer's, since fortresscraft's makers do not seem very proffessional, it comes down to the language's speed (specifically use of shaders).

Author:  apython1992 [ Thu Jul 28, 2011 1:36 pm ]
Post subject:  RE:Why Java sucks

Java is hardly slower than C#. Sure, before JIT it was a big issue, but now Java isn't remotely something I'd call a "speed hog".

Author:  mirhagk [ Thu Jul 28, 2011 1:46 pm ]
Post subject:  RE:Why Java sucks

slower in what way? With 3D video game development, XNA lets you use shaders much more intuitively, and even allows you to use your own shader to draw using it's 2D drawing functions. Java can work with openGL that lets you do most of those things sure, but it doesn't work as closely together, and the speed isn't quite as good.

If you really think that fortresscraft was somehow developed better than minecraft (other than the fact that the developers actually were able to do things such as bump mapping and stuff), then I am completely wrong, but I think notch is a decent enough developer, and it's the limitations of his project and language that make it slow.

Author:  DemonWasp [ Thu Jul 28, 2011 5:16 pm ]
Post subject:  RE:Why Java sucks

Then you're wrong. The reason that Minecraft is slow is because that's how its written. Java is perfectly able, through any one of various libraries (LWJGL, JOGL, ...) of accessing OpenGL features, including everything from shaders and bump mapping to the fun mesh subdivision stuff in OpenGL4 / DirectX 11. Some kinds of calls might be slower, because there's a slight JNI overhead, but you can usually get around that with batched calls (instead of draw-this-triangle, use draw-these-1K-triangles).

For example, Java Monkey Engine (JME) is a shader-based 3D engine written entirely in Java, and it's pretty fast.

Author:  Insectoid [ Thu Jul 28, 2011 5:17 pm ]
Post subject:  RE:Why Java sucks

http://jmonkeyengine.com/showcase/

jMonkey is pretty sweet. These games, while certainly not the most graphically intense, do look very nice, and all were programmed in Java. I'd bet my ass they run faster than Minecraft's garbage graphics, and jMonkey can certainly be optimized further. I am 100% sure that most of the slow-down in Minecraft is due to bad code.

XNA is a toolkit, not a language. All it does is abstract game creation away from low-level code and lets you build games for multiple (microsoft) platforms easily. I don't see how it speeds up the actual execution except perhaps because XNA code is faster than anything the game developer could (or has the time to) write.

I haven't bothered to look for any, but I'm sure there are tools available to streamline OpenGL/whatever development to match XNA's functionality.

EDIT: Mythruna looks like a minecraft clone (according to the description, and them blocky trees) but you can't deny how nice the other games look.

Author:  mirhagk [ Thu Jul 28, 2011 10:20 pm ]
Post subject:  RE:Why Java sucks

the reason why XNA runs faster is because it takes away the low level work (while keeping most of the needed control), and those low level functions are done by the library, This makes it faster for 2 reasons. 1 because the programmer themselves don't have to worry about sub-optimal code, and 2 because the actual operations aren't running as C# code, but rather as assembly operations.

This is actually where much of C#'s speed comes into play, not in the fact that the operations themselves are fast, but because the common libraries are all implemented as assembly libraries, instead of C# code.

jMonkey does actually look decent, but compare that to XNA games, like these
http://www.riemers.net/eng/Tutorials/XNA/Csharp/Series4/Gradient_skybox.php
http://www.youtube.com/watch?v=EAcMWJvibjo&feature=related

http://www.youtube.com/watch?v=2LBz31EpBNA&feature=related

Author:  DemonWasp [ Fri Jul 29, 2011 12:18 am ]
Post subject:  RE:Why Java sucks

Okay, then look at Tribal Trouble ( http://tribaltrouble.com/ ), JMonkeyEngine demos ( http://jmonkeyengine.com/demo/webstart/ ) and JMonkeyEngine tutorials ( http://jmonkeyengine.org/wiki/doku.php/jme3#tutorials_for_beginners ).

All the things you've listed as benefits of XNA are also benefits of JME, with the exception that most of JME is Java. The difference is pretty negligible though, especially since much of the straight-up arithmetic is farmed out to the GPU in either case.

Author:  mirhagk [ Fri Jul 29, 2011 12:37 am ]
Post subject:  RE:Why Java sucks

But the fact that the library is written in Java is the point. Obviously assembly routines are going to run faster than either language ever could, so the fact that the .NET libraries are all assembly routines is the thing that makes it fast.

Author:  rdrake [ Fri Jul 29, 2011 3:36 am ]
Post subject:  Re: RE:Why Java sucks

Thread is TL;DR, but...

mirhagk @ Fri Jul 29, 2011 12:37 am wrote:
But the fact that the library is written in Java is the point. Obviously assembly routines are going to run faster than either language ever could, so the fact that the .NET libraries are all assembly routines is the thing that makes it fast.
Yes, but .NET assemblies are different than object code compiled from assembly. Both the JVM and .NET environments compile bytecode down to machine code in a JIT manner when required.

Tools such as ngen exist for .NET to pre-JIT all of the code. That is, run every possible branch ahead of time so the native code is generated. Otherwise the JIT compiler would compile to native code at run-time. I'm sure Java has similar projects.

Another random slap at Java which I personally found amusing: [general] [WARNING] Index corruption and crashes in Apache Lucene Core / Apache Solr with Java 7.

Author:  DemonWasp [ Fri Jul 29, 2011 7:54 am ]
Post subject:  RE:Why Java sucks

Actually, I don't find it obvious that hand-written assembler will necessarily be faster than compiled code. That may have once been the case, but compilers are orders of magnitude better now, and JVM / CLR run code pretty fast. Often, the performance difference is so narrow you'd never notice it; occasionally, the managed languages are actually faster than equivalent C++ code.

Author:  Tony [ Fri Jul 29, 2011 9:47 am ]
Post subject:  RE:Why Java sucks

That depends on all kinds of things. Sometimes you might have intimate knowledge of the operating environment (OS, hardware, memory states) that will let you make assumptions that a compiler cannot infer from static analysis alone. Or that are plain illegal (e.g. certain shenanigans with raw memory access). Then you could win in some (in absolute terms... not necessary significant) performance.

But the size of the applications has grown in complexity to a point where anything that runs on top of an OS will benefit from a compiler over hand assembly.

Author:  mirhagk [ Sat Jul 30, 2011 11:38 pm ]
Post subject:  RE:Why Java sucks

I just want people to try out a little experiment. (not sure if it works with Java, since their libraries are written in Java I believe).

Open up a C# project with .NET. create a sorting algorithm, the fastest you can (probably quicksort), and then try to optimize the best you can. Make the algorithm sort an object of type list. Okay now test out the speed. Now call the exact same list with it's built in sort method and compare.

Last time I did this, I sorted some giant data structure (forget exactly how big) in about 3 seconds, and I was so happy. Called .Sort() and it sorted in 11ms. That's what I'm talking about here.

Author:  Tony [ Sun Jul 31, 2011 1:14 am ]
Post subject:  RE:Why Java sucks

All that this "experiment" shows is that you shouldn't be the one writing library implementations for major programming languages Laughing

Author:  DemonWasp [ Sun Jul 31, 2011 4:04 am ]
Post subject:  RE:Why Java sucks

Err, yeah. Just did this experiment myself. Sorting a list of 1M Integer objects with my custom not-especially-efficient mergesort implementation...833ms. The Collections.sort() API managed it in 653ms.

What the hell were you sorting that it took you a full 3 seconds to sort?

Author:  Insectoid [ Sun Jul 31, 2011 6:34 am ]
Post subject:  RE:Why Java sucks

Lol mirhagk. People have been improving and optimizing the standard library for years and years now. Good luck writing a better sort function in one evening.

Author:  mirhagk [ Sun Jul 31, 2011 12:45 pm ]
Post subject:  RE:Why Java sucks

It was actually my final algorithm after about a month's lesson's on sorting in school. It was quicksort, so perhaps others may have been slightly faster, but it was definetly the fastest in my class, and it was a true implementation of quick sort.

I don't remember exactly how many integers I was sorting, but I know it was at least a couple million.

Also i mentioned that the experiment probably wouldn't work with Java, which is why demonwasp's results turned out as they did.

Oh and insectoid, I have written better sorting functions than quicksort, or any implementation of sorting. They were only better for certain projects but they were MUCH faster for those projects. (For instance a list where only one item is out of place takes much too long with quicksort, or mergesort, or anything the standard libraries may use, but it's trivially fast with bubble sort, it's all about the application)

Author:  DemonWasp [ Sun Jul 31, 2011 4:32 pm ]
Post subject:  RE:Why Java sucks

Are you sure you didn't have the API sort run on already-sorted data? When I do that, the time for the API sort drops to ~120ms. I seriously doubt that a full sort of "several million integers" occurred in 11ms, no matter what language you implemented it in.

Full list of times I generated (1M Integers for the Collections examples, 1M ints for the array examples):
Collections.sort() - random data - 763ms
Collections.sort() - sorted data - 117ms
Custom mergeSort() - random data - 903ms
Custom mergeSort() - sorted data - 543ms
integer array sort - random data - 242ms
integer array sort - sorted data - 62ms

Author:  phil [ Fri Aug 12, 2011 12:13 pm ]
Post subject:  RE:Why Java sucks

It sounds like you would be happier programming in Haskell Very Happy

Author:  goroyoshi [ Mon Feb 27, 2012 7:58 pm ]
Post subject:  RE:Why Java sucks

for #2, you can return an array

Author:  bbi5291 [ Mon Feb 27, 2012 10:35 pm ]
Post subject:  Re: Why Java sucks

re: sorting: The C++ standard library typically uses introsort. It starts out as quicksort, but falls back to heap sort if it hits too many bad partitions, in order to avoid degenerating to quadratic running time; and below some small cutoff, it uses insertion sort to finish the job (it's non-recursive, so it has less overhead). These parameters are typically carefully tuned and tested against real-world data (and, of course, on real-world machines) in order to obtain optimal performance.

That's why standard library sort functions are so damn fast.

Author:  randint [ Sat Mar 23, 2013 10:21 am ]
Post subject:  RE:Why Java sucks

Java 7 supports switch (String)

Author:  BMP [ Sat Jan 03, 2015 6:54 pm ]
Post subject:  RE:Why Java sucks

How to shoot yourself in the foot with Java.

After importing java.awt.right.foot.* and java.awt.gun.right.hand.*, and writing the classes and methods of those classes needed, you?ve forgotten what the hell you?re doing.

Author:  MatthewDaigneau [ Mon Jan 19, 2015 12:49 pm ]
Post subject:  RE:Why Java sucks

Is this a reference to a certain novel?


: