6 ms·

> You think I'm done? Let's get to Lens. Lens is a library, not part of Haskell the language, it's also not particularly widely used. If you are going to confl

> You think I'm done? Let's get to Lens. Lens is a library, not part of Haskell the language, it's also not particularly widely used. If you are going to conflate the ecosystem with the language, then we could equally talk about the complexity of dependency injection frameworks, AbstractSingletonProxyFactoryBeans, aspect-oriented bytecode weaving, and enterprise Java beans when discussing how much "easier" Java programming is. I have programmed both Java and Haskell professionally on multiple codebases. I honestly found more ad-hoc and incidental complexity in the Java world. At least the Haskell libraries generally were consistent in the abstractions used. Java the language, also had a lot of hidden complexity, for example its memory model (required knowledge for concurrent programming).

karmakaze 7y ago
Not to refute your findings but it seems unfair to call commonly selected aberrations not hidden complexity and the Java memory model as such. The only things you can compare is the complexity inherent to the task vs that which is added by the choice of implementation which is subjective based on familiarity.
- willtim 7y ago
  I was calling out the Java memory model and concurrent programming in Java as being very complex. It's inherent to the language itself and almost impossible to change. I was only calling it "hidden" complexity as most people do not see an issue when writing single threaded programs. Concurrent programming I genuinely believe is easier in Haskell.
  - karmakaze 7y ago
    And also using the java.util.concurrdent package sidesteps most foot-guns involving roll your own synchronization.
    - willtim 7y ago
      Perhaps most, but not all. Even something as simple as a date formatter in Java is not thread-safe.
      - dropofwill 7y ago
        That was fixed with the Java 8 package java.time.format, https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html https://docs.oracle.com/javase/8/docs/api/java/time/format/D...
        willtim 7y ago
        Ok bad example, but it shouldn't have taken them 15+ years to fix it.
marcosdumay 7y ago
Yes, you should consider all of those when you talk about how hard Java is to learn. Java is a notoriously complex language and one should expect to put a lot of hours into learning it. Haskell has a different kind of difficulty. One must expect to feel dumb for a long time, because it's composed of hard concepts. Those are much simpler concepts, but they aren't any quicker to learn.
- auggierose 7y ago
  Understanding the Java memory model properly is not easier than anything Haskell throws at you.
glutamate 7y ago
SingletonFactory is an oxymoron. Edit: oh wow, it actually exists
- dragonwriter 7y ago
  > SingletonFactory is an oxymoron. It's not, you still need to create the one instance when it is first needed. It's possibly excessive abstraction, but it's not an oxymoron.
  - sidlls 7y ago
    I've come to believe that "excessive abstraction" is practically a synonym for "object oriented programming". It takes an incredible amount of discipline to not abstract unnecessarily in an OO shop.
  - anoncake 7y ago
    It's not just excessive abstraction, separating Singleton and SingletonFactory can even reduce encapsulation since you can't make the Singleton constructor private.
    - reificator 7y ago
      You can if it's in the same file.
- rumanator 7y ago
  A factory method returns instances, but there is no obligation for those instances to be created on demand or each time the function is called. Some Singleton implementations only initialize the Singleton object at first call, for example, and other implementation units the object at startup.
- jknoepfler 7y ago
  That's not oxymoronic at all. You have a Factory<T> interface. Depending on T and context, it may be reasonable to provide an implementation of Factory<T> that returns a singleton, something taken from an object pool, or a new instance of an object. I haven't worked in an IoC-heavy world for awhile, but a SingletonFactory is neither silly nor an anti-pattern.

karmakaze 7y ago

Not to refute your findings but it seems unfair to call commonly selected aberrations not hidden complexity and the Java memory model as such. The only things you can compare is the complexity inherent to the task vs that which is added by the choice of implementation which is subjective based on familiarity.

willtim 7y ago
I was calling out the Java memory model and concurrent programming in Java as being very complex. It's inherent to the language itself and almost impossible to change. I was only calling it "hidden" complexity as most people do not see an issue when writing single threaded programs. Concurrent programming I genuinely believe is easier in Haskell.
- karmakaze 7y ago
  And also using the java.util.concurrdent package sidesteps most foot-guns involving roll your own synchronization.
  - willtim 7y ago
    Perhaps most, but not all. Even something as simple as a date formatter in Java is not thread-safe.
    - dropofwill 7y ago
      That was fixed with the Java 8 package java.time.format, https://docs.oracle.com/javase/8/docs/api/java/time/format/DateTimeFormatter.html https://docs.oracle.com/javase/8/docs/api/java/time/format/D...
      - willtim 7y ago
        Ok bad example, but it shouldn't have taken them 15+ years to fix it.

marcosdumay 7y ago

Yes, you should consider all of those when you talk about how hard Java is to learn. Java is a notoriously complex language and one should expect to put a lot of hours into learning it. Haskell has a different kind of difficulty. One must expect to feel dumb for a long time, because it's composed of hard concepts. Those are much simpler concepts, but they aren't any quicker to learn.

auggierose 7y ago
Understanding the Java memory model properly is not easier than anything Haskell throws at you.

glutamate 7y ago

SingletonFactory is an oxymoron. Edit: oh wow, it actually exists

dragonwriter 7y ago
> SingletonFactory is an oxymoron. It's not, you still need to create the one instance when it is first needed. It's possibly excessive abstraction, but it's not an oxymoron.
- sidlls 7y ago
  I've come to believe that "excessive abstraction" is practically a synonym for "object oriented programming". It takes an incredible amount of discipline to not abstract unnecessarily in an OO shop.
- anoncake 7y ago
  It's not just excessive abstraction, separating Singleton and SingletonFactory can even reduce encapsulation since you can't make the Singleton constructor private.
  - reificator 7y ago
    You can if it's in the same file.
rumanator 7y ago
A factory method returns instances, but there is no obligation for those instances to be created on demand or each time the function is called. Some Singleton implementations only initialize the Singleton object at first call, for example, and other implementation units the object at startup.
jknoepfler 7y ago
That's not oxymoronic at all. You have a Factory<T> interface. Depending on T and context, it may be reasonable to provide an implementation of Factory<T> that returns a singleton, something taken from an object pool, or a new instance of an object. I haven't worked in an IoC-heavy world for awhile, but a SingletonFactory is neither silly nor an anti-pattern.