Forum Stats

  • 3,872,125 Users
  • 2,266,392 Discussions
  • 7,911,052 Comments

Discussions

Categories

I hate making Java more complex

843793
843793 Member Posts: 41,732 Green Ribbon
edited Apr 30, 2003 1:09PM in Generics
Just wonder, how many people hate adding generic, enum, boxing conversion, for(:), etc, to Java, which make Java almost as complex as C++.

I hate all of them, expecially generic. I like Java what it is now. If people like more complex language, why they(including me) come to Java from C++???

· Share on TwitterShare on Facebook

Comments

  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Because C++ did them wrong.

    Although it looks like Java may do it wrong as well.
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I also hate making java more complex. I love java's simplicity. But, I think that when complexity can turn run time errors into compile time errors, it is worthwhile. That's why I like generics; without them, if you put a String into a hash map that is supposed to hold only StringBuffer's, you don't find out you made a mistake until the bad line of code gets executed. With generics, you can find out when you compile that you made a mistake. This is good, don't you agree?

    I don't like some of the other proposed changes, espcially the ones that add complexity and save typing. I love how verbose java is, that you are forced to specify exactly what class all constants and static functions come from. This "static import" thing is just bulls*** to me. Sure, it saves you from having to type a class name on occasion, but now when I see "foo = magicFunction();", I can't just search the file for the function - to figure out what the heck is going on, I have to search all the classes that were statically important too. Ugh. Especially if you spend a lot of time working with other people's code, this will lead to a lot of wasted time tracking down where things come from.

    Anybody else agree with me, that adding stuff to catch errors is good, adding stuff to save typing at the expense of clarity is bad?

    PS - I'm also of the group that believes "import java.awt.*;" is bad form, because again, then when you see "Foo.magicFunction()", you don't know which package it is from. If you had "import java.awt.Foo", you can just check the import list, right away you know where the function is coming from.
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Yeah, can not agree more.

    foo = magicFunction(). Am I writing C/C++ code? It seems more like a global function. sigh. Compare this: GigaView gv = GigaView.getInstance(); vs GigaView gv = getInstance(), What would people think of when they read the latter one in more than 500 lines of code?


    As for for(s : myArrayList), Now, The language itself is tied tightly with the Collection framework, which, is essentially a library. Do you want to improve the library? Sorry, you should redefine the language first :)

    As for generic, Sure, it can add compile time error checking, but, from my programming experience, people rare add a wrong class instance into a collection. And, I don't think generic is useful without operator overloading(Although I do know Sun team claims that they don't want to unify primary type and class type).
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Yeah, can not agree more.

    foo = magicFunction(). Am I writing C/C++ code? It
    seems more like a global function. sigh. Compare
    this: GigaView gv = GigaView.getInstance(); vs
    GigaView gv = getInstance(), What would people think
    of when they read the latter one in more than 500
    lines of code?
    I Agree that this can be abused.

    However, whithin a package there are sometimes some basic constants that most of the classes in the package need. Many times the qualifying class name is useless verbage in this context.

    But I probably won't ever use this construct across package boundaries.

    >
    As for for(s : myArrayList), Now, The language itself
    is tied tightly with the Collection framework, which,
    is essentially a library. Do you want to improve the
    library? Sorry, you should redefine the language first
    :)
    I don't think this is a valid argument. String/StringBuffer are tightly tied to the language. So are Throwable/Exception/RuntimeException. This new feature is much less tied to the library than some of the above.

    This seems like a nice set of syntactic sugar that will reduce typographical errors -- especially when combined with generics, if they add some of the extensions that have recommended in these forums.

    >
    As for generic, Sure, it can add compile time error
    checking, but, from my programming experience, people
    rare add a wrong class instance into a collection.
    There are lots of mistakes that people rarely make that compilers check for us. When there of millions of lines of code out there, even rare mistakes happen. Besides, generics are not just for containers.
    And, I don't think generic is useful without operator
    overloading(Although I do know Sun team claims that
    they don't want to unify primary type and class type).
    I disagree -- I find generics quite useful.

    I also find it strange that you seem to be in support of operator overloading, since they can be abused much worse than static imports. In my opinion, operator overloading is wonderful for some tasks and awful for most others.

    Darron
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    I agree that the advantages of these new features do not justify the language complexity imposed by them, especially generics. Having used generics in C++ and templates in Ada, I have had extensive experience with similar language features since 1983. The concept of generics is a siren's song that will overly complicate the language and its library without adding much value. It wasn't a new concept at all when they tried to add it to C++, and look at what turned out. What makes the Java community think that it can do any better?

    Sun lets Java developers vote for up to three of their favorite "Request for Enhancements," but they don't allow developers to vote AGAINST such requests. I would have gladly used one of my votes in this case to offset someone else's vote. Also, I conjecture that most of those who voted for it do not realize the implications that a change of this magnitude will add to the language. If you think that the addition of generics is a good thing, then read some of the posts in the following forum before you reply. You'll see a lot of original supporters complaining. In particular, Sun has decreed that "When 1.5 is released, code compiled with generics enabled will require a 1.5 VM to run." That is, you won't be able to use generics for things like applets unless you are using them on a company intranet and can require everyone to upgrade their runtime to version 1.5.

    http://forum.java.sun.com/thread.jsp?forum=316&thread=362755
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Correction to my previous post: Ada calls it "generics"; C++ calls it "templates." Of course I knew that since I have had several years experience with both languages and have taught them both in training courses and in academia. I simply reworded a statement and did not proof read it carefully.
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    "In particular, Sun has decreed that "When 1.5 is released, code compiled with generics enabled will require a 1.5 VM to run." That is, you won't be able to use generics for things like applets unless you are using them on a company intranet and can require everyone to upgrade their runtime to version 1.5."

    Sun has not "decreed" anything or changed the design of Java generics in any way. They simply made the decision that code compiled with javac using the -source 1.5 switch will require a 1.5 JRE to run the generated bytecode. You are free as always to use another Java compiler if you do not like how javac is implemented.
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    You are free as always to use
    another Java compiler if you do not like how javac is
    implemented.
    Unfortunately, this just isn't true. Yes, you're free to use any compiler you like in that place of javac. But it won't do you much good if the libraries are different. Just like assert and the AssertionError class, the new features in 1.5 are being written to depend on 1.5's library classes - some of which won't be available in previous versions. Mostly this won't be a problem - generics will mostly work fine unless you use reflection. But the compiler is not the only place where compatibility happens.

    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    Why doesn't someone hack Jikes so that it will compile generics to backwards compatible class files?

    Or perhaps even simpler just write some sort of simple script (in perl perhaps) that changes the class file version numbers from Sun's generics compiler. If it is really backwards compatible and you don't use the features that require the new JVM (Reflection on generics) then that should work also.
    · Share on TwitterShare on Facebook
  • 843793
    843793 Member Posts: 41,732 Green Ribbon
    #define PL/I C++
    #define C Java

    http://www.jargonfile.com/jargon/html/entry/If-you-want-X-you-know-where-to-find-it..html

    There is a legend that Dennis Ritchie, inventor of C, once responded to demands for features resembling those of what at the time was a much more popular language by observing "If you want PL/I, you know where to find it." Ever since, this has been hackish standard form for fending off requests to alter a new design to mimic some older (and, by implication, inferior and baroque) one. The case X = Pascal manifests semi-regularly on Usenet's comp.lang.c newsgroup. Indeed, the case X = X has been reported in discussions of graphics software (see X).
    · Share on TwitterShare on Facebook
This discussion has been closed.