Why do people hate Java?



  • @xtremezone said:

    The fact is that processing power is limited and you simply cannot give the BEST solution from scripted or byte-coded applications. It might require more work on the programmer's part to do, but it seems that a well written application in C/C++ will result in a much faster application than a functionally equivalent written in any of the scripting languages you have named.

    This is a common misconception. Escpecially newbies think that the program spends most of it's runtime in their code. This is true for some kinds of programs, e.g. games and word processors, but totally wrong e.g. for a database frontend. In fact, most business applications spend a lot of time in the database layer. Choosing a lowlevel-language like C for the frontend hardly makes any difference in terms of performance. On the other hand, choosing a powerfull language makes it much easier and cheaper to customize the program to the users' requirements, so they might actually gain a lot of performance because the program does exactly the right thing.



  • @masklinn said:

    @Obfuscator said:

    Yes, you're right. I feel that by not introducing too many special constructs, Java teaches design patterns in a nice way.

    The issue I have with this declaration is the fact that you consider design patterns good thing. See, Java teaches design patterns but in other languages what you get by introducing design patterns is baked into the language or so simple to attain that you don't even think of it as a pattern, it's just natural behaviour.

    The way I see it, most low level design patterns (i'm not talking about, say, MVC here) are "common solutions to work around the shortcomings of the language", the more design patterns you need to use (or you can recognize, or whatever) and the lower level they are, the less productive (from a programmer standpoint) and high level your language is.

    Remember, in the 70s Object Orientation was a C design pattern...

    I found this post especially interresting, because I've never thought of it that way. And you are probably right in many ways. For example, I really do think that the command pattern is a poor subsitute for function pointers or closures. But there are also many examples when the builtin solutions are less than elegant. Take the C# event and delegate keywords as an example. It might be just me, but I think they are mostly confusing, and are not really improving productivity in any way. The just sort of obfuscate how things work behind the scenes. I think the most important aspect of a good language is that it doesn't change philosophy and has a clear goal. Perl is a good example. It's very cluttered and nearly impossible to understand for non-users. But it's focusing on a few hard-to-solve problems and is really good at it. It never tried to be more than it is, and that is one of its best qualities. I would never try to write a Perl program in Java or C++, and I agree that that would require incredible amounts of "workaround-design patterns". In this sense, I agree with what you are saying.

    But there is another side of design patterns. These are the patterns used to improve your design by decreasing coupling, structuring you program in a reusable way and increasing maintainability. I can't really say that I think that it's up to the programming language to solve these problems for me. Therefore, I would still like to argue that design patterns are very important to learn. And if there is only a few simple constructs to learn in the language, it's more obvious that the design is the most important thing about coding, and not about "using as many keywords as possible". So, in short, what I should have said is probably that "Java teaches good application design".

     



  • @Obfuscator said:

    I think the most important aspect of a good language is that it doesn't change philosophy and has a clear goal. Perl is a good example. It's very cluttered and nearly impossible to understand for non-users. But it's focusing on a few hard-to-solve problems and is really good at it. It never tried to be more than it is, and that is one of its best qualities.

    Perl's philosophy is to try and be everything to everybody (usually quite effectively) - commonly abbreviated as TMTOWTDI. At the same time, it's designed around various principles of linguistics, so to a person who can read perl, you can really read perl - you don't have to decode it in your head to figure out what it does. It's like learning a foreign language, and this is deliberate. (People who gripe about perl are frequently like people who go to Japan and try to talk English to everybody, then complain that nobody understands them and it must be everybody else's fault - sure it's hard, but it's your own fault if you can't do it)

    It belongs to the small class of languages that are designed with the intention that the programmer must really learn how to use it, rather than being designed down to the programmer's level. This reduces to one of the old philosophical questions: do you try and achieve synthesis between human and computer so they can work more effectively, or do you limit yourself to what the human can already do? This question pops up all over the place (for example, in user interface design).

    I would never try to write a Perl program in Java or C++, and I agree that that would require incredible amounts of "workaround-design patterns".

       use Java::Import qw(
    java.lang.StringBuffer()
    );

    my $sb = new java::lang::StringBuffer();
       $sb->append(jstring("java String")); 
    The true master can write Perl programs in any language. Yes, it's constructing an object on a real JVM.



  • @xtremezone said:

    @tster said:
    @masklinn said:
    @tster said:

    I guess you have never used LISP/Ruby/Perl/ML/Smalltalk if you think that C++ is the most powerful language around.

    Can we add Python, Haskell, Erlang, D, Factor and Self to the list?

    Sure..  I just didn't want to make a long list and make it look like it was the definitive list...  THere are certainly more. 

    Well you're right that I haven't used that long list of languages (I believe I said I am a young programmer). From what I can tell most of the languages listed are scripting languages, which generally speaking suffer from performance loss like that of Java. I'm not saying that they aren't powerful. Nor did I say that Java was not powerful.

    They're not, they're full fledged programming language, and only Perl, Ruby and Python could ever be called "Scripting Languages".

    @xtremezone said:

    The fact is that processing power is limited and you simply cannot give the BEST solution from scripted or byte-coded applications. It might require more work on the programmer's part to do, but it seems that a well written application in C/C++ will result in a much faster application than a functionally equivalent written in any of the scripting languages you have named.

    As a matter of fact, processing power usually isn't limited.

    @xtremezone said:

    The only two languages in the above lists that are compiled (from what I found) are ML and D.

    Actually, Haskell is also compiled (even if it has interpreters) and so is Common Lisp (there are in fact extremely good Common Lisp compilers)

    And compilation is not necessary for good performances: Erlang is a language created by Ericsson for use in telecom switches (among others), it's an interpreted, functional language for soft-real time and massive concurrent programming and it has very good performances (except when you're doing heavy string-based stuff, and even there it's acceptable) even without using the JIT implementation (HiPE).

    And of course it can trivially be scaled from a single-processor machine to multiple multiprocessor machines.



  • Okay,  I read through the "Hundred Year Language" article. It suggests we do away with strings, arrays, hash tables, and numeric types. Essentially they praise the "list" as the basis for the 100 year programming language. Apparently definitions are a bad thing... On the contrary, I HATE languages with no type definitions.

    The article also assumes that in 100 years programming will no longer consider optimization because computer hardware will be near infinitely fast and there will be no need for it.

    I'm a young guy, and that sounds stupid to me. I've heard some older programmers, professors, etc., say that 20 years ago they thought the same about today. The truth is that no matter how fast computers operate or how much capacity they have; we will always use every bit of every cycle possible. In 100 years I expect programs to be that much larger, graphics will be that much more intense, and optimized programming will be just as important, if not more important, than it is today.

    Consider this: if you choose to write your programs in an inefficient language that makes writing the program a snap, how well do you think your application will do competing against a competitor's application that has been written in an optimized language? The users don't care about how the program got there: they care about how it suits their wants and needs.

    Towards the end of the article the author seems to change gears and move toward compiler optimization. In other words, you write your program in a very programmer friendly-way (which in my opinion is an explicit language, not a simple one), and the compiler fills in the gaps to make the program completely optimal.

    In short, programmer-friendly languages are great (again, your definition may vary). However, performance is not something we should overlook. Waste is never a good thing. "Good" waste, as the author of that article puts it, does not exist. Sometimes we trade performance for rapid development, but for larger applictions this is inappropriate - and even for the smaller applications it is seen as an expense: it is not free.

    I never meant that C++ was the perfect language for every domain. I meant that C++, and other languages powerful like it, are all I care to use. C++ is very powerful, but it's not necessary worthwhile to write an optimized C++ application for a small Windows application. There are benefits to the simpler languages, but they come at a cost - power and performance.



  • We're going to just have to ardently disagree on this until you've actually gotten over your stigma and honestly tried a myriad of languages.



  • @xtremezone said:

    Okay,  I read through the "Hundred Year Language" article. It suggests we do away with strings, arrays, hash tables, and numeric types. Essentially they praise the "list" as the basis for the 100 year programming language. Apparently definitions are a bad thing... On the contrary, I HATE languages with no type definitions.

    That's cool. Some of the languages that were listed have static type definitions (optional for e.g. lisp and inferred for SML or Haskell).

    In fact, languages like SML and Haskell have some of the most complete and impressive type systems of all the programming languages (much more so than C++ or Java).

    @xtremezone said:

    Consider this: if you choose to write your programs in an inefficient language that makes writing the program a snap, how well do you think your application will do competing against a competitor's application that has been written in an optimized language? The users don't care about how the program got there: they care about how it suits their wants and needs.

    Consider this: you choose to write your programs in an extremely efficient language that makes microoptimization a staple, how well do you think you'll fare about a competitor's application written in a programmer friendly language which is slower but actually works instead of crashing and burning every 10 minutes? The users don't care about the speed of execution that much: they care about the program doing what it's supposed to do in the first place.

    Another one: Consider this: you choose to write your programs in an extremely efficient language that makes microoptimization a staple, how well do you think you'll fare about a competitor's application written in a programmer friendly language which managed to reach the market with your current feature set 3 years before you were done, and has now gone long past it? The users don't care about the speed of execution that much: they care about the program existing in the first place.

    Oh, and on a side note you're setting up a logical fallacy of "efficienty and programmer-hating languages" versus "inefficient and programmer-friendly languages". This is known as the False Dichotomy as you don't consider, say, efficient and programmer-friendly languages (OCaml is efficient, and OCaml is very high level. For instance.)

    @xtremezone said:

    I never meant that C++ was the perfect language for every domain. I meant that C++, and other languages powerful like it, are all I care to use. C++ is very powerful, but it's not necessary worthwhile to write an optimized C++ application for a small Windows application. There are benefits to the simpler languages, but they come at a cost - power and performance.

    Please voice your opinions again when you'll have learned and extensively used more than two languages.



  • I second everything masklinn said.



  • @asuffield said:

    @Obfuscator said:

    I think the most important aspect of a good language is that it doesn't change philosophy and has a clear goal. Perl is a good example. It's very cluttered and nearly impossible to understand for non-users. But it's focusing on a few hard-to-solve problems and is really good at it. It never tried to be more than it is, and that is one of its best qualities.

    Perl's philosophy is to try and be everything to everybody (usually quite effectively) - commonly abbreviated as TMTOWTDI. At the same time, it's designed around various principles of linguistics, so to a person who can read perl, you can really read perl - you don't have to decode it in your head to figure out what it does. It's like learning a foreign language, and this is deliberate. (People who gripe about perl are frequently like people who go to Japan and try to talk English to everybody, then complain that nobody understands them and it must be everybody else's fault - sure it's hard, but it's your own fault if you can't do it)

    It belongs to the small class of languages that are designed with the intention that the programmer must really learn how to use it, rather than being designed down to the programmer's level. This reduces to one of the old philosophical questions: do you try and achieve synthesis between human and computer so they can work more effectively, or do you limit yourself to what the human can already do? This question pops up all over the place (for example, in user interface design).

    I would never try to write a Perl program in Java or C++, and I agree that that would require incredible amounts of "workaround-design patterns".

       use Java::Import qw(
    java.lang.StringBuffer()
    );

    my $sb = new java::lang::StringBuffer();
       $sb->append(jstring("java String")); 
    The true master can write Perl programs in any language. Yes, it's constructing an object on a real JVM.

    Alright. Obviously I've said a lot of stupid things in this thread. I'll just be quitet now and go and try some new languages. I'll start with Haskell and Lisp. Can anyone recommend a good lisp compiler? There were to many to choose from ;)
     



  • @ammoQ said:

    @asuffield said:

    Ah yes, another of the dumber parts of the java standard library. I mean -  UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()), what sort of utter BASTARD names functions like that?

    I fail to see the problem here.

    The problem is the wear to my keyboard. 

    The other problem is that the system look and feel is still subtly wrong, and therefore the app looks unprofessional. (Buttons are the wrong size, message boxes are not system message boxes, a few things like that.) 



  • @Bob Janova said:

    @ammoQ said:
    @asuffield said:

    Ah yes, another of the dumber parts of the java standard library. I mean -  UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName()), what sort of utter BASTARD names functions like that?

    I fail to see the problem here.

    The problem is the wear to my keyboard. 

    That's why you don't use notepad res. cat to write java programs. BTW, this line appears only once per program, it at all.

     

    The other problem is that the system look and feel is still subtly wrong, and therefore the app looks unprofessional. (Buttons are the wrong size, message boxes are not system message boxes, a few things like that.) 

    Unfortunately, you are right. This is the reason why I prefer the Java L&F (aka Metal) to the nearly-there-but-not-yet Windows L&F (when I work with Windows at all).



  • What OS and version are you using?  System look and feel looks fine to me.



  • @Obfuscator said:

    Alright. Obviously I've said a lot of stupid things in this thread. I'll just be quitet now and go and try some new languages. I'll start with Haskell and Lisp. Can anyone recommend a good lisp compiler? There were to many to choose from ;)
     

    Well I like Haskell, but it's a bad idea to start with it I think, unless you really want to wallow in misery as you realize how little you know about so much stuff (this is not a jab by the way, this is the way I felt when I started trying to understand Haskell, and I had quite a few languages under my belt).

    I suggest you start with high level OO/Imperative languages, either C-syntax (D) or not (Python, Ruby). That way you'll get a feel of what higher levels of abstraction can offer, you'll start getting some potential insight on functional programming, and your brain won't nearly explode at the rate it would if you learn Haskell.



  • @masklinn said:

    Well I like Haskell, but it's a bad idea to start with it I think, unless you really want to wallow in misery as you realize how little you know about so much stuff (this is not a jab by the way, this is the way I felt when I started trying to understand Haskell, and I had quite a few languages under my belt).

    I suggest you start with high level OO/Imperative languages, either C-syntax (D) or not (Python, Ruby). That way you'll get a feel of what higher levels of abstraction can offer, you'll start getting some potential insight on functional programming, and your brain won't nearly explode at the rate it would if you learn Haskell.

    Well, I've done quite a lot of coding in Python, and tried Ruby for a while. I think Python is good, but Ruby is not the type of language I would go for. I wouldn't use them for anything less than trivial though, since I just don't really like the script feeling that these languages have. Been burnt too many times with those type of languages. Haven't tried D yet, but I use the Digital Mars C++ compiler on windows for its speed and simplicity. I feel that if I'm to learn a "true" OO language, I might just go all the way and use a truly pure one. I guess what I'm looking for is a OO language with robust typechecking. Is there any of those out there?



  • @Obfuscator said:

    @masklinn said:

    Well I like Haskell, but it's a bad idea to start with it I think, unless you really want to wallow in misery as you realize how little you know about so much stuff (this is not a jab by the way, this is the way I felt when I started trying to understand Haskell, and I had quite a few languages under my belt).

    I suggest you start with high level OO/Imperative languages, either C-syntax (D) or not (Python, Ruby). That way you'll get a feel of what higher levels of abstraction can offer, you'll start getting some potential insight on functional programming, and your brain won't nearly explode at the rate it would if you learn Haskell.

    Well, I've done quite a lot of coding in Python, and tried Ruby for a while. I think Python is good, but Ruby is not the type of language I would go for. I wouldn't use them for anything less than trivial though, since I just don't really like the script feeling that these languages have. Been burnt too many times with those type of languages. Haven't tried D yet, but I use the Digital Mars C++ compiler on windows for its speed and simplicity. I feel that if I'm to learn a "true" OO language, I might just go all the way and use a truly pure one. I guess what I'm looking for is a OO language with robust typechecking. Is there any of those out there?

    You paint yourself into a corner there since you want full OO but turn away the extant specimens...

    C++ is the language with the by far richest OO feature set, but neither it nor Java are fully object-oriented languages. I don't see why to go for D, it has more limited OO facilities than C++ along with a somewhat simplified syntax for templates and some other things, but that does not justify losing multiple inheritance (though it seems to have gained a small but somewhat enthusiastic gathering). Ruby and Python are fully object-oriented, but apparently due to bad experiences you want to stay away from them. Perhaps Scala, a fully OO rewrite of Java, might be up your ally; I like what I've seen of it, except that it doesn't support functions outside classes, which is silly and a major wart in Java.



  • @ammoQ: it's not that specific example that is of concern, it's just an example of the needless verbosity of Java. And it should be possible to write reasonable code in a simple text editor - maybe not UI design, but the application logic. Forcing me to use code completion because the language uses too many characters is the wrong answer - see this oft-referenced article to see why. My pattern of thinking fits with often coding obj.doSomething().doSomethingElse() before obj is declared. I shouldn't have to change how I think because the language I use is too verbose.

    @tster: I'm using Win XP but I've noticed these problems with all releases of Windows since Swing came out. I operate in Windows Classic mode with non-standard colours and Java doesn't get it right.

     Oh yes, and another thing I don't like about it: one (public) class or interface per file. WTF? I have to have a whole separate file for a two method interface? As a general guideline this may be reasonable (it depends on the project and the typical size of classes you're coding, it can often make sense to have a small package or class group in one file); as a compiler-enforced rule it is crazy.



  • @Obfuscator said:

    @masklinn said:

    Well I like Haskell, but it's a bad idea to start with it I think, unless you really want to wallow in misery as you realize how little you know about so much stuff (this is not a jab by the way, this is the way I felt when I started trying to understand Haskell, and I had quite a few languages under my belt).

    I suggest you start with high level OO/Imperative languages, either C-syntax (D) or not (Python, Ruby). That way you'll get a feel of what higher levels of abstraction can offer, you'll start getting some potential insight on functional programming, and your brain won't nearly explode at the rate it would if you learn Haskell.

    Well, I've done quite a lot of coding in Python, and tried Ruby for a while. I think Python is good, but Ruby is not the type of language I would go for. I wouldn't use them for anything less than trivial though, since I just don't really like the script feeling that these languages have. Been burnt too many times with those type of languages. Haven't tried D yet, but I use the Digital Mars C++ compiler on windows for its speed and simplicity. I feel that if I'm to learn a "true" OO language, I might just go all the way and use a truly pure one. I guess what I'm looking for is a OO language with robust typechecking. Is there any of those out there?

    The "truest" OO language is Smalltalk, but it doesn't feature static typing (it's a strongly, dynamically typed language). Very few OO languages actually have a strong static type systems, that's something that started with C++ and followed through with Java and C# (although maybe with weaker type sys? This could be debated), and D also seems to have a very strong type system, with nice generics, and type inference, and a lot of good stuff.

    Haskell, while having an extremely strong type system, is a purely (and pure) functional language, no OO there. Same for SML.

    I guess you could try OCaml, it's an Object extension of the Caml functional programming language so it's an OO/Functional language as opposed to most OO languages being OO/Imperative.

    Scala, as mentioned by Mikademus, may also be of interest, it's basically a "next gen" java with much stronger functional abilities, type inference, a better concurrency model (actors-based, kind-of feels like Erlang's), it runs on the JVM and it's backwards-compatible with Java (Scala can compile pure java code).

    Also please do note that Python and Ruby have very strong type systems what they don't have are static type systems (the types are not known nor checked before runtime)



  • @masklinn said:

    Haskell, while having an extremely strong type system, is a purely (and pure) functional language, no OO there.

    OO is a design concept, not a language feature, and it's entirely compatible with functional programming. In fact, it is quite hard to write complex programs in a non-OO fashion in Haskell (entirely possible, but the result is the same kind of mess you get when trying to write complex non-OO programs in Java). Haskell's object system is sadly lacking several important features though - it has an almost ideal mixin system and one of the most perfectly polymorphic type systems I've ever seen, but there's just no sane way to do partial inheritance or metaprogramming.

     

    Also please do note that Python and Ruby have very strong type systems what they don't have are static type systems (the types are not known nor checked before runtime)

    Ruby uses duck typing (the same as Perl), which is entirely different to both strong and weak typing (all these terms have very specific definitions). Saying that Python has a strong type system is like saying that raw lisp has a strong type system (it does, but the only types in lisp are 'list' and 'atom', so it's not a very interesting strong type system). While Python's type system does meet the criteria, it doesn't do any particularly useful type checking - it's only a strong type system by coincidence.



  • @Bob Janova said:

    it's not that specific example that is of concern, it's just an example of the needless verbosity of Java. And it should be possible to write reasonable code in a simple text editor - maybe not UI design, but the application logic. Forcing me to use code completion because the language uses too many characters is the wrong answer - see this oft-referenced article to see why.

    Nothing at all in Java forces you to apply the same verbosity for your own identifiers like the API does it. IMO, this verbosity is essential for the standard library. You don't want 20000+ cryptic class and method names. Since the standard library is already there, you can rely on the auto-completion features of your favorite IDE.

    My pattern of thinking fits with often coding obj.doSomething().doSomethingElse() before obj is declared. I shouldn't have to change how I think because the language I use is too verbose.

    I completely understand that. My favorite editor for programs is SlickEdit; this editor has a simple-but-usefull autocompletion feature that simply learns the words (identifiers) used in the program. For example, I can first write

    myVerySpecialFriend="BOB";

    and then go up to the position where I want the declaration, type a few letters (like "myv") and select "myVerySpecialFriend" from the popup.



  • @ammoQ said:

    You don't want 20000+ cryptic class and method names. Since the standard library is already there, you can rely on the auto-completion features of your favorite IDE.

    Well, I can agree with that. What I don't agree with is wanting 20000+ classes in the first place in the Standard Library. That kind of proliferation is an indication of something gone horribly wrong. shudders



  • @asuffield said:

    @masklinn said:

    Haskell, while having an extremely strong type system, is a purely (and pure) functional language, no OO there.

    OO is a design concept, not a language feature

    OO is a programming paradigm, FP is another one, they can be mixed (you can use FP as a base to OO just as you can use Procedural Programming as a base of OO), but this doesn't mean that FP languages are object oriented, and that programming in an object-oriented way in an FP language is a good idea.

    @asuffield said:

    and it's entirely compatible with functional programming.

    I know, OCaml and O'Haskell base OO on FP. Haskell doesn't, it bases FP on FP.

    @asuffield said:
    In fact, it is quite hard to write complex programs in a non-OO fashion in Haskell (entirely possible, but the result is the same kind of mess you get when trying to write complex non-OO programs in Java). Haskell's object system is sadly lacking several important features though - it has an almost ideal mixin system and one of the most perfectly polymorphic type systems I've ever seen, but there's just no sane way to do partial inheritance or metaprogramming

    Do you realize that by your "definition", everything that you can use to program is OO, even C, or Fortran, or Cobol??

    Just say that the part is sadly missing, and even Basic, Pascal and raw x86 ASM become somehow "object oriented".

    @asuffield said:

    Ruby uses duck typing (the same as Perl), which is entirely different to both strong and weak typing (all these terms have very specific definitions). Saying that Python has a strong type system is like saying that raw lisp has a strong type system (it does, but the only types in lisp are 'list' and 'atom', so it's not a very interesting strong type system). While Python's type system does meet the criteria, it doesn't do any particularly useful type checking - it's only a strong type system by coincidence.

    1. Ruby and Python have pretty much the same approaches to type systems, which is as a matter of fact Smalltalk's in broad lines: rich, strong (no coercion or automatic conversion), dynamic, runtime-only type system.
    2. Both can (and do extensively) use the so-called Duck Typing, which does not by any mean that you can't typecheck as you'd do in Java. But you have to do it "manually" (some people have created typechecking and method-dispatching decorators in Python so the "manually" is actually arguable) and at runtime, not via typehints and at compile time.

    At the end of the day, whatever you say about them, both Ruby and Python are strongly typed, exactly in the way that Smalltalk is strongly typed and with exactly the same type-system richness. And they're not statically typed, which doesn't make them "Perl".



  • @masklinn said:

    @asuffield said:
    In fact, it is quite hard to write complex programs in a non-OO fashion in Haskell (entirely possible, but the result is the same kind of mess you get when trying to write complex non-OO programs in Java). Haskell's object system is sadly lacking several important features though - it has an almost ideal mixin system and one of the most perfectly polymorphic type systems I've ever seen, but there's just no sane way to do partial inheritance or metaprogramming

    Do you realize that by your "definition", everything that you can use to program is OO, even C, or Fortran, or Cobol??

    Did you miss the first sentence? Languages are not OO, at all, ever. Program designs are OO (or not, as the case may be), and it's just one of many tools that may be employed in the creation of a program. Persisting in thinking of OO as a language feature leads to nonsense statements like "everything that you can use to program is OO" - it's a form of turing-completeness. OO is something that happens in the minds of people, not in computers.

     

    @asuffield said:

    Ruby uses duck typing (the same as Perl), which is entirely different to both strong and weak typing (all these terms have very specific definitions). Saying that Python has a strong type system is like saying that raw lisp has a strong type system (it does, but the only types in lisp are 'list' and 'atom', so it's not a very interesting strong type system). While Python's type system does meet the criteria, it doesn't do any particularly useful type checking - it's only a strong type system by coincidence.

    Ruby and Python have pretty much the same approaches to type systems, which is as a matter of fact Smalltalk's in broad lines: rich, strong (no coercion or automatic conversion), dynamic, runtime-only type system.

     

    Ruby uses a duck type system, not a strong one. Strong type checking disallows function applications that do not fit the specification, while duck typing has no specification at all (merely a system for determining which function to apply).


    Both can (and do extensively) use the so-called Duck Typing, which does not by any mean that you can't typecheck as you'd do in Java.

    You don't have a clue what you're talking about. The absence of such things is precisely what duck typing means. There is an established body of theory, literature, and research on this subject - you can't just make stuff up.

    Ruby is fundamentally duck typed (in fact, duck typing in the form of message passing is the fundamental axiom of Ruby, upon which everything else is built). It has no capacity for strong typing, because it has no capacity for type specifications. Simulating it via reflection and conditionals is not type checking in any sense.

    I can't be bothered to respond to the rest of your bile-spitting python bigotry. Get over it. Languages are just tools, not religions.


  • @asuffield said:

    Ruby uses a duck type system, not a strong one.

    Once again, Ruby uses a dynamic type system, not a static one, a strong type system is about values and containers having a type and the absence of coercion, not about static type analysis of programs.

    @asuffield said:

    Strong type checking disallows function applications that do not fit the specification, while duck typing has no specification at all (merely a system for determining which function to apply).

    Nope, sorry sir but that's "Static type checking" not "Strong type checking".



  • @masklinn said:

    a strong type system is about values and containers having a type and the absence of coercion, not about static type analysis of programs.

    Wrong. A strong type system is one which has some form of type specifications (independent from the actual program code, although usually placed alongside it) and requires that program code always validate against them. The validation might be done statically or dynamically. (That's approximately the definition of the term - the full one includes a definition of exactly what a type specification is, as opposed to other kinds of program validation technique, but that's about one chapter of a textbook on type systems so I'm not including it here)

    A strong type system is not about "having a type" - there is no requirement for the type specifications to cover the entire program (most do not), or for those specifications to be related in any way to the execution of the program - and does not include any definition of "coercion" (which could mean just about anything, you're probably mistaking C pointer casts for something that is applicable to other type systems - they aren't).

     


    @asuffield said:

    Strong type checking disallows function applications that do not fit the specification, while duck typing has no specification at all (merely a system for determining which function to apply).

    Nope, sorry sir but that's "Static type checking" not "Strong type checking".

    Where did you get this idea? Static type checking is when the program is validated against the type specifications without running the program. Dynamic type checking is when the program is validated against the type specifications while it is running. Again, these are the actual definitions. There is no relationship between the static/dynamic and strong/weak/duck properties - you can pick any combination.



  • @asuffield said:

    Again, these are the actual definitions.

    May I ask you a question here? Actual definitions from where?

    See the issue is that most of these terms have half a dozen definitions or more (see the second part of the post for 8 different and mostly incompatible definitions of "Strong Typing" courtesy of Mark Jason Dominus). I use one of the definitions and you use another one, I probably shouldn't have been so dogmatic and set on my definition and should just have asked you to agree to disagree on the definition, and thus the list, from the beginning.

    Various definitions of "Strongly typed language" found on the interblag, my source for it is this post from c.l.perl but you can also find it and and some more discussions on C2's StronglyTyped page

    1. A language is strongly typed if type annotations are associated with variable names, rather than with values. If types are attached to values, it is weakly typed.
    2. A language is strongly typed if it contains compile-time checks for type constraint violations. If checking is deferred to run time, it is weakly typed.
    3. A language is strongly typed if it has compile or run-time checks for type constraint violations. If no checking is done, it is weakly typed.
    4. A language is strongly typed if conversions between different types are forbidden. If such conversions are allowed, it is weakly typed.
    5. A language is strongly typed if conversions between different types must be indicated explicitly. If implicit conversions are performed, it is weakly typed.
    6. A language is strongly typed if there is no language-level way to disable or evade the type system. If there are casts or other type-evasive mechansisms, it is weakly typed.
    7. A language is strongly typed if it has a complex, fine-grained type system with compound types. If it has only a few types, or only scalar types, it is weakly typed.
    8. A language is strongly typed if the type of its data objects is fixed and does not vary over the lifetime of the object. If the type of a datum can change, the language is weakly typed.

    From what i understand, your definition of Strong Typing is about assertions 1 and 3, mine is mostly about assertions 4 to 6.

    Keeping on discussing this matter is pointless because since we'll never agree on the "right" definition of static typing (others smarter than us have tried and failed e.g.Benjamin C. Pierce of TAPL fame) we'll never agree on which languages are strongly typed, and which ones are weakly typed.

    Let's let it die here, ok?



  •  

    I can add my 2 cents about Java. When I first started coding in Java, I really wanted to like it. Some of these I discovered by my own projects, others I observed in commercial enterprise apps. I moved away from Java quite a few years ago for these reasons. My apologies if Java has "caught up" with some of these. If that's the case, my canned reply is: "Well it's about time! Other languages took care of that problem in version 1.0 of their product."

    1. I hate the UI of Java apps, always have. They never refresh correctly. They are slow. They don't look as good as other UIs. Sliders don't scroll correctly. (e.g.- I've seen well-known commercial apps where the slider is at the bottom when there's still more "page" below) Sun obviously never should have gotten into this arena. This is the day and age when UIs should "just work."

    2. I hate "Write once; debug everywhere." I've lived this nightmare in the corporate IT world. Why can't it "just work" like it is supposed to?

    3. Slow- dog slow. Too many apps are dog slow- even on fully loaded machines. This is less of an issue now, but at least historically it's been absolutely true.

    4. Applets are a failure- Flash "just works," almost every time. With applets you need to constantly worry about which users have what version of Java. With Flash, it just knows what version of the player you need if you coded your web page correctly. Applets are slow and don't refresh right. Don't scroll that window- or else the applet will not know how to refresh itself! Flash is much more compact, looks better, smoother, sharper, and is lightning fast. You know in your gut that Flash apps will "just work" wherever you deploy it- allowing you to sleep soundly at night. Java will give you nightmares. I once deployed an applet- one of my users said it made his machine crash and reboot when the applet was running, he left the machine idle for a few minutes and then his screensaver kicked in! Get it right, Sun!

    5. I'm tired of talking about the problems with Java, and then a Java guru gets upset, and says something like, "If only you would have used Java.. (insert perverse new Java technology of your choice, which I don't have time to take 2 months to learn, and wouldn't add squat to the value of my resume)!"

     

     

     



  • Oh I forgot one:

    6. Java gurus always reply the same to #3 with: 

     "It must be your code!"

    My reply:

     "No, it's Java." Java slowness has been a pattern for too long for it to be "the code."

     



  • @alexjag33 said:

    Oh I forgot one:

    6. Java gurus always reply the same to #3 with: 

     "It must be your code!"

    My reply:

     "No, it's Java." Java slowness has been a pattern for too long for it to be "the code."

    IMO much of Java's perceived slowness comes from the abundance of frameworks and "best practices". 



  • @ammoQ said:

    IMO much of Java's perceived slowness comes from the abundance of frameworks and "best practices". 

    I agree with you here. i've used several "commercial grade" java apps, and they all ran just fine. Azureus is a really good example of a really well designed java app that doesn't run "slow"

    Now mind you, i've never seen anything 3d done in java, or similar applications that require a ton of real-time DSP or anything like that... but if you're writing stuff like that you wouldn't want java anyhow since java isolates itself from the hardware by default (right?)

    Java has its place, i personally don't like it (and i know how to program in it), but it does some things really really well. if i want to write a networked application that doesn't need anything fancy and i want all of my friends to be able to use it, java is the way to go. I send them the jar files and they just work. (assuming they have the JVM installed, of course).

    The thing that i don't like about java and .NET is the same thing that i like about it. If i want to send a friend a java app (or VB.net, or C#) that i have made, they have to have the same (or higher) version of whatever virtual machine or framework i used. It eliminates the need for me to compile 10 different binaries, i never have to release the source code, but it makes it a pain to the people i know on dialup, and the non-tech savvy friends and family i have. BUT! after they have the framework, i can send them a 40K application that is as powerful as some 2 meg application that has everything compiled in already. And if i am remembering correctly, you can almost assert that the user experience is going to be the same on all platforms with java, right?

     I know why people hate Java, it's mostly because it isn't C++. I don't think you'll find many people who say java really really sucks who don't also know C++ and possibly C.

    In other words, you won't find an Eisel programmer that doesn't know C++ that thinks that Java is a piece of crap.



  • @alexjag33 said:

    Oh I forgot one:

    6. Java gurus always reply the same to #3 with: 

     "It must be your code!"

    My reply:

     "No, it's Java." Java slowness has been a pattern for too long for it to be "the code."

     

     

    Just because you have been around people that write bad and slow Java code doesn't mean that that's how it has to be.  

     

    As far as 3D applications, I've seen a couple. 



  • @GeneWitch said:

    The thing that i don't like about java and .NET is the same thing that i like about it. If i want to send a friend a java app (or VB.net, or C#) that i have made, they have to have the same (or higher) version of whatever virtual machine or framework i used. It eliminates the need for me to compile 10 different binaries, i never have to release the source code, but it makes it a pain to the people i know on dialup, and the non-tech savvy friends and family i have. BUT! after they have the framework, i can send them a 40K application that is as powerful as some 2 meg application that has everything compiled in already.

    This is true for any language that doesn't compile to native binaries.

    @GeneWitch said:

    And if i am remembering correctly, you can almost assert that the user experience is going to be the same on all platforms with java, right?

    left @GeneWitch said:

     I know why people hate Java, it's mostly because it isn't C++. I don't think you'll find many people who say java really really sucks who don't also know C++ and possibly C.

    I strongly disagree with that statement, some people may hate java because it's not C++ or C, but many others don't like it because it's not Python, or Ruby, or Erlang, or ObjectiveC, or OCaml, or Smalltalk, or Common Lisp.



  • @ammoQ said:

    @alexjag33 said:

    Oh I forgot one:

    6. Java gurus always reply the same to #3 with: 

     "It must be your code!"

    My reply:

     "No, it's Java." Java slowness has been a pattern for too long for it to be "the code."

    IMO much of Java's perceived slowness comes from the abundance of frameworks and "best practices". 

    Much of it comes from the fact that Java bytecode is typically interpreted. Yes, I know that there's a JIT engine. It's turned off by default in the JRE used for desktop apps and almost nobody knows how to turn it on. If you take the regular Sun JRE, compile some java code with javac/jikes, and run it with 'java class', no JIT will occur (unless the java code does various evil things).

    The rest is mostly because Java code tends to be quite wasteful of memory. This is caused by a combination of a fairly inefficient object model, a standard library that encourages the creation of many objects, and transparent memory allocation that causes programmers to not think about memory usage. A typical Java program uses several times more memory than the equivalent C program. That makes it run through the CPU cache faster, slowing the whole thing down. Frameworks and best practices tend to make this much worse than it already is, because all the extra object baggage chews up memory space.



  • @asuffield said:

    Much of it comes from the fact that Java bytecode is typically interpreted. Yes, I know that there's a JIT engine. It's turned off by default in the JRE used for desktop apps and almost nobody knows how to turn it on. If you take the regular Sun JRE, compile some java code with javac/jikes, and run it with 'java class', no JIT will occur (unless the java code does various evil things)

    Unless I've missed something, this is not true since Java 1.3. 


    The rest is mostly because Java code tends to be quite wasteful of memory. This is caused by a combination of a fairly inefficient object model, a standard library that encourages the creation of many objects, and transparent memory allocation that causes programmers to not think about memory usage. A typical Java program uses several times more memory than the equivalent C program. That makes it run through the CPU cache faster, slowing the whole thing down. Frameworks and best practices tend to make this much worse than it already is, because all the extra object baggage chews up memory space.

    I won't argue that point. 



  • @ammoQ said:

    @asuffield said:

    Much of it comes from the fact that Java bytecode is typically interpreted. Yes, I know that there's a JIT engine. It's turned off by default in the JRE used for desktop apps and almost nobody knows how to turn it on. If you take the regular Sun JRE, compile some java code with javac/jikes, and run it with 'java class', no JIT will occur (unless the java code does various evil things)

    Unless I've missed something, this is not true since Java 1.3. 

    Right, slight misstatement. In that scenario, some JIT might occur, but most of the program will be interpreted and the JIT optimizer will never be used - it's just like compiling C code without any -O arguments. The essential point remains: it's bloody slow.

    If you want java code to run at speeds comparable to C, you need to run it differently. Most people who use java don't know about this. So most java applications run horribly slow.

    (If you're using tomcat or something like that, things are different and more complicated; this applies only to desktop java)



  • @GeneWitch said:

    @ammoQ said:

    IMO much of Java's perceived slowness comes from the abundance of frameworks and "best practices". 

    I agree with you here. i've used several "commercial grade" java apps, and they all ran just fine. Azureus is a really good example of a really well designed java app that doesn't run "slow"

    Actually, Azureus is perhaps the most languid and sluggish of all current torrent clients (this is not to say that it lacks in features). In fact, checking the hundreds of peers connected to my seeds atm Azureus is less common than uTorrent, Mainline and BitComet where uTorrent is by far the most popular client. uTorrent also happens to be most CPU- and memory efficient one, and incidentally coded in C++ and compiled to a native binary. (That might change soon, though, since it has been purchased bit the original BitTorrent band and will be reworked into the backbone of syndicate and Hollywood controlled digital  media distribution, and as such will be pumped full of DRM and ads). Also, Azureus has been under heavy flak for some years for being creeping featuratis-ridden bloatware, which ironically mirrors the same common criticism directed at Java.

    Now mind you, i've never seen anything 3d done in java, or similar applications that require a ton of real-time DSP or anything like that... but if you're writing stuff like that you wouldn't want java anyhow since java isolates itself from the hardware by default (right?)

    There are a few Java3D packages, but in my limited experience they are mostly abstractions sitting on top of native 3D APIs (OpenGL and/or D3D), and as such in fact platform- and hardware dependent.  

    I know why people hate Java, it's mostly because it isn't C++. I don't think you'll find many people who say java really really sucks who don't also know C++ and possibly C.

    You might think so from the pathetic language wars raging all the time. However, you'll find that most good programmers base their preferences on language capabilities and facilities relative to what problems they need to address. Thus the good C++ programmers who don't like Java does so because of Java's restricted set of facilities. The BAD, irrelevant, programmers base their "preferences" on prejudices, and there are as many bad seeds or more among the Java crew that there are among C++ coders (though there are most among VB victims).



  • There appear to be any number of reasons why Java is disliked, and, if I may, I'd like to add one more to the mix.

    Good programming practise involves dividing a software up into discrete pieces, such as functions, objects, modules and so forth. This technique is sometimes known as factoring, and there are many different ways this can be achieved, some better than others. The better a program is factored, the more pieces of code can be reused, and the less effort expended. Intelligently factoring software is the main thing that divides good software from bad.

    Programming languages differ on how well they can factor programs, and how easily this can be achieved. Java is near the bottom of the pile, as it provides relatively few syntactical constructs to facilitate factoring. I'll provide an example; lets say you want to write a method to find the sum of a list, and a method to find the product of a list. In Java:

    int sum(List<int> xs) {
    int total = 0;
    for (int x : xs)
    total += x;
    return total;
    }
    int product(List<int> xs) {
    int total = 1;
    for (int x : xs)
    total *= x;
    return total;
    }</int></int>

    Now, these functions are very similar, and one might think, well, is there a way of factoring out the common code? Unfortunately, you can't do this in Java without generating more code than the original solution:

    interface Functor<T> {
    T invoke(T x, T y);
    }

    int reduce<T>(List<T> xs, Functor<T> f, T start) {
    T total = start;
    for (T x : xs)
    total = f(total, x);
    return total
    }

    int sum(List<int> xs) {
    return reduce(xs, new Functor<int>() {
    invoke(int x, int y) {
    return x + y;
    }
    }, 0);
    }

    int product(List<int> xs) {
    return reduce(xs, new Functor<int>() {
    invoke(int x, int y) {
    return x * y;
    }
    }, 1);
    }</int></int></int></int></T></T></T></T>

    Now lets see what the same functionality would look like in Haskell; first the original, unfactored version:

    sum [] = 0
    sum x:xs = x + (sum xs)

    product [] = 1
    product x:xs = x * (product xs)

    Well, it's already significantly shorter than the Java version, demonstrating Java's verboseness and lack of type checking. But what observe what happens when it is refactored:

    reduce f [] s = s
    reduce f x:xs s = f (reduce f xs s) x

    sum = reduce (+) 0
    product = reduce (*) 1

    Notice that in Haskell, refactoring these functions are possible. Our sum and product functions have been reduced from two lines down to one. This example is trivial, but for more complex systems, the language constructs of Haskell can result in programs factored much more efficiently than would be possible in Java. This is why programming in Java can be a very frustrating experience, because as a good programmer, you want to avoid repeating yourself, but Java's limited syntax often makes the alternatives even more verbose and costly. Java has a large standard library, and a very optimised virtual machine, but as a language, it lacks the power that other programming languages can provide.

    And that's why I dislike programming in Java.



  • Weave Jester,

    While I won't refute what you suggest (that Java is overly verbose and sorely lacking in many places) I would like to point out that your comparison isn't perhaps completely fair.  You are comparing Java to Haskell, a functional language, in an arena where Haskell is sure to blow Java out of the water.  The example you give is a text-book case of why first-class functions are a good thing.  First-class functions are Haskell's bread-and-butter.  Java does not support them.  The single-method interface is a kludge for first-class functions (one I personally dislike).

     I agree with a lot of what you say but I think you are comparing apples and oranges. 

    Your example illustrates why first-class functions are extremely powerful and why it is unfortunate that Java does not support them, but this comparison would hold for any other functional language.  I agree with most of your assertions and just thought it might be worth pointing out that this is a defficiency of many imperative languages when compared to any functional language and is not limited to the  Java and Haskell example.

     

     



  • @variableName said:

    Your example illustrates why first-class functions are extremely powerful and why it is unfortunate that Java does not support them, but this comparison would hold for any other functional language.  I agree with most of your assertions and just thought it might be worth pointing out that this is a defficiency of many imperative languages when compared to any functional language and is not limited to the  Java and Haskell example.

    First class functions aren't limited to functional languages. Python supports them. Ruby supports them. Perl supports them. Javascript supports them. Hell, even C# supports them via anonymous delegates, and 3.0 has some nice sugar to make the whole process rather more concise. And it's not like its a limitation of the JVM, as every other JVM-based language I can think of (Scala, Groovy, Nice, JRuby, Jython, Kawa) supports first class functions as well.

    The lack of first class functions in Java is, essentially, a choice by the designers to intentionally limit the functionality of the language.
     



  • @Weave Jester said:

    Well, it's already significantly shorter than the Java version, demonstrating Java's verboseness and lack of type checking. But what observe what happens when it is refactored:

    reduce f [] s = s
    reduce f x:xs s = f (reduce f xs s) x

    sum = reduce (+) 0
    product = reduce (*) 1

    I don't know Hasell, but this example seems a bit strange to me. The first parameter to "reduce" is the functor, the second parameter is the list, the third parameter is the start value... or isn't it?

    I'd rather expect something along the lines of...

     

    reduce f s [] = s
    reduce f s x:xs = f x (reduce f s xs)

    sum = reduce 0 (+)
    product = reduce 1 (*)

    Can you enlighten me?



  • @ammoQ said:

    I don't know Hasell, but this example seems a bit strange to me. The first parameter to "reduce" is the functor, the second parameter is the list, the third parameter is the start value... or isn't it?

    You're right, of course. Since Haskell already has a function like this (foldl), I used "reduce" as a name instead, which is what the equivalent function is called in Python. Because the start parameter is optional in Python's reduce function, it is also the final parameter. I suppose I used Python's parameter ordering out of (bad) habit.

    Of course, the whole function isn't really that good of an example, because it's not tail recursive (the last function called is f, rather than reduce). A better way to write it would be:

    reduce f s [] = s
    reduce f s x:xs = reduce f (f s x) xs

    Which is essentially the same as the definition for foldl defined in the Haskell prelude. However, despite poor execution, my point remains the same :)
     



  • @GeneWitch said:

    The thing that i don't like about java and .NET is the same thing that i like about it. If i want to send a friend a java app (or VB.net, or C#) that i have made, they have to have the same (or higher) version of whatever virtual machine or framework i used.
    I agree this is a frustrating problem with Java. Upgrading Java doesn't seem to go as smoothly as it should.

    For example, they seem to have problems with versioning at Sun. The site is horribly maintained and finding the version of the JDK or JRE that I'm looking for is a nightmare. Apparently there is an update to the JDK 6 (although it's not really 6, is it, it's 1.6.0 WTFWTFWTFWTFWTFWTF) called update 1 or JDK 1.6.0_01 or something. I'm not entirely sure - again, their versioning system is all messed up.

    In any case, it is supposed to fix some of the GUI problems with Java applications used with compiz window decorator. Thankfully I should have a link to it in a conversation history somewhere or I would never find it because Sun Microsystems have a horribly designed site.

    As far as the .NET framework is concerned I have to disagree here. I don't have a whole lot of experience releasing .NET projects, but if you have a legal copy of Windows you shouldn't have a problem with updating frameworks. If your users don't have a legal copy that is their problem - tell them to get a Linux distro if they aren't willing to pay for Windows. There is free software for everything in Linux, though some might not be as reliable as a Microsoft equivalent is.

    If you're using .NET applications in Linux with Mono or something I would say that you shouldn't expect to get full support there. I thought it was more of a hack than an official product, even though apparently Microsoft is supposed to be assisting them somewhat now.

    To summarize, Java versioning is retarded, but the .NET framework seems to be a great design.



  • @Bob Janova said:

    - GUI applications (which is what we all use most of the time) are slow to start and slow to paint, and don't fit in with other apps on any system.

    Slow to start? EVERY Swing app starts up in less than one second for me. On a 1.5 GHz machine.

    The "Java is slow" troll is so old I shouldn't even bother with it. If your Swing app is slow it's because you suck. Stop doing I/O in the AWT event dispatch thread.



  • That's a good point.  I have seen a lot of Java GUIS that felt really slow because the application was doing debugging output and logging in the UI thread.



  • @tster said:

    That's a good point.  I have seen a lot of Java GUIS that felt really slow because the application was doing debugging output and logging in the UI thread.

    Hmm, interesting and food for thought... Let's accept for tha argument that Java programs are not necessarily slow per se, and yet we see so many excruciatingly slow Java apps. Then, if it is not Java in itself that is slow but the phenomenon undeniably still is widespread, it must rather be that Java invites suboptimal programming manners. More fodder for the lacking-RAII side, perhaps.



  • @Mikademus said:

    @tster said:

    That's a good point.  I have seen a lot of Java GUIS that felt really slow because the application was doing debugging output and logging in the UI thread.

    Hmm, interesting and food for thought... Let's accept for tha argument that Java programs are not necessarily slow per se, and yet we see so many excruciatingly slow Java apps. Then, if it is not Java in itself that is slow but the phenomenon undeniably still is widespread, it must rather be that Java invites suboptimal programming manners. More fodder for the lacking-RAII side, perhaps.

     Paul Graham would agree with you.
     



  • Another reason for the pile of why Java tends to be slow:

    A misguided attempt to compensate for the absence of parametric polymorphism in Java led to an interesting quirk in the way its type system handles arrays.

    The array type X[] is a subtype of Y[] if the type X is a subtype of Y.

    This is not normal for a type-safe language. Here's the problem:

    class Top {
    }
    class Sub extends Top {
    public int a;
    }
    Sub[] subs = new Sub[1];
    Top[] tops = subs; // this is legal, Sub[] is a subtype of Top[]
    tops[0] = new Top;
    return subs[0].a; // fault, we've just accessed member 'a' in an object of type Top

    In order to restore type safety here, Java disallows the statement "tops[0] = new Top". This requires it to perform a run-time type check. The result: every store to any array (except arrays of primitive and final types) requires a run-time type check. This does horrible things to the performance of inner loops that involve array stores and there's no way to work around it - it's a flaw in the design of the type system, and it cannot be fixed without breaking compatibility with existing Java code.



  • @asuffield said:

    Another reason for the pile of why Java tends to be slow:

    A misguided attempt to compensate for the absence of parametric polymorphism in Java led to an interesting quirk in the way its type system handles arrays.

    The array type X[] is a subtype of Y[] if the type X is a subtype of Y.

    This is not normal for a type-safe language. Here's the problem:

    class Top {
    }
    class Sub extends Top {
    public int a;
    }
    Sub[] subs = new Sub[1];
    Top[] tops = subs; // this is legal, Sub[] is a subtype of Top[]
    tops[0] = new Top;
    return subs[0].a; // fault, we've just accessed member 'a' in an object of type Top

    In order to restore type safety here, Java disallows the statement "tops[0] = new Top". This requires it to perform a run-time type check. The result: every store to any array (except arrays of primitive and final types) requires a run-time type check. This does horrible things to the performance of inner loops that involve array stores and there's no way to work around it - it's a flaw in the design of the type system, and it cannot be fixed without breaking compatibility with existing Java code.

    This is bad, really bad. At least they avoided this mistake with the Generics introduced in Java5...

    import java.util.Vector;
    class Top {
            public static void main(String[] args) {
                    Vector<Sub> subs = new Vector<Sub>();
                    Vector<Top> tops = subs;
                    tops.add(new Top());
                    System.out.println(subs.get(0).a);
            }
    }
    class Sub extends Top { public int a; }

    [erich@iTux ~]$ javac Top.java
    Top.java:5: incompatible types
    found   : java.util.Vector<Sub>
    required: java.util.Vector<Top>
                    Vector<Top> tops = subs;
                                       ^
    1 error
    [erich@iTux ~]$  

     

     



  • @ammoQ said:

    At least they avoided this mistake with the Generics introduced in Java5...

     

    Java Generics is a form of parametric polymorphism, so it would be insane to do the same thing there.

    The 'right' solution would have been to include something like Generics from the outset, rather than this misguided hack. The irony is that this is exactly the reason why the C++ standard library uses template containers for everything, and this was known at the time Java was created. I can't imagine what they were smoking.
     



  • About the slowness of Java. I think Eclipse (IDE mainly for Java development) is an good example I think. While it takes 15 seconds to start up, after that it's pretty fast. (2Ghz machine, Eclipse with a few plugins)

    At first I thoughed it wasn't that great, 15 seconds startup time for a silly text editor. Until I started to develop java applications with it. Realtime syntax checking (and not just a basic check but even paramater X at call Y is of the wrong type), autocompletion, refactoring, suggestions or syntax errors (variable X does not exist, add as private variable, class, etc...?). I've used quite some IDEs, but for usuability Eclipse for Java scores the highest at the moment.


Log in to reply