[Haskell-beginners] Haskell and design patterns
Alex Rozenshteyn
rpglover64 at gmail.com
Thu Jun 2 16:01:53 UTC 2016
Sounds reasonable. A few comments:
Avoid the temptation to think of monads as "containers" as much as
possible, some containers aren't monads (Set, for example) and many monads
aren't containers (IO, Reader, Writer, State, etc.).
As I understand "design pattern"s, they are approaches to solving problems
that cannot be completely abstracted away. In that sense, "monad"s are no
stranger a design pattern than "visitor".
Some resources (many of which could be found by searching for "haskell
design patterns", but which I personally found interesting):
Design patterns for functional strategic programming
<https://scholar.google.com/scholar?cluster=4442103092796807160&hl=en&as_sdt=0,21>
(discusses
patterns which are found in functional programming)
http://blog.ezyang.com/2010/05/design-patterns-in-haskel/ (relates the
original GoF patterns to Haskell alternatives)
http://www.haskellforall.com/2012/08/the-category-design-pattern.html
http://www.haskellforall.com/2012/09/the-functor-design-pattern.html
(more design principles than design patterns, IMO, but good, clear reads)
http://dev.stephendiehl.com/hask/ (an all around amazing resource of
curated material)
On Thu, Jun 2, 2016 at 1:30 AM Dennis Raddle <dennis.raddle at gmail.com>
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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/beginners/attachments/20160602/4497e87e/attachment.html>
More information about the Beginners
mailing list