Hacker News Reader

Comment by willtim | Hacker News Reader

> 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).

View on HN

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.

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

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.

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.

And also using the java.util.concurrdent package sidesteps most foot-guns involving roll your own synchronization.

Perhaps most, but not all. Even something as simple as a date formatter in Java is not thread-safe.

That was fixed with the Java 8 package java.time.format, https://docs.oracle.com/javase/8/docs/api/java/time/format/D...

Ok bad example, but it shouldn't have taken them 15+ years to fix it.

SingletonFactory is an oxymoron.

Edit: oh wow, it actually exists

> 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.

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.

It's not just excessive abstraction, separating Singleton and SingletonFactory can even reduce encapsulation since you can't make the Singleton constructor private.

You can if it's in the same file.

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.

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.

Reply on news.ycombinator.com