4 ms·

Reading this is frustrating because I agree with a lot of what the author is saying (that using dynamic languages can speed up initial development but incur fut

Reading this is frustrating because I agree with a lot of what the author is saying (that using dynamic languages can speed up initial development but incur future technical debt), but I think that Java has a huge number of issues that prevent it from being a language I'd want to use for a lot of tasks. Here are some examples, although since I haven't written Java in a while I could be inaccurate on some of them: - the use of the Object type (surprisingly common) - No first-class functions or function types. New Java has lambdas but I'm not sure if it has function types or the ability to pass a class or instance method as a first-class value - No higher-order types (e.g. The type of a map function, let alone an fmap function, can't be written) - Need for frequent casting is both inelegant and a big source of errors - Classes are giant, heavyweight and deeply stateful, and tend to have deeply nested hierarchies - Class-scoped variable names (E.g. That don't require explicit 'this') are confusing, and for example don't make it clear whether a variable being referenced is a class variable, instance variable or local variable. Creating inner classes complicates things further, and inherited variables and methods are also opaque - creation of new types is a pain which promotes overuse of primitives (ints/strings/bools) over more expressive and safe types - polymorphism via interfaces isn't particularly expressive, for example AFAIK you can't make a function which takes two arguments of the same type unless you specify that type precisely - null pointers are rampant, and even considered idiomatic, for example during initialization - imperative style is forced on the user in a very strong way; for example no literals for array lists, maps etc, standard library overwhelmingly provides mutable data structures. I could go on, but suffice it to say that the author's claim that the main complaint against Java is its verbosity is a red herring. It's also a bit disappointing to see him dismiss languages like Scala (and presumably languages like Ocaml and Haskell, which he doesn't even mention) due to being "complex", which suggests to me that he hasn't fully grasped his own lesson that putting the time and effort into a safer, more expressive and more strongly typed language is worth the initial trade off in productivity. Although the author claims that once their code compiles it usually runs without errors, this has definitely not been my experience. Indeed my biggest argument against Java is that due to its imperative nature and inexpressive type system, it's not that much safer than many dynamic languages, which makes it really hard for me to justify using it.

nunobrito 11y ago
We had a large project that depended on a library written in Haskell. One day the developer for that library quit his job. We sincerely couldn't find another Haskell developer, had to re-write the library in Java. Heck, I've tried hard to understand Haskell. Simply don't understand why someone goes through the effort of using that exotic language. The old library was taking 2 minutes to process input, the re-written version in Java took 3 seconds. Just keep it simple, use Java.
- catnaroek 11y ago
  There are very good reasons for using Java: portability, libraries and the JVM's performance. But simplicity really isn't amongst them. Even Featherweight Java (a carefully selected subset of Java for the purpose of proving theorems about it) is full of tricky details. That being said, yeah, Haskell's learning curve is quite steep, and writing high-performance code in it is kind of a black art.
catnaroek 11y ago
> It's also a bit disappointing to see him dismiss languages like Scala (and presumably languages like Ocaml and Haskell, which he doesn't even mention) due to being "complex" Hey, it's possible to dismiss Scala due to being “complex” (which is certainly is), and still like (or at least not dismiss) OCaml and/or Haskell. :-p
deleted 11y ago
[deleted]
Overlord_Dave 11y ago
From my perspective, a lot of the problems listed above are either because 'you're doing it wrong' (and awful excuse that could apply to any language) or are hangovers from previous Java versions. That said, I've addressed a few of your points from my own personal experience working with Java for the last 6 years (3 years professionally): > - the use of the Object type (surprisingly common) Doesn't appear common to me at all - the code base I work on has no declaration of anything as 'Object' anywhere in well over 300k lines. None of the 3rd-party libraries we use have the Object type in any of their public APIs. So from my experience this is a non issue, and I'm quite surprised it was mentioned. Then again, I do work on a relatively new (<4 yrs old) code base, recently moved to Java v1.8. In fact, probably the biggest offender of Object use is the Java built-in libraries, especially the Collections framework, parts of which are frustratingly not type-safe as a compatibility hangover from before generics were introduced. For a fun example, the map interface has put(K, V), but get(Object). Grrr! > - Need for frequent casting is both inelegant and a big source of error Again, the code base I work on has very little casting. I feel like this is more a symptom of how code has been designed rather than an inherent issue with the language. Once more possibly a hang-over from the pre-generics days. > - Classes are giant, heavyweight and deeply stateful, and tend to have deeply nested hierarchies This seems a bit subjective, so I'd say you might be writing/using classes badly. How does Java differ from any other OO language in this respect? And remember the words of The Great Joshua Bloch: always favour composition over inheritance! > - Class-scoped variable names (E.g. That don't require explicit 'this') are confusing, and for example don't make it clear whether a variable being referenced is a class variable, instance variable or local variable. Creating inner classes complicates things further, and inherited variables and methods are also opaque A moot point when using a modern IDE as far as I see it. But certainly a concern if syntax highlighting isn't available. > - creation of new types is a pain which promotes overuse of primitives (ints/strings/bools) over more expressive and safe types How/why exactly is this a pain? Related to the verboseness, perhaps? And certainly in the code I work on I wouldn't consider primitives over-used at all. Don't forget the Java enum, one of the best features of the language, can quickly be put together and contain as much extra information/functionality as you'd like. We certainly use them frequently. > - null pointers are rampant, and even considered idiomatic, for example during initialization If null pointers are this rampant, then again the code must be badly designed or doing something wrong. Null pointers are probably the least common issue we get in our code base. Of course I can only speak for myself. The Optional in Scala does sound like a brilliant feature, but doesn't demonstrate why Java is any worse than other non-Scala OO languages (here's looking at you C#). > - imperative style is forced on the user in a very strong way; for example no literals for array lists, maps etc, standard library overwhelmingly provides mutable data structures I can't argue with this. Mutibility in the standard libraries isn't great and parts of it certainly could do with a re-write (which worked out totally fine for Python, amiright?) and generally there are few few 'correct' ways to write anything (I'm ignoring the monstrosity that is Java EE here). But this is an aspect of the language I actually really like. I like the verboseness, I like the lack of ambiguity, and I like that all well-written Java code looks remarkably similar. If dev teams enforce strict (and at least partially arbitrary) style rules, what's wrong with the language doing it for you? If you think that's a bad thing then I'd be very interested to hear your reasoning.

nunobrito 11y ago

We had a large project that depended on a library written in Haskell. One day the developer for that library quit his job. We sincerely couldn't find another Haskell developer, had to re-write the library in Java. Heck, I've tried hard to understand Haskell. Simply don't understand why someone goes through the effort of using that exotic language. The old library was taking 2 minutes to process input, the re-written version in Java took 3 seconds. Just keep it simple, use Java.

catnaroek 11y ago
There are very good reasons for using Java: portability, libraries and the JVM's performance. But simplicity really isn't amongst them. Even Featherweight Java (a carefully selected subset of Java for the purpose of proving theorems about it) is full of tricky details. That being said, yeah, Haskell's learning curve is quite steep, and writing high-performance code in it is kind of a black art.

catnaroek 11y ago

> It's also a bit disappointing to see him dismiss languages like Scala (and presumably languages like Ocaml and Haskell, which he doesn't even mention) due to being "complex" Hey, it's possible to dismiss Scala due to being “complex” (which is certainly is), and still like (or at least not dismiss) OCaml and/or Haskell. :-p

deleted 11y ago

[deleted]

Overlord_Dave 11y ago

From my perspective, a lot of the problems listed above are either because 'you're doing it wrong' (and awful excuse that could apply to any language) or are hangovers from previous Java versions. That said, I've addressed a few of your points from my own personal experience working with Java for the last 6 years (3 years professionally): > - the use of the Object type (surprisingly common) Doesn't appear common to me at all - the code base I work on has no declaration of anything as 'Object' anywhere in well over 300k lines. None of the 3rd-party libraries we use have the Object type in any of their public APIs. So from my experience this is a non issue, and I'm quite surprised it was mentioned. Then again, I do work on a relatively new (<4 yrs old) code base, recently moved to Java v1.8. In fact, probably the biggest offender of Object use is the Java built-in libraries, especially the Collections framework, parts of which are frustratingly not type-safe as a compatibility hangover from before generics were introduced. For a fun example, the map interface has put(K, V), but get(Object). Grrr! > - Need for frequent casting is both inelegant and a big source of error Again, the code base I work on has very little casting. I feel like this is more a symptom of how code has been designed rather than an inherent issue with the language. Once more possibly a hang-over from the pre-generics days. > - Classes are giant, heavyweight and deeply stateful, and tend to have deeply nested hierarchies This seems a bit subjective, so I'd say you might be writing/using classes badly. How does Java differ from any other OO language in this respect? And remember the words of The Great Joshua Bloch: always favour composition over inheritance! > - Class-scoped variable names (E.g. That don't require explicit 'this') are confusing, and for example don't make it clear whether a variable being referenced is a class variable, instance variable or local variable. Creating inner classes complicates things further, and inherited variables and methods are also opaque A moot point when using a modern IDE as far as I see it. But certainly a concern if syntax highlighting isn't available. > - creation of new types is a pain which promotes overuse of primitives (ints/strings/bools) over more expressive and safe types How/why exactly is this a pain? Related to the verboseness, perhaps? And certainly in the code I work on I wouldn't consider primitives over-used at all. Don't forget the Java enum, one of the best features of the language, can quickly be put together and contain as much extra information/functionality as you'd like. We certainly use them frequently. > - null pointers are rampant, and even considered idiomatic, for example during initialization If null pointers are this rampant, then again the code must be badly designed or doing something wrong. Null pointers are probably the least common issue we get in our code base. Of course I can only speak for myself. The Optional in Scala does sound like a brilliant feature, but doesn't demonstrate why Java is any worse than other non-Scala OO languages (here's looking at you C#). > - imperative style is forced on the user in a very strong way; for example no literals for array lists, maps etc, standard library overwhelmingly provides mutable data structures I can't argue with this. Mutibility in the standard libraries isn't great and parts of it certainly could do with a re-write (which worked out totally fine for Python, amiright?) and generally there are few few 'correct' ways to write anything (I'm ignoring the monstrosity that is Java EE here). But this is an aspect of the language I actually really like. I like the verboseness, I like the lack of ambiguity, and I like that all well-written Java code looks remarkably similar. If dev teams enforce strict (and at least partially arbitrary) style rules, what's wrong with the language doing it for you? If you think that's a bad thing then I'd be very interested to hear your reasoning.