What do you think?
Rate this book
An Outsider’s Guide to Statically Typed Functional Programming
Dynamically typed functional languages like Clojure and Elixir are now at the point where I feel comfortable basing a commercial application on them. If you use Clojure instead of Java, or Elixir and Phoenix instead of Ruby on Rails, you'll be fine. Your app might still fail, but it won't be because of the technology stack.
Statically typed functional languages like Elm, Purescript, Haskell, or Idris are definitely becoming more popular, but (in my opinion) are not clearly safe bets for mainstream applications. By "mainstream", I mean:
- Applications that require only "ordinary" reliability. I sometimes see HTTP 500 errors on websites. I shrug and try again. Netflix via my Amazon Fire media player occasionally gets stuck loading a TV show. I shrug, back out, click on the show again, and it works. This restriction to ordinary reliability matters, because the static FP languages are much more obviously useful in cases where runtime errors can kill people.
- Applications that work in messy domains. Messy domains are ones like payroll systems that have to deal with decades of special cases negotiated by unions. Or enterprise applications with a long history of salespeople making special deals to close big sales–deals that require special-case code somewhere in the system. Or, generally, any application in direct contact with people who can't be forced to behave in a consistent, "lawful" way.
- Applications that are continuously growing new features. Sometimes one of those features forces a rethink of a domain model, and a major challenge is getting the architecture to a state where such rethinking doesn't have a ripple effect that makes every change hugely expensive.
The programmers who work on mainstream applications are rarely the target audience of the static FP literature. They are exactly the target audience for this book. My goal is to make the most compelling case I can that static FP will give you new abilities, especially new abilities for modeling a messy domain riddled with exceptions to the rules. I aim to do that by teaching you idioms, habits, and design patterns that can make this style of programming an ordinary practice for you to perform–rather than a pile of ideas for you to connect.
Statically typed functional languages like Elm, Purescript, Haskell, or Idris are definitely becoming more popular, but (in my opinion) are not clearly safe bets for mainstream applications. By "mainstream", I mean:
- Applications that require only "ordinary" reliability. I sometimes see HTTP 500 errors on websites. I shrug and try again. Netflix via my Amazon Fire media player occasionally gets stuck loading a TV show. I shrug, back out, click on the show again, and it works. This restriction to ordinary reliability matters, because the static FP languages are much more obviously useful in cases where runtime errors can kill people.
- Applications that work in messy domains. Messy domains are ones like payroll systems that have to deal with decades of special cases negotiated by unions. Or enterprise applications with a long history of salespeople making special deals to close big sales–deals that require special-case code somewhere in the system. Or, generally, any application in direct contact with people who can't be forced to behave in a consistent, "lawful" way.
- Applications that are continuously growing new features. Sometimes one of those features forces a rethink of a domain model, and a major challenge is getting the architecture to a state where such rethinking doesn't have a ripple effect that makes every change hugely expensive.
The programmers who work on mainstream applications are rarely the target audience of the static FP literature. They are exactly the target audience for this book. My goal is to make the most compelling case I can that static FP will give you new abilities, especially new abilities for modeling a messy domain riddled with exceptions to the rules. I aim to do that by teaching you idioms, habits, and design patterns that can make this style of programming an ordinary practice for you to perform–rather than a pile of ideas for you to connect.
- GenresProgramming
509 pages, ebook
First published May 24, 2017
5 people are currently reading
28 people want to read
About the author
Brian Marick
13 books6 followersBrian Marick first learned to program in 1976, using the Tutor language. He has since done real programming in C, Common Lisp, Java, Ruby, Clojure, Elixir, and Elm. Much of his career, though, has been spent consulting, first on software testing, then–after he lucked into being one of the authors of the Manifesto for Agile Software Development–on testing and programming on Agile teams. He's written four books, three of which you can still buy: The Craft of Software Testing (horribly out of date), Everyday Scripting with Ruby, and Functional Programming for the Object-Oriented Programmer (almost entirely about dynamically-typed functional languages). He's currently trying to make a modest living writing webapps for schools of veterinary medicine, deliberately using advanced languages and techniques so that he has real-world examples to use in books, training, and consulting.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 of 1 review
September 27, 2024
A very opinionated book.
The author is showing just its own way to do Elm and PureScript (the part about Idris wasn't completed at the time I was reading the book). And this way is too far from the common styles for both of the mentioned languages.
There is a good part: if you want to see the Elm programmer in action (with its own style) this part of the book you may find interesting. The author shows how he is dealing with the complex application state, how he designs the data flow, and how he splits the domain. There is even the state machine with continuations - a pretty nice piece of code!
But I should warn you: this book is not good for the beginners.
Update (2024): For now the Elm part is a way less "unconventional", but still too "outsider-ish". The whole material from the educational point of view is neat, thought.
The author is showing just its own way to do Elm and PureScript (the part about Idris wasn't completed at the time I was reading the book). And this way is too far from the common styles for both of the mentioned languages.
There is a good part: if you want to see the Elm programmer in action (with its own style) this part of the book you may find interesting. The author shows how he is dealing with the complex application state, how he designs the data flow, and how he splits the domain. There is even the state machine with continuations - a pretty nice piece of code!
But I should warn you: this book is not good for the beginners.
Update (2024): For now the Elm part is a way less "unconventional", but still too "outsider-ish". The whole material from the educational point of view is neat, thought.
Displaying 1 of 1 review