This is one of the reasons why Higher-Kinded Types are such a boon in the languages which have them. It allows you to translate "patterns" into straight-up libraries. This slideshow is good documentation for what the patterns are, but if you go use them in Haskell (e.g.) then you'll start to see that libraries are designed to completely contain that pattern and ensure compatibility between your use of it and others.<p>Usually this is achieved by representing the pattern exactly in the language. Usually the patterns are just maths. Usually math happily quantifies over higher-kinded types. Thus, you really want HKTs in your language.<p>And to be fair, Haskell does not go tremendously far in this direction. The languages which will truly profit from this are still in gestation.
I quite liked the types section, particularly the bit about making illegal states unrepresentable so you can enforce business rules, eg. validating email addresses.<p>One of the things I'm always thinking when people talk about the merits of various type systems and the problems they solve is: "But I don't have those problems". However, there are a few good examples in there that opened my eyes a little and I'll give type-centric programming a go on my next project. Not necessarily solving problems that I have, but certainly presenting a different, hopefully clearer, way of writing some functionality.
Excellent presentation. Of the leading type safe functional languages (Haskell, F#, and OCaml) I find F# to be far and away the most accessible in terms of syntax and application.<p>Writing Scala in my day job currently (which, for the most part, I quite enjoy) but can see jumping ship if Microsoft's move to Linux is successful. Being able to develop and deploy F# applications on Linux with full blown Type Providers and <i>decent</i> IDE support? Pretty compelling combo, and that's just the tip of the iceberg.
These slides explain the usual functional patterns but it seems like a bit of a cheat, because it doesn't really explain how to do anything hard (dealing with time, persistence, logging, and so on).<p>The comparison between Slides 81 and 82 is particularly unfair because the "object soup" actually does deal with the database, SMTP, and so on and the functional version doesn't. If you add those in, you're going to get something complicated: perhaps a bunch of monad transformers or some such?<p>Slide 104 is misleading. In an imperative language, you can write a decorator function that logs a function's inputs and outputs, and it will have the same API. In a pure language, you can't do that because a function that does I/O has a different type. The flexibility or sloppiness (depending on your point of view) that allows you to do I/O anywhere is really a feature of imperative languages rather than pure functional languages.
A good read, I especially like the parts about error handling and maps/applicatives. They are well-illustrated and tackle some difficult common problems I had shortly after I started using functional languages.<p>The part about functors/monads/monoids is also nice, although I feel like it would be better with the accompanying talk to bind it together a bit more.
The talk is here: <a href="https://skillsmatter.com/skillscasts/4971-domain-driven-design-with-scott-wlaschin" rel="nofollow">https://skillsmatter.com/skillscasts/4971-domain-driven-desi...</a>
Ok, I'm sure the slides get better as they go on. But what the hell? The difference between the patterns that are compared and contrasted are... well, tenuous, at best.<p>Seriously, it gives off the impression not that these are going to be better patterns. But that someone simply has a bias against "patterns" as they are promoted in Java and then rails against it saying that they are going back to the root of the word patterns. Ignoring that this is the same path.
This a good read. I like the railway analogy.<p>"Functional Programming in Scala" is also well worth a read as well if you're trying to learn FP... I've found it to be excellent, especially since it has lots of exercises to use for practice.
There's a book with the same name plus "... In Scala and Clojure". It is based on the wrong sort of patterns (trying to shoehorn GoF into FP). This presentation is much more what I had hoped that book was going to be.
I am currently taking EdX's Intro to Functional Programming mooc, taught by Erik Meijer (with his crazy shirts), which uses Haskell to teach functional programming concepts.<p>I am wondering if there are any other good resources for teaching the functional programming paradigms. Anybody care to recommend me some resources?<p>Also, I mainly work with Ruby and Javascript in my full time job. Currently, in school, I use Java (in the context of Android, which is on Java 6) and Objective-C (iOS programming). If anybody has any resources regarding functional programming and the previously mentioned languages, it would be most appreciated.<p>Thanks people!
I thank the lord every day that the language I work in (Javascript) supports functions! I try to write pure functions as often as possible, so it's easy to refactor the code when I come back three months later.<p>But is there, except for Clojurescript, any true (like Haskell) FP language for browsers? Something that has the tools, and community to back it, so it's viable to actually make projects in it?
Interesting but not always correct.<p>Eg: slide 64 encourages the reader to "Using sum vs inheritance", and then goes on to show the "good" algebraic datatypes (no behaviour, just data) vs the "bad"... multiple class implementing the same interface (which I wouldn't call inheritance).
I Really found the book "Learn you a haskell" to be an really fast way to get functional programming into production.<p>I did not however continue to use haskell since it doesnt have key libraries I need.<p>I instead adopted livescript,underscore into javascript and was good to go.
Some guy almost 20 years ago argued, that if you end up with a bunch of "design patterns" then your language is not good enough.)<p><a href="http://norvig.com/design-patterns/design-patterns.pdf" rel="nofollow">http://norvig.com/design-patterns/design-patterns.pdf</a>