I would argue that the closes thing you get to type classes in OO languages are interfaces. The concept of an interface is also a pattern though, but it's so tightly integrated in most OO languages these days that you hardly think of it as a pattern anymore (just like you rarely think if inheritance as a pattern). An interface in the OO world is usually a set of function that any type who implements the interface is expected to provide. Same thing with type classes in Haskell. As for the monad pattern feeling strange for imperative (and OO programmers), the pattern is actually used quite a lot even in the OO domain, but one rarely talks if it using that name. A very clear example of this is the Task class used for asynchronous operations in C#. It has both the bind operation (Task.ContinueWith) and return (Task.FromResult) and captures the sequential nature of operations that is exactly what the monad type class is used for in Haskell. On Thu, Jun 2, 2016 at 7:30 AM, Dennis Raddle wrote:

I have been using Haskell on and off, as a hobbyist, for five years. I haven't been diligent in training myself on it, so I am learning slowly. It was confusing at first, coming from an imperative background.

It occurred to me the other day that Haskell typeclasses are a kind of "design pattern." They identify a common pattern and provide a solution. I've been reading about design patterns in C++ for years. Haskell patterns are a twist on that.

The imperative view looks at a task in a certain way, often conceiving of it as steps that mimic how human thoughts would go, and finding big general patterns that occur in different big applications.

I don't want to speak for all of Haskell, but at least some Haskell patterns are smaller-scale and more attuned to the language of programming rather than the language of human thought.

For instance, the Monad. The common use case is this---you have some "things," and you have a "container" that can accept more than one type of "thing." The common patterns are

- you need to wrap things in the container - you need to unwrap things - you need to modify things while in their container - you have functions that operate on containers - you have functions that operate on the things, but maybe you don't want to unwrap them first. or maybe you do.

To an imperative programmer, this is bizarre. What things are you talking about? What containers? You have not defined either one, so why can you say anything specific? Why all this emphasis on wrapping and unwrapping?

Yet this is a design pattern all the same. It gets weird when you realize that the Maybe monad, conceived in human-thought terms, has totally different behavior than the list monad. Yet they are the same design pattern and have a relationship that is more concisely expressed mathematically than in human thought.

The abundance of operators for wrapping/unwrapping/operating seems, if I understand right, closely related to the conciseness of Haskell. If you can use your containers without unwrapping them first, then by all means you don't want extra syntax just to do so. Same if you have functions that only operate on unwrapped things.

Haskell patterns are "lightweight" also helping with the conciseness. The closest thing to a "container" in C++ is a class, which is a dozen times heavier than a Functor, Applicative, or Monad. Actually you really need a "template class" which is like a tank compared to Functor which is a skinny guy fighting with a short knife (who can usually get the job done just fine, thank you).

Any comments welcome. I'm just trying to get a good perspective on Haskell.

Mike

_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

-- Mvh Øystein Kolsrud