4 ms·

One of the hotly debated aspects of java is that even with java 8 additions the language is fairly simple and there really aren't that many ways to express the

by vitalyd 11y ago

One of the hotly debated aspects of java is that even with java 8 additions the language is fairly simple and there really aren't that many ways to express the same thing.

sacado2 11y ago
Hmm... Java's reference manual is about 800 pages long. That is close to Ada's reference manual, and Ada is quite a hard to grok language, and its reference very exhaustive, by design. It is bigger than C++14's ISO reference, which is fun considering Java was marketed as "much simpler than C++". Overall, Java is not an arcane language, but it has many, many gotchas and mixing new concepts with old design decisions only increases the number of gotchas.
- pron 11y ago
  The spec is long because it's very, very detailed (probably more than any other language spec out there). Also, Java doesn't allow any undefined behavior under any circumstance. It is much, much simpler than C++.
  - lmm 11y ago
    There are also lots of awkward edge cases where Java specifies something just as complex as a more general language feature, that's then only used in one tiny case. E.g. Java has a specification of type inference - that's used only for anonymous classes. And another, more limited form of inference that's applied to generics. Java has a syntax for union types - that can only be used in catch clauses - and generic type bounds have their own parallel syntax and rules. Language constructs are inconsistent (braces are mandatory around the body of a try or a function, but not an if or while). A lot of parts of the specification need special-casing for primitive types and/or arrays, which most languages handle in a more unified way (e.g. accessing the length of an array via reflection is unlike any other method or field access).
    - pron 11y ago
      So what? A language's complexity is measured (by developers) as the mental effort required to learn and read it -- not by the regularity of the grammar. Java is a relatively very simple language (for a statically typed one) -- even with its corner cases. It's certainly more complex than C and a little more than Go, but it's much simpler than C++, C#, Scala, Ada, Rust, Haskell, OCaml and pretty much every other statically typed language out there with more than 1000 users.
      - lmm 11y ago
        These aren't just theoretical grammar issues. Every beginner struggles with when you use == and when you use .equals(), or the differences between casting primitives and casting objects. I've witnessed even very experienced developers get confused reading generic bounds, or fail to take advantage of multi-catch or generics inference. All I can say for your comparisons is that I disagree with many of them.
        pron 11y ago
        > Every beginner struggles with when you use == and when you use .equals(), or the differences between casting primitives and casting objects. I actually agree with those points (though Java is still very simple), but there's an obvious reason: that's the exact same behavior as in C++ (unless you start playing with operator overloading), and any other behavior would have looked surprising or strange to people coming over from C/C++, which was basically everyone who learned Java in its first 10 years. The same goes for the fallthrough switch statement. Generic bounds indeed completely go against the language's design goals, but failing to take advantage of multicatch or generic inference (or lambda inference) is not a problem[1]. Java is a language designed for ease of reading (it says so right in its design documents), and for large teams/project, so code is made to look uniform, with all "advanced" features being local and obvious to anyone reading them. The goal was to make every new developer on your team (people working on large projects move around a lot) immediately able to read the code and not have to learn the team's DSL or coding style. Those were the problems that plagued C++ (alas, they only became apparent years after C++ had been in widespread use, and cost the industry billions), and Java very successfully avoided. Go has adopted the same design philosophy. [1]: Not that it's important, but every Java IDE would automatically suggest the shortened syntax. Java IDEs even automatically convert loops to streams.
- reagency 11y ago
  C++ reference would be longer if it had to define behavior for all the currently undefined cases.

by vitalyd 11y ago

One of the hotly debated aspects of java is that even with java 8 additions the language is fairly simple and there really aren't that many ways to express the same thing.

sacado2 11y ago

Hmm... Java's reference manual is about 800 pages long. That is close to Ada's reference manual, and Ada is quite a hard to grok language, and its reference very exhaustive, by design. It is bigger than C++14's ISO reference, which is fun considering Java was marketed as "much simpler than C++". Overall, Java is not an arcane language, but it has many, many gotchas and mixing new concepts with old design decisions only increases the number of gotchas.

pron 11y ago
The spec is long because it's very, very detailed (probably more than any other language spec out there). Also, Java doesn't allow any undefined behavior under any circumstance. It is much, much simpler than C++.
- lmm 11y ago
  There are also lots of awkward edge cases where Java specifies something just as complex as a more general language feature, that's then only used in one tiny case. E.g. Java has a specification of type inference - that's used only for anonymous classes. And another, more limited form of inference that's applied to generics. Java has a syntax for union types - that can only be used in catch clauses - and generic type bounds have their own parallel syntax and rules. Language constructs are inconsistent (braces are mandatory around the body of a try or a function, but not an if or while). A lot of parts of the specification need special-casing for primitive types and/or arrays, which most languages handle in a more unified way (e.g. accessing the length of an array via reflection is unlike any other method or field access).
  - pron 11y ago
    So what? A language's complexity is measured (by developers) as the mental effort required to learn and read it -- not by the regularity of the grammar. Java is a relatively very simple language (for a statically typed one) -- even with its corner cases. It's certainly more complex than C and a little more than Go, but it's much simpler than C++, C#, Scala, Ada, Rust, Haskell, OCaml and pretty much every other statically typed language out there with more than 1000 users.
    - lmm 11y ago
      These aren't just theoretical grammar issues. Every beginner struggles with when you use == and when you use .equals(), or the differences between casting primitives and casting objects. I've witnessed even very experienced developers get confused reading generic bounds, or fail to take advantage of multi-catch or generics inference. All I can say for your comparisons is that I disagree with many of them.
      - pron 11y ago
        > Every beginner struggles with when you use == and when you use .equals(), or the differences between casting primitives and casting objects. I actually agree with those points (though Java is still very simple), but there's an obvious reason: that's the exact same behavior as in C++ (unless you start playing with operator overloading), and any other behavior would have looked surprising or strange to people coming over from C/C++, which was basically everyone who learned Java in its first 10 years. The same goes for the fallthrough switch statement. Generic bounds indeed completely go against the language's design goals, but failing to take advantage of multicatch or generic inference (or lambda inference) is not a problem[1]. Java is a language designed for ease of reading (it says so right in its design documents), and for large teams/project, so code is made to look uniform, with all "advanced" features being local and obvious to anyone reading them. The goal was to make every new developer on your team (people working on large projects move around a lot) immediately able to read the code and not have to learn the team's DSL or coding style. Those were the problems that plagued C++ (alas, they only became apparent years after C++ had been in widespread use, and cost the industry billions), and Java very successfully avoided. Go has adopted the same design philosophy. [1]: Not that it's important, but every Java IDE would automatically suggest the shortened syntax. Java IDEs even automatically convert loops to streams.
reagency 11y ago
C++ reference would be longer if it had to define behavior for all the currently undefined cases.