In Praise of Haskell
drdobbs.com
In Praise of Haskell
1–5 of 5 posts
Re: In Praise of Haskell
#2I've long been a fan of functional languages, though I've found them wanting in any sort of production environment. This is mostly due to the lack of the compositional semantics that are needed for a team of four to six developers to simultaneously build an application or product.
How does Haskell address this issue?
Re: In Praise of Haskell
#3I've long been a fan of functional languages, though I've found them wanting in any sort of production environment. This is mostly due to the lack of the compositional semantics that are needed for a team of four to six developers to simultaneously build an application or product. How does Haskell address this issue?
What exactly do you mean by "compositional semantics"?
If you mean modularity, I've found Haskell to allow for more modularity than normal programs. Since you don't have side-effects everywhere, distant parts of your code are actually distinct and truly decoupled.
Haskell also makes it more natural to break your code up into small, self-contained modules; thanks to its type system, these modules tend to have well-defined interfaces that are easy for other people to use. It's surprisingly easy to write loosely-coupled code that works together.
Did you have something more specific in mind?
Re: In Praise of Haskell
#4I've long been a fan of functional languages, though I've found them wanting in any sort of production environment. This is mostly due to the lack of the compositional semantics that are needed for a team of four to six developers to simultaneously build an application or product. How does Haskell address this issue?
What exactly do you mean by "compositional semantics"? If you mean modularity, I've found Haskell to allow for more modularity than normal programs. Since you don't have side-effects everywhere, distant parts of your code are actually distinct and truly decoupled. Haskell also makes it more natural to break your code up into small, self-contained modules; thanks to its type system, these modules tend to have well-def…
Interfaces are the most salient feature on my mind. Secondarily, I really like Ruby meta-programming with it's ability to inject an anonymous class in the middle of the inheritance hierarchy. But Haskell isn't object oriented so I don't know how it might support such features.
Re: In Praise of Haskell
#5Earlier quoted context omitted.
What exactly do you mean by "compositional semantics"? If you mean modularity, I've found Haskell to allow for more modularity than normal programs. Since you don't have side-effects everywhere, distant parts of your code are actually distinct and truly decoupled. Haskell also makes it more natural to break your code up into small, self-contained modules; thanks to its type system, these modules tend to have well-def…
Interfaces are the most salient feature on my mind. Secondarily, I really like Ruby meta-programming with it's ability to inject an anonymous class in the middle of the inheritance hierarchy. But Haskell isn't object oriented so I don't know how it might support such features.
Haskell is fundamentally different from Ruby et al. It has plenty of features for achieving the same goals--say modularity--but there is no 1:1 mapping between those features and Ruby features. Or any OOP features at all.
Basically, you can do the same things but not necessarily in the same ways. For example, Haskell does not have any inheritance the way OO languages do, so that simply doesn't come up. This doesn't mean it's less capable--it just means it's different. Very different.
One example is interfaces: in Haskell, depending on the context, you might use the module system, typeclasses or even just normal types to accomplish the same things as an OOP interface. You can still organize your code in a similar way, but the actual mechanics are different. In fact, since Haskell allows you to explicitly control effects, you have more organizational power!
I hope this clears things up. Ultimately, the details of how you can organize things is going to vary per use case. Perhaps the easiest thing to do is just to pick up basic Haskell and see what larger Haskell programs look like.