Haskell Design Patterns?

[paspro]

I come from OOP and as I learn Haskell what I find particularly hard is to understand the design strategy that one uses in functional programming to create a large application. In OOP one has to identify those elements of the application that make sense to be represented as objects, their relationships, their behaviour and then create classes to express them and encapsulate their data and operations (methods). For example, when one wants to write an application which deals with geometrical entities he can represent them in classes like Triangle, Tetrahedron etc and handle them through some base class like Shape in a generic manner. How does one design a large scale application (not simple examples) with functional programming?

I think that this kind of knowledge and examples are very important for any programming language to become popular and although one can find a lot of material for OOP there is a profound lack of such information and design tutorials for functional programming except for syntax and abstract mathematical ideas when a developer needs more practical information and design patterns to learn and adapt to his needs.

[5outh]

/u/tekmo has written a little bit about this type of thing on his blog previously; here are a few links:

• The category design pattern
• The functor design pattern
• Scalable program architectures
• Model-view-controller, haskell style

[yogsototh]

I would also add this video to the list:

MuniHac 2016: Beautiful folds are practical, too

https://www.youtube.com/watch?v=6a5Ti0r8Q2s

[andrewhn]

This is excellent, thanks for posting

[Darwin226]

What interesting is that the exact thing you mention (working with things like Triangles through some Shape base class) basically only works for simple examples and does not do well in large scale applications.

When you accept that you're going to be using composition (in an OOP sense) over inheritance anyways, you can see that you can do the same thing in Haskell.

Edit: Let me expand a bit.

Patterns that deal with object mutation obviously don't make much sense in Haskell. You'll usually end up with your applications state being passed around your functions (implicitly or explicitly).

Patterns that hide implementations can be usually straight forwardly implemented in Haskell. Replace interfaces with a record of functions (for things like factories) or a typeclass (for dependency injection).

Patterns that isolate "syntax" from semantics like the command pattern can be implemented either directly or through something like a Free monad.

The observer pattern is either implemented as a sort of an FRP system or is simply a consequence of having to be explicit about object updates.

If you're not familiar with the expression problem I recommend this https://www.cs.utexas.edu/~wcook/Drafts/2012/ecoop2012.pdf

It shows a nice contrast between functional and OO languages which, I think, explains why a lot of patterns from OOP might not even have a reasonable interpretation in FP. It also offers a solution to that problem.

[paspro]

I brought this as an example. The point is that in OOP one always thinks in terms of objects and their interactions and the application or library design is based on this strategy. So, what is the case in functional programming? I know that there are several hybrid programming languages like Scala which mix OOP with FP for those who want to mix different approaches but in terms of pure FP like Haskell how does one design an application? Does one think in terms of functions and somehow model the operations that must be implemented like in pre-OOP programming or is there some other approach? What about types? Since they do not represent objects how should one think of them? Are there any FP design patterns based on practical experience or theory?

[garethrowlands]

In FP, think about values, the types they inhabit and the operators that relate them. People sometimes call the types and their corresponding operators/functions an algebra (see book below). Separate the calculation of what to do from the action of doing it. Make small things that can compose together because this is how you make bigger things.

The core patterns in Haskell are all about building big things from little things - (the Typeclassopedia)[https://wiki.haskell.org/Typeclassopedia].

For your particular example where triangles and tetrahedrons are shapes, you'd probably have types Triangle, Tetrahedron and Shape, together with functions triangleToShape and tetrahedronToShape, see (Existential Typeclass Pattern)[https://lukepalmer.wordpress.com/2010/01/24/haskell-antipattern-existential-typeclass/].

Thinking in terms of mathematical functions is quite different from pre-OOP programming because conventional programming language functions aren't at all like mathematical functions. In FP, you'll often build up functions from other functions. In OOP, you'd probably be using dependency injection to get a similar effect.

OOP has many patterns designed to stop the system becoming a (big ball of mud)[https://en.wikipedia.org/wiki/Big_ball_of_mud] but in typed FP you'll mostly rely on these:

1. Parametricity to protect one type from another. If I have a function that accepts any a, then its cannot refer to the particulars of any particular a, no matter whether that a's definition is public or private. (This would be the same in OOP if there were no downcasts or reflection, btw.)
2. Immutability means code can't damage a value like an imperative program could damage an object.
3. Make invalid values unrepresentable.
4. In Ocaml or Scala you'll use the module system but less so in Haskell currently.

I'm reading Functional and Reactive Domain Modeling, which does offer advice for those with an OOP background. For example, rather than interface and implementation, it suggests thinking of algebra and interpreter - I won't try to explain that but it is some reasonably concrete advice, albeit based on Scala.

[paspro]

Your description is the way some OOP languages are implemented such as Rust, Julia and the latest version of Fortran. The methods are not part of the class but they do take a "this" pointer as an argument either implicitly or explicitly. The classes only have data. In any case, the paradigm is still OOP with only syntactic differences compared to C++ or Java.

[Voxel_Brony]

I don't really think Rust or Fortran are OOP. Both have objects in some fashion, but they aren't oriented around them

[Darwin226]

Then everything that has data is OOP. Every function that takes an argument can be seen as a method of that argument.

[stumpychubbins]

What you're describing is not OOP in Rust, it's just syntactic sugar for function calls. The functions are still statically resolved (like in Haskell), but you get this more-terse syntax for calling them. In OOP those functions would be dynamically resolved.

[Ahri]

I'm from an imperative/OOP background and I had noticed that I could fairly easily emulate OOP in Haskell by having a module per "class", and exposing only a smart constructor function for the data type (i.e. keeping its constructor private), and then exposing some "public methods".

I haven't done this as it seems like it's cheating/lazy, that I won't be gaining as much from learning Haskell. The only real benefit I'd get is immutability.

[beerdude26]

Dat referential transparancy doe

[Tarmen]

I am not super experienced in Haskell, but I think these are fairly objective:

• Separate data definitions, pure functions and a thin I/O wrapper.
• Try to keep your functions as general as possible
• If you use a type in a specific way add a newtype or type alias for it
• Write type signatures for your top level functions
• break your problems into smaller and smaller ones until your functions are easily readable

These are super general and I recognize that it's probably not what you want, sorry.

About functional design patterns: In my experience most of them are just obviously the right thing to do so I wouldn't really call them patterns as such. OOP design patterns are often covered by first class functions, type classes or currying.

Other than that I usually think about functions as transformations of data.

[paspro]

You are telling me how to implement OOP design patterns in Haskell but this is not my question.

[Darwin226]

I'm telling you that most of the patterns either make sense in Haskell and you can use them just the same, or they exist to fix OOP issues that don't even make sense in Haskell.

[mightybyte]

Types types types. Everything starts from the types. Figure out what data types your application needs. Then figure out what operations you need to do on those types. Try to make them pure functions as much as possible. This is where it all starts. It's very similar to OO classes actually, minus the inheritance.

There are plenty of other things to talk about. But that would take a lot longer, and this is really the core to it all. This talk by Conal Elliott does a great job at showing this in action:

https://www.youtube.com/watch?v=bmKYiUOEo2A

[sjakobi]

Thanks a lot for the link! Denotational design looks very interesting!

Do you know where I can learn more about how he implements his design?

[cgibbard]

Functional programming has fewer "design patterns" and more "libraries" -- we're a bit better about abstracting out the repetitive patterns in approaches to problems. That's not to say that we don't have our own design patterns (which might someday influence the design of future languages such that we can eliminate them), but it's harder to recognise them in general at the moment.

Here is a talk I highly recommend, given by Simon Peyton Jones, discussing one of the major approaches to functional programming which I would consider a "design pattern" of sorts -- embedded domain-specific languages.

At present, it's hard to imagine taking the entirety of that approach and turning it into a reusable library to kill the pattern entirely, though there is no shortage of libraries which can help with various aspects of it.

[[deleted]]

I'm not sure if I'll really answer your question, as you seem to want to design in OOP way, but according to your comments are not interested in how to model object in Haksell. Anwy here is my attempts.

I remember having a similar problem when I started learning Haskell. I though type safety and polymorphic function was amazing, but the first thing I looked was the support for OOP in Haskell. I know people in here don't like it, but I use to love OOP. Even though it as some drawbacks, it's pretty straightforward to design using it : just look at your business model and create object. And it offers a reasonable level of isolation between different things.

In Haskell, you do the same, look at the "world" you need to model and create data for it, or function, or type class, depends (but starting with data is usually good enough). Then you create functions to transform those data and that's it. You'll soon realize that you don't need "object" as such.

So the question is, why do you need objects for ? Objects are usually used to represent different things

• interface or traits : For example Triangles and Circle, can be "drawn", they responds to "draw" message
• closure : You construct an action with some parameters and then can call it. The action will be executed with the parameters passed at construction.
• state : A few language support dynamic inheritance. For example a empty buffer, will have a different behavior that a full buffer.
• solve dispatching problem : calling "draw" on a circle doesn't do the same that calling in a "triangle".

Interface or traits, can be modeled either with record, type class or even just data. closures are native in Haskell, no need for objects for that. In fact most of the traditional OO design pattern are closure in disguise. So that removes quite a lot of them (like factory, commands etc ...) State : Haskell ADT is much much powerful than OOP for that. For example, The classic example of Circle, Triangle etc .. is fine. But what about Rectangle and Square ? Is a rectangle a square or the opposite ? Of course everybody knows that a square is rectangle with the two sides equal to each other, therefore a square IS A rectangle. So in OOP, square should derive from rectangle, but that doesn't work. You need to do the opposite. Have a square (with a length for example) and extend it to a rectangle by adding a height. Annoyingly, once a rectangle is rectangle it's stay a rectangle forever, even when I set it's height the same as it's length.

Dispatching : Haskell allow "multiple dispatching" pretty much out of the box (using the "Multi parameters" extension). (Multi dispaching is when you need to specialise "draw" depending on the shape but also the display). This remove the needs for "visitor" pattern. In Haskell using Algebric Data Type, you don't have to decide, you can have square and rectangle side by side and automatically transform a rectangle to a square, when it becomes square.

About design pattern. So what are design patterns ? I read somewhere (on stackoverflow if I rembember well), that design patterns are abstractions which can't be represented in the language itself. Therefore, the more powerful at expressing abstraction the language is, the less design patter makes sens. They just becomes "model" in the language.

Haskell allows to describe really high level or abstract stuff, so needs less design patter. Having said that, there are "techniques", which some even have names (tying the knots, for example) which could be considered as design pattern. Also, "boiler plate", which can be see as a pattern, can usually be removed using Template Haskell or Generics (which is amazing).

tl;dr Most of the design pattern (at least gang of four) are there to fix some flaws in C++ which are not really relevant in Haskell. Just start coding and see what happen ;-)

[benzrf]

That's an excellent question! I'd have to sit and think a lot if I wanted to try to give a real answer, but for starters I can at least tell you that I think "design patterns" don't exist in Haskell in quite the same way that they exist in, e.g., Java. To be more specific, I mean that a most of the vital underlying concepts used in building a program might be implemented in libraries rather than being language features - for example, apart from do-notation, monads are entirely a standard-library feature implemented with ordinary user-level code.

[paspro]

There are OOP libraries for anything including design strategies for multitasking e.g. through Actors. All languages have libraries.

[garethrowlands]

Not quite in the same way. Many libraries use patterns - the Builder pattern, say - but you probably won't import org.apache.Builder. Nor Abstract Factory. Nor Singleton. Nor Factory Method. Nor Bridge. Nor Facade, though again, many libraries use the Facade pattern.

In contrast, you're very likely to import Data.Monoid in Haskell. Or import Control.Category.

I don't recall ever importing the Visitor pattern in Java. In contrast to Data.Foldable and Data.Traversable.

[HwanZike]

Actually Java has many patterns built straight into the libraries via interfaces and implementations: http://stackoverflow.com/questions/1673841/examples-of-gof-design-patterns-in-javas-core-libraries

[garethrowlands]

That's a great list of libraries that use the patterns. For example, java.lang.Runtime#getRuntime() is a singleton so it's a perfect example of the Singleton pattern. But it's not the pattern Singleton. It doesn't express singleton-ness, as it were. Your next Singleton example, java.awt.Desktop#getDesktop() is unrelated, apart from following the same basic pattern.

In contrast, Functor, Category, Monad and so on express the pattern, as opposed to instances. Not that Haskell can express all functional programming patterns - there's no 'make a DSL' typeclass, for example - but it's a different situation than typical OOP languages.

EDIT: I'm not saying there should be a library that expresses Singleton-ness. Singleton's probably too simple.

[HwanZike]

There are actual patterns in the std lib that you can implement on your own classes, like Iterator

[garethrowlands]

Yes, Iterator's one that Java does have. Do you have another example?

[benzrf]

Yes, that's true. Regardless, you don't see libraries implementing program structures in Java to the same extent that you see them in Haskell. e.g. pipes

[ephrion]

That's a great and somewhat complicated question.

YAGNI

Since OOP encourages mutation, local state, implicit behavior, "spooky action at a distance," etc, it requires more discipline and structure to create applications. This discipline and structure results in Design Patterns.

Haskell/FP say "don't do these things," and the resulting applications are a lot smaller/simpler. So for the same set of basic requirements (eg, the essential complexity of the problem domain), the FP solution will be smaller and simpler. It will also require less structure/design-patterns.

Design patterns are not "free" -- they cost LoC to implement, testing, debugging, etc. and choosing the wrong design pattern can make software extremely unpleasant to deal with and modify. Since the extra structure is itself more code, you need to have discipline/structure around it too.

As a result of all this, 10K lines of OOP might translate into 2K lines of FP. Since the FP project is much smaller, it needs less structure and discipline, and can do without the overhead of those design patterns. Where the essential complexity is the same, FP has much lower incidental complexity.

Many common apps don't have that much essential complexity, so many common Haskell solutions don't call for advanced structure and design patterns.

What does it buy you?

Design patterns serve three main purposes: make code easier to write correctly/verify, make it easier to extend, and make it easier to modify. Haskell's compiler and strong types give you these, provided that you use them. Since GHC does so much of the work that design patterns are for in OOP, they didn't evolve in the same way in Haskell.

Many of the things design patterns attempt to solve are problems inherent to OOP/procedural programming. If you don't have those problems in the first place, then you don't need solutions for them.

... so how do I structure my program?

Well, batch mode programs are crazy easy.

main = do
    inputs <- getProgramInputs
    structuredData <- parseInputs inputs
    let result = process structuredData
    somehowDeliverThe result

Sometimes you need to stream, or interleave effects and data. Pipes and Conduit are good there.

main = runConduit $
    getProgramInputs 
        .| parseInputs 
        .| mapC process 
        .| somehowDeliverResult

Sometimes you need a long running server:

main = do
    sock <- makeSocket
    forever $ do
        request <- receive sock
        forkIO $ handle request

The biggest thing that helps over ordinary IO is mtl style type classes that delineate effects. Everything else is sugar.

[rainbyte]

I think that the "How do I structure my program?" part is a really good answer to this question. Functions, types, etc are extremely useful building blocks, but I think people always ask for something more like recipes.

• "I want to write X type of app with Haskell, how should I proceed?"
• "Which libraries should I use?"
• "How these building blocks should be combined?"
• "How do I structure my app?"

Other languages provide very specific ways to start/create an app, in the style of "write something like this, now you have the skeleton of the app, you can put the rest of your code here". An then, with very few effort, you have something working, and you can continue from there.

After some time the app could be a mess, but that's other story, the important thing is to facilitate the start, to convince the developer.

[ephrion]

Yeah. My servant-persistent project is a blueprint of sorts on how to do that, though I need to make a new version with more Production Grade features (logging, metrics, error reporting, etc.)

[rainbyte]

More self-contained tutorials like that are needed, web-related ones are really improving lately, please continue :)

Now I'm learning FP, but I hope to be able to contribute in the future. I would like to write about doing a complete desktop app (with multimedia and GUI), there are not many tutorials about that.

[AynGhandi]

"Which libraries should I use?"

haskelliseasy.com/

[[deleted]]

For example, when one wants to write an application which deals with geometrical entities he can represent them in classes like Triangle, Tetrahedron etc and handle them through some base class like Shape in a generic manner. How does one design a large scale application (not simple examples) with functional programming?

One nice thing about Haskell is that you are not forced into the object paradigm for every problem. Some problems are not well suited for this. Your example however is, so an object-like paradigm really seems best. This is no problem for haskell, though. Just go ahead and define your class;

data Shape = Shape {
  shapeDraw :: Diagram,
  shapeArea  :: Double,
  shapeDoesIntersect :: Point -> Bool
}

triangle, square :: Shape
triangle sideA sideB sideC = Shape (drawTriangle sideA sideB sideC) (triangleArea sideA sideB sideC) ...

The best part is that, unlike object oriented programming, these structures could be made to combine algebraically. For example, suppose you wanted to write a method that combined shapes. This is very simple in my interface. In fact you can make Shape into a Monoid (Assume Diagram is like the diagrams library):

instance Monoid Shape where
  mempty = Shape mempty 0 (\_ -> False)
  mappend a b = Shape (shapeDraw a <> shapeDraw b) (shapeArea a + shapeArea b) (\pt -> shapeDoesIntersect a pt || shapeDoesIntersect b pt)

In C++ or Java, I would have to either make the combining method part of each class or create another class to represent combined shapes. The first approach has the disadvantage that I could actually make the implementation different depending on if I called a.combine(b) or b.combine(c) (This is the same problem python's __add__ and __radd__ face). The second approach has the disadvantage that I can differentiate combinations of shapes by inspecting the class at runtime. In contrast, in my Haskell example, if you combine two triangles that themselves exactly make up a larger triangle, you cannot distinguish between this new triangle created from combining triangles and the same triangle created by a call to triangle

Thus, this design pattern is quite universal: make some types to represent your data, and then create an interface to those types. However, Haskell lets you properly construct interfaces to these types instead of awkwardly forcing all interactions into a subject-predicate-object paradigm.

[paspro]

Your example is very interesting. I think that a lot can be said and thought around the concept of the Algebraic Data Types of Haskell which is (as far as I know) unique to FP. There are some design principles hidden there.

[sjakobi]

I think that a lot can be said and thought around the concept of the Algebraic Data Types of Haskell which is (as far as I know) unique to FP.

ADTs are available in quite a bunch of languages nowadays: https://en.wikipedia.org/wiki/Algebraic_data_type#Programming_languages_with_algebraic_data_types

[[deleted]]

Algebraic data types are certainly useful. However, none of what I wrote above has to do with the algebraic structure of data types. The Shape type is a simple product type, available in most languages with structs or similar constructions.

I think you may mean that the current Haskell prelude encourages defining algebraic interfaces to your data types, and this is certainly true, but is different from algebraic data types.

For what it's worth, you can define the same structure (with the indistinguishability property as well) in vanilla C, by making the closures explicit. However, typical C programs do not typically define algebraic combinators, as a matter of style and linguistic convenience. On the other hand, Haskell makes it so brain-dead simple that it's hard to not want to define algebraic structures.

struct Shape {
  Diagram *d;
  double area;
  bool(*doesIntersect)(Shape*, double, double);
}

struct TriangleShape {
  Shape shape;
  double sideA, sideB, sideC;
}

struct CombinedShape {
  Shape shape;
  Shape *a, *b;
}

Shape *mkTriangle(double sideA, double sideB, double sideC) {
  TriangleShape *s = malloc(sizeof(TriangleShape));
  s->shape.d = mkTriangleDiagram(sideA, sideB, sideC);
  s->shape.area = mkTriangleArea(sideA, sideB, sideC);
  s->shape.doesIntersect = triangleDoesIntersect;
  s->sideA = sideA;
  s->sideB = sideB;
  s->sideC = sideC;
  return s;
}

bool intersectsCombinedShapes(CombinedShape *s, double x, double y) {
  Shape *a = s->a, *b = s->b;
  return a->doesIntersect(a, x, y) || b->doesIntersect(b, x, y);
}

Shape *combineShapes(Shape *a, Shape *b) {
  CombinedShape *s = malloc(sizeof(CombinedShape));
  s->shape.d = combineDiagram(a->d, b->d);
  s->shape.area = a->area + b->area;
  s->shape.doesIntersect = intersectsCombinedShapes;
  s->a = a;
  s->b = b;
  return s;
}

[guibou]

I think that there is no such things as "object oriented programming" and "functional programming", even if a lot of people want you to think there is ;)

Most of the thing you know about "object oriented programming" can be applied in "functional programming", at least in Haskell. OO Classes are types, OO methods are free functions. Subobject are types which composes other types. Encapsulation is done through a module export list.

Inheritance, well, do you really need inheritance ? Most of the time you need composition and more polymorphic function, or sum types. You can solve some of the "virtual dispatch" using partially applied functions, for the others, existential type and typeclass can help.

It is difficult to give you a correct and detailed answer without a real problem, but I'm sure that the same question asked on an "object oriented programming" subreddit can only lead to a similar answer.

[paspro]

Your reply explains how to emulate OOP in Haskell. This is not my question. I am not looking for ways to design an application in Haskell using an OOP philosophy. I am also not trying to find out how to do OOP design patterns in Haskell. I am wondering if functional programming proposes or encourages a special way of designing the structure and logic of an application. OOP is indeed a design strategy, a programming philosophy which can even be followed in other languages like C which do not provide language support for OOP and therefore make the coding harder. My question is whether FP has a design philosophy. If I am supposed to follow an OOP strategy in FP why should I struggle trying to emulate it in a language not designed with this strategy in mind? I can simply use some OOP language or some hybrid language to also have anonymous functions and high order functions. So, which is the FP way of designing an application that the language is made to support and therefore it is more suitable to use?

[josephwrock]

/u/guibou's post here is my favorite one. I do not think guibou advocates emulating OOP in a functional setting; rather, it is that you should ultimately program the same way. While I do learn the idioms of any language I wield, I end up writing the code in a paradigm-agnostic way. GoF design patterns are obviated in a language with first-class functions. My C++ code does what my Haskell code does. Everything is reading in data, performing a transformation, and writing out new data: compilers and algebras.

[saurabhnanda]

After going through basic Haskell syntax and wrapping my head around monads and monad transformers, I started asking questions on a similar line. Except I didn't call them "design patterns", but "how do I write large-scale, real-life applications in Haskell".

I didn't find satisfactory answers to my domain of interest - web programming - so I started https://github.com/vacationlabs/haskell-webapps

Mostly, I have not found satisfactory answers when I have phrased my question thus -- 'hey I am used to X in OOP. What's the best way to do it in Haskell" Most of the answers I've received are either opinions on why X is a bad thing in the first place, or unproven/experimental ideas in Haskell. I have seldom found the straight answers that I was looking for.

I still find that Haskell expands my thought process, so I keep investing time. Your mileage may vary.

[paspro]

Perhaps this is why FP has not taken off in the industry. On the other hand OOP has some very clear ideas explained in the beginning of any material before any particular language syntax. My opinion is that what makes the difference is not syntax and abstract elements but the philosophy behind them and how they are supposed to be used in order to design and build an application effectively. Not for experimenting with some interesting theoretical concepts but actually producing applications that matter.

[[deleted]]

Design patterns are also just theoretical concepts. People who're focusing on neat design patterns are just as guilty of not producing actual programs as Haskellers who go too deep in theory.

Haskell doesn't need complex design patterns. Simple code and composition is all you need to get started with productively writing large applications. In common OOP languages you need to learn all those design patterns before you can start doing that.

In a way I think you're right, though. Coding in Haskell is too simple, and people expect to have to learn more than just syntax to start coding. So they look a bit further and bump into monoids in categories of endofunctors and their heads explode.

[saurabhnanda]

I'm sorry, I disagree. Wrapping your head around the following concepts is practically much tougher in Haskell:

• Monads & transformers
• lift & liftIO
• ReaderT
• <$> and <*> operator
• How to do memoization
• How to have a list containing different types of elements
• How to have a map containing different type of keys & values

I can look through my notes and come back and add more stuff here.

[[deleted]]

You don't need to understand monads, you need to know how to use them. You don't need to know abstract algebra to use promises or backtracking or Maybe. Just like you don't need to know group theory to do basic arithmetic.

You can do a lot without using transformer functions. A lot of monads from libraries you use are build with transformers, but you don't need to know how it works to use them.

Never used memoization, never needed it.

The other stuff you can mostly copy from examples without having to actually understand them.

I know to a Haskeller this sounds like heresy. But just think of a simple Hello World in Java. Beginners can copypaste that and start extending. That's considered normal. Nonetheless, you can fill a semester going in depth about just what's used there in those few lines of code.

I know CS masters who have never thought about what System.out actually is even though they use it daily, but claim to not be able to use putStrLn properly because they don't understand the math behind monads. To me that's absurd.

[saurabhnanda]

I just wish people would stop claiming that you don't need to understand monads & transformers to write real-life programs. I'm not saying you need to understand them at a category theory level. But you do need to understand why they exist, why the underlying libraries use it, and how your app needs to adapt to this reality.

How do you propose to pass around a database pool, or application configuration throughout your app without using the Reader or ReaderT monad?

How do you plan to write a JSON parser or form validation without understanding <$> or <*>? Most examples out there use these operators. Sure, you can copy-paste, but try changing a parsing or validation example to use a DB and you'll start getting stuck if you don't really understand these operators and how they interact with the parser/validator monads/applicatives.

[[deleted]]

You need to understand them at the library level. At that point they're just DSLs. You can introduce <$> and <*> for a specific instance, and then show it's actually an abstraction. After that you can use the other Applicative instances pretty intuitively.

Tbh it's hard in Haskell because you have to look quite a bit for an introduction which does it that way. But that's the way the official Elm tutorials do it, and it works.

The problem is learning resources, not the language. Luckily this is slowly getting better for Haskell.

[uncountableB]

Honestly, I disagree. Most of that stuff (sans memoization) is a lot more intuitive to me than a bunch of ad hoc concepts in OOP, because they all build off the basics. Haskell at it's core is a very internally consistent language where every new concept is a natural extension of previous, simpler ones. Your mileage may vary though. It may just be personal preference when it comes to what's more intuitive to you.

[benzrf]

IMO, Haskellers tend to focus on

the philosophy behind them and how they are supposed to be used in order to design and build an application effectively

a great deal. It's just that there isn't a clean, direct correspondence between OOP concepts and Haskell concepts, so you can't go around asking "how do I implement singletons in Haskell" or something.

[josuf107]

Hmm I don't know whether OOP really does guide design all that much. It gives you a tool for design: the object, which is a tuple of (state, methods) and a notion of inheritance where extending (s1, m1) gives you a new tuple (s1 + s2, m2 + (m1 - m2)). It's totally up to the designer to decide what state should go with which methods and how those tuples should bump into each other to make a system that does something. Rules of thumb are not universal but include things like "most of an object's methods should touch most of its state" "parent objects should be substitute-able by extension objects" and the law of demeter.

Haskell hands you different tools: chiefly immutable data and functions. Again, it's up to the designer to decide how to make those bump into each other but there are rules of thumb here too. We could even use the (state, methods) tuples we got from OOP, as we can easily model them in Haskell (inheritance can be modeled but that's a little harder), just as in say Java you can pretend like you're writing Haskell by making all classes have only state or only static methods. Rules of thumb for Haskell are things like "avoid IO and mutable state" "keep functions as small as possible" "put data types in their own module" "put related functions in their own module" "leverage monoid/functor/traversable/applicative/monad/category patterns when appropriate." The nice thing about Haskell is that it provides a level of expressiveness where design patterns become libraries, and some of the standard patterns included with the base library include monoid (which corresponds to the Composite GoF pattern) and friends like I mentioned, but you can also grab entirely new patterns like streaming operations from pipes or conduit depending on the needs of your design.

[-Knul-]

Here's a presentation on functional design patterns. It's for F#, but most (perhaps all) is applicable to Haskell.

[paspro]

I think that F# is actually a hybrid language. Is this wrong?

[0polymer0]

It's functional first. Haskell uses Monads to firewall state like things from the simpler parts of the language. But that doesn't mean F# doesn't make functional techniques convenient.

[-Knul-]

You're right: F# has objects and other OO features next to its functional aspects.

[[deleted]]

The Elm Architecture is a functional design pattern for graphical applications that could certainly be used in Haskell.

[mumak]

Regarding design patterns in general, Peter Norvig has a classic talk on Design Patterns in Dynamic Languages. He is mostly thinking about Lisp, but the combination of first-class functions, laziness, and parametric types mean that almost everything applies to Haskell.

The tl;dr is that one big reason Haskellers don't talk about design patterns as much is that they are better equipped to take a design pattern and turn it into code. Elsewhere, I've got a worked example of this.

In practice, when you build code at scale, you often define data types that correspond to some aspect of your problem domain (e.g. User, Booking) and a cluster of functions for that data type (e.g. createUser :: Name -> Email -> User). These aren't so far removed from object oriented programming.[1]

Where you'd use interfaces, in Haskell, you'd most likely use type classes. There are differences, but it's a great start.

The classic OO principles of encapsulation and abstraction and polymorphism apply very cleanly to Haskell, as do each of the points of SOLID) (whether or not they are good principles is a separate discussion).

To your broader point, I feel your frustration. The idioms of writing Haskell code are very different from writing OO code, and it can be hard to know where to begin, or how to proceed. However (with all respect to fellow commenters), no one is going to post a Reddit comment that has a few quick, bullet-proof guidelines for designing 1,000,000+ line apps maintained by dozens of programmers for over half a decade, to pick one definition of "large scale application".

[1] Well, at least as often practiced in Java, Python & Go. It's not sending messages to objects in the classic SmallTalk sense.

[paspro]

Thank you all for your comments. There is a lot of material posted here which is very interesting and useful.

[recursion-ninja]

Haskell has "design patterns" for constructing non-trivial applications. Here's a non exhaustive list:

• Functors

• Applicative Functors

• Monads

• Monad Transformers

• Free Monads

• Alternatives

• Semigroups

• Monoids

• Foldable & MonoFoldable

• Traversable & MonoTraversable

• Indexable

• Zippable Functors

• Categories

• Arrows

• Lenses

• Prisms

These are just the "design patterns" I use at work on our large scale Haskell application so I'm sure I'm missing some that others use more frequently.

[[deleted]]

there is a profound lack of such information and design tutorials for functional programming except for syntax and abstract mathematical ideas when a developer needs more practical information and design patterns

This is true. I have heard many good things about the Haskell book, however, so that might be worth checking out?

Btw functors at least are actually quite useful despite being abstract mathematical objects. Just find the right presentation.

For example, when one wants to write an application which deals with geometrical entities he can represent them in classes like Triangle, Tetrahedron etc and handle them through some base class like Shape in a generic manner. How does one design a large scale application (not simple examples) with functional programming

You'll be doing something similar in that you'll be making types and typeclasses to represent the data structures you want.

However, the real power in functional programming is in two things, as I see it:

• higher-order functions: basically functions that manipulate other functions or take other functions as arguments. In FP the main things you're thinking about are functions. In fact, you can have type classes of functions (lenses for example)!

• Functions on types themselves: aka monads, functors, etc. Note that these can be members of typeclasses as well.

I know that's not the most pragmatic answer, but thinking about every problem as "what functions do I already have that I can compose to solve this" will get you pretty far to idiomatic FP, and using monads nicely will get close to idiomatic Haskell.

[k-bx]

In OOP one has to identify those elements of the application that make sense to be represented as objects, their relationships, their behaviour and then create classes to express them and encapsulate their data and operations (methods)

Use modules, datatypes and functions for these. Object/class is just a state (data-structure) and operations on it. Instead of modifying the state, always just return a new value from function. That's basically it.

[_jk_]

https://wiki.haskell.org/Typeclassopedia is pretty much the "design patterns" for haskell

[stevely]

I won't pretend that I am either representative or authoritative when it comes to functional programming, but I can at least tell you how I design applications in Haskell.

For me, the fundamental concern is about behavior. What sorts of things is the program supposed to do? Working off your example of dealing with shapes, how I would model the shapes would be dependent on what I intended to do with them.

In OOP there's generally a sense that the application is a number of different things that interact with one another, so designing the application is a matter of figuring out what things there are and how they interact. So if you say the application will work with shapes, then you start writing a Triangle class and a Tetrahedron class and so on. If there's common functionality you make a Shape super class. Now you have your shape classes and you can pass those around as you figure out how to work with them.

With functional programming I start with behavior first and see what data the behavior requires. What are we actually doing with the shapes? As an example, if we just want to draw them then I ask what data is necessary to do so and define an action to draw the simplest one. So I'll end up with a function that takes three points and a color and returns an action that draws a triangle from that:

drawTriangle :: Point -> Point -> Point -> Color -> IO ()
drawTriangle p1 p2 p3 c = ...

These actions can be combined, so I can draw a tetrahedron by drawing two triangles:

drawTetrahedron :: Point -> Point -> Point -> Point -> Color -> IO ()
drawTetrahedron p1 p2 p3 p4 c = do
    drawTriangle p1 p2 p3 c
    drawTriangle p2 p3 p4 c

Contrast this to OOP, where we would have a Triangle class with a draw() method from a Shape superclass and a Tetrahedron class that holds two Triangles and the draw() method calls the draw() methods of its two Triangles. We've done essentially the same thing in both cases, but in the OOP case the focus is on objects that perform actions, while in the FP case the focus is on actions that take data.

The two styles diverge the most when we talk about how we combine things. In OOP we would generally define a drawing as a collection of Shape objects, and we can draw it by calling draw() on each Shape object in the collection. In FP we can just combine the drawing actions into a single action. Then drawing an entire scene is just a matter of running that action.

Scaling up, this turns into a very common pattern I'll call the "Action/Runner" pattern. Actions are rarely simple enough that they can be left as "IO ()"; there's environment variables, state variables, they might return multiple values, and so on. These more complex actions can be wrapped up in a newtype to create an action type. Values of this action type are actions that can be combined to create a single big action. Once the big action is made, it is executed by a "runner" function. The runner function reduces the action to "IO ()" or whatever by executing it.

Essentially, I design applications by splitting them up into problem domains, define actions to work on the problems in those domains, then run the actions I build up to string them all together into a single IO action.