Read on Twitter
So, the Sapir-Whorf hypothesis is controversial, but it remains a valuable idea. My junior colleagues are several weeks in to reading http://haskellbook.com and concurrently doing the odd bit of coding on the side in other languages, and I'm hoping this is what they're feeling…
Sometimes, in the kitchen, a friend will turn up and say "how can I help?" And you say, "ok, here is a thing I want chopped, and let me show you exactly how I want a knife put through it." And after a few rounds they take over and do the rest.
Now imagine if, in professional kitchens all over the world, the head chef had no other way to communicate to the line chefs, other than to say, "now watch me as I chop this thing, and later you copy, mmmkay?"
One day, a Great Chef comes along and says, "I have a system! A taxonomy of knife cuts! I will label this as Coarse Dice; Fine Dice; Mince; Julienne."
Kitchens around the world would be revolutionized. "So this thing that we've been doing, there's a name for it? Amazeballs!"
Kitchens around the world would be revolutionized. "So this thing that we've been doing, there's a name for it? Amazeballs!"
For her next act, the Great Chef goes around slapping names on activities that happen in the kitchen, activities which previously were communicated via "watch me". Now we have names for: steam; simmer; broil; roast; bake; pan-fry; deep-fry; stir-fry.
Kitchens become more efficient. Head chefs no longer need to go around laboriously demonstrating. Junior chefs can learn the lingo in schools. This was the original job assigned to Adam; later picked up by Linnaeus. Abstraction and naming is the highest act of the verbal animal.
What does this have to do with Haskell? After simmering in functional programming for several months, switching back to a "normal" language feels like going back to work in a kitchen where they don't know the lingo. Everything has to be manually demonstrated.
Some head chefs get fed up with this benighted situation. Opening a cooking school is beyond their resources at the moment, but they rebelliously start to teach their line chefs the lingo. Line chefs who've been exposed to those secrets carry them with them to the next project.
A secret handshake develops: "do you know the Vocabulary? Do you know the Names of Things? Can you describe an entire sequence of cooking using words alone?"
"I can, and I'll tell you another secret: the name for describing a sequence of cooking using words alone, is a 'recipe'"
"I can, and I'll tell you another secret: the name for describing a sequence of cooking using words alone, is a 'recipe'"
Lodash and pydash are the remnants of secret knowledge secretly whispered in kitchens where the boss doesn't know.
Haskell is the cooking school where new names are made.
The "design patterns" movement was the first stab at systematizing these names.
Haskell is the cooking school where new names are made.
The "design patterns" movement was the first stab at systematizing these names.
Yes, the vocabulary is pretty huge. It takes time to learn and context to appreciate. But the higher the mountain, the better the view. Turns out that many of the things we do in the dark have names. If you've got "tramp data", it's a "code smell"; what you want is a State monad.
Chains of transformations happen in kitchens all the time. Meet Control.Arrow, inspired by Unix pipes:
defrost >>> sear >>> instantPot 30
velvet >>> stirFry >>> sauce
Each of these is a function composed from smaller functions. You can run them on various inputs: “ingredients”
defrost >>> sear >>> instantPot 30
velvet >>> stirFry >>> sauce
Each of these is a function composed from smaller functions. You can run them on various inputs: “ingredients”
And I’m not just talking about us programmers having names for things. I’m talking about the programming language understanding the names of things, so the computer can do the work without us having to micromanage it, bossing around pointers, indexes, data structures, loops.
You want to add five to every member of an array?
(+5) <$> myArray
To every node in an tree?
(+5) <$> myTree
If the variable is null, do nothing; add five only if defined:
(+5) <$> myMaybe
Suppose myTriple(x) = x*3
(+5) <$> myTriple
produces a function that does x * 3 + 5
(+5) <$> myArray
To every node in an tree?
(+5) <$> myTree
If the variable is null, do nothing; add five only if defined:
(+5) <$> myMaybe
Suppose myTriple(x) = x*3
(+5) <$> myTriple
produces a function that does x * 3 + 5
That operator <$> is pronounced “fmap”. And there you have an incredibly powerful idea, named and primed like a spell ready to cast. Programming is full of situations that call for it; but because less expressive languages don’t have that word, you have to spell it out each time.
Brillat-Savarin said: 'The discovery of a new dish does more for the happiness of the human race than the discovery of a star.'
Note he said “discovery”, not “invention”. Lisp and Haskell have a similar quality. If aliens know pi and e and the lambda calculus, they know FP too.
Note he said “discovery”, not “invention”. Lisp and Haskell have a similar quality. If aliens know pi and e and the lambda calculus, they know FP too.
“Lisp is a family of programming languages descended from a language John McCarthy invented (or more accurately, discovered) in the late 1950s.” – http://www.paulgraham.com/lispfaq1.html
Greenspan’s Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
And, if you’ve ever written a parser, you know that the first order of business is to transform the input into an AST: an abstract syntax tree. Which is to say, every computer program ever written in any high-level language is first transformed into, basically, a kind of Lisp.
I know, I know, the quibblers will say, hang on, you’re playing fast and loose here, there’s S-expressions and there’s data types and a compiler’s AST is not literally valid Lisp, these things are not all the same even if they are interconvertible… but the point remains…
Just as Unix is the Hole Hawg of operating systems, Lisp and Haskell are, similarly, the Hole Hawg of programming languages – except the power comes not from metal but math.
(This is an allusion to Neal Stephenson’s In the Beginning was the Command Line: http://cristal.inria.fr/~weis/info/commandline.html)
(This is an allusion to Neal Stephenson’s In the Beginning was the Command Line: http://cristal.inria.fr/~weis/info/commandline.html)
Now, I’m not saying Haskell and FP are the be-all and end-all of programming languages and paradigms. It behooves every programmer to know multiple paradigms: https://www.info.ucl.ac.be/~pvr/VanRoyChapter.pdf
If I were building a WhatsApp I would reach for Erlang. If I were building an expert system I would use Prolog. If I were solving SAT problems I would use Z3.
If I were building Erlang, Prolog, or Z3, I would use Haskell.
If I were building Erlang, Prolog, or Z3, I would use Haskell.
Thank you for coming to my Ted talk
Next step: read this book https://twitter.com/graninas/status/1302269114623373312
Next step: read this book https://twitter.com/graninas/status/1302269114623373312
