4 ms·

What are some examples of unneeded complexity?

by azth 5y ago

adgjlsfhk1 5y ago
All of it? For a specific example, try doing any functional programming in Java and compare it to pretty much any other language.
- 41b696ef1113 5y ago
  I am far from a Java guy, but that seems like a poor example. Functional programming is not in the wheelhouse of Java. In the same way, it would be unfair to criticize Haskell for its object-oriented style.
- aphexairlines 5y ago
  Java's not helpful for FP, but that's an odd example to bring up in a discussion about Go, which is also statement-oriented.
- azth 5y ago
  Incidentally, golang is much worse for FP.
- kaba0 5y ago
  It really is not that bad, and it is at least possible, both to incorporate it partly (stream api, immutable objects, especially with records) or go full-on with vavr.
doctor_eval 5y ago
While not strictly the language itself, I find the Java standard library API to be unnecessarily verbose, with often obtuse defaults. Go’s library is sometimes overly terse, but after having experienced both in production, I much prefer Go’s style. An example is one of the date parsing functions (I can’t remember details now) which will happily accept an invalid date string (eg 2021-02-35) and silently convert it to a valid date (2021-03-07) despite declaring a parsing Exception. You see, you only get the exception if you call setLenient(false) or if the date string can’t be coerced. For the life of me, I cannot think of a use case for this behaviour, and it certainly violates the principle of least surprise.
- blibble 5y ago
  the replacement for SimpleDateFormat/Calendar came with Java 8 (released in 2014)
  - doctor_eval 5y ago
    Sure, but it is an example of the kind of crappy APIs that littered Java for a long time.
    - hbogert 5y ago
      Crappy apis is not beholden to java. Have you looked at go's timer API? Try to re-use one without inadvertently causing a data race, or get wrong behaviour.
      - vips7L 5y ago
        Or any of go’s file api’s… https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
- eknkc 5y ago
  On the other hand, Go’s time format and parse logic is the biggest pile of shit I’ve ever seen in an API.
- kaba0 5y ago
  I think Java has one of the best standard libraries out of any language I used. Sure, it has its warts (but the Date class should really not be used anymore over its more modern replacements, which are again, really sane), but it doesn’t make you reach for third party dependencies at every turn, neither for lack of feature nor lack of performance. Sure, you can use hand-tuned collection libs, but it is very seldom needed.
deleted 5y ago
[deleted]
grey-area 5y ago
Inheritance.
- azth 5y ago
  Inheritance does have its place. I've seen verbose and error prone workarounds in golang due to its lack of inheritance.
  - grey-area 5y ago
    Even the author of Java, James Gosling, disagrees with you. https://www.infoworld.com/article/2073649/why-extends-is-evil.html https://www.infoworld.com/article/2073649/why-extends-is-evi... As to workarounds for inheritance in Go, that sounds like trying to write in another language but in Go, which is of course not advisable in any language.
    - azth 5y ago
      > Even the author of Java, James Gosling, disagrees with you. From the article: > Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible. Key words: preferable, and whenever possible. It's sometimes preferable to have inheritance and not possible to leave it out without unneeded extra complexity. Furthermore, nowadays interfaces in Java (as well as Kotlin, Scala, C# - all of which are much more expressive and have superior modeling capability than golang) can have default implementations, which increases their application even more and reduces the need for explicit inheritance. Not so in golang since interfaces cannot have default implementations there. > As to workarounds for inheritance in Go, that sounds like trying to write in another language but in Go, which is of course not advisable in any language. Not quite, it's just where having inheritance would have simplified the design, and improved readability.
      - grey-area 5y ago
        He quite clearly states in the article he would ‘leave out classes’ (i.e. implementation inheritance). You didn’t quote the clearest statement in the article, just preceding your excerpt!? Again on interfaces, sometimes less is more. Many people prefer the inverted interfaces of go, declared at point of use. It’s fine to prefer the opposite, but these are deliberate choices, not mistakes or failures. Re inheritance simplifying a design, it does the opposite in my experience, unless by simplify you mean hide program flow and state.

What are some examples of unneeded complexity?

by azth 5y ago

What are some examples of unneeded complexity?

All of it? For a specific example, try doing any functional programming in Java and compare it to pretty much any other language.

41b696ef1113 5y ago
I am far from a Java guy, but that seems like a poor example. Functional programming is not in the wheelhouse of Java. In the same way, it would be unfair to criticize Haskell for its object-oriented style.
aphexairlines 5y ago
Java's not helpful for FP, but that's an odd example to bring up in a discussion about Go, which is also statement-oriented.
azth 5y ago
Incidentally, golang is much worse for FP.
kaba0 5y ago
It really is not that bad, and it is at least possible, both to incorporate it partly (stream api, immutable objects, especially with records) or go full-on with vavr.

doctor_eval 5y ago

While not strictly the language itself, I find the Java standard library API to be unnecessarily verbose, with often obtuse defaults. Go’s library is sometimes overly terse, but after having experienced both in production, I much prefer Go’s style. An example is one of the date parsing functions (I can’t remember details now) which will happily accept an invalid date string (eg 2021-02-35) and silently convert it to a valid date (2021-03-07) despite declaring a parsing Exception. You see, you only get the exception if you call setLenient(false) or if the date string can’t be coerced. For the life of me, I cannot think of a use case for this behaviour, and it certainly violates the principle of least surprise.

blibble 5y ago
the replacement for SimpleDateFormat/Calendar came with Java 8 (released in 2014)
- doctor_eval 5y ago
  Sure, but it is an example of the kind of crappy APIs that littered Java for a long time.
  - hbogert 5y ago
    Crappy apis is not beholden to java. Have you looked at go's timer API? Try to re-use one without inadvertently causing a data race, or get wrong behaviour.
    - vips7L 5y ago
      Or any of go’s file api’s… https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-ride https://fasterthanli.me/articles/i-want-off-mr-golangs-wild-...
eknkc 5y ago
On the other hand, Go’s time format and parse logic is the biggest pile of shit I’ve ever seen in an API.
kaba0 5y ago
I think Java has one of the best standard libraries out of any language I used. Sure, it has its warts (but the Date class should really not be used anymore over its more modern replacements, which are again, really sane), but it doesn’t make you reach for third party dependencies at every turn, neither for lack of feature nor lack of performance. Sure, you can use hand-tuned collection libs, but it is very seldom needed.

deleted 5y ago

[deleted]

grey-area 5y ago

Inheritance.

azth 5y ago
Inheritance does have its place. I've seen verbose and error prone workarounds in golang due to its lack of inheritance.
- grey-area 5y ago
  Even the author of Java, James Gosling, disagrees with you. https://www.infoworld.com/article/2073649/why-extends-is-evil.html https://www.infoworld.com/article/2073649/why-extends-is-evi... As to workarounds for inheritance in Go, that sounds like trying to write in another language but in Go, which is of course not advisable in any language.
  - azth 5y ago
    > Even the author of Java, James Gosling, disagrees with you. From the article: > Interface inheritance (the implements relationship) is preferable. You should avoid implementation inheritance whenever possible. Key words: preferable, and whenever possible. It's sometimes preferable to have inheritance and not possible to leave it out without unneeded extra complexity. Furthermore, nowadays interfaces in Java (as well as Kotlin, Scala, C# - all of which are much more expressive and have superior modeling capability than golang) can have default implementations, which increases their application even more and reduces the need for explicit inheritance. Not so in golang since interfaces cannot have default implementations there. > As to workarounds for inheritance in Go, that sounds like trying to write in another language but in Go, which is of course not advisable in any language. Not quite, it's just where having inheritance would have simplified the design, and improved readability.
    - grey-area 5y ago
      He quite clearly states in the article he would ‘leave out classes’ (i.e. implementation inheritance). You didn’t quote the clearest statement in the article, just preceding your excerpt!? Again on interfaces, sometimes less is more. Many people prefer the inverted interfaces of go, declared at point of use. It’s fine to prefer the opposite, but these are deliberate choices, not mistakes or failures. Re inheritance simplifying a design, it does the opposite in my experience, unless by simplify you mean hide program flow and state.