The monad fear

LINE Haskell Boot Camp
The Monad Fear
The Shibuya Camp
Finale
1 / 42

This slide is the presentation material used in the LINE Haskell Boot Camp that took
place in Shibuya, Tokyo, on October 28th, 2016.
The latest version of this slide is available at: https://e.xtendo.org/monad
2 / 42

Fear, Uncertainty, and Doubt
Haskell is difficult to learn
Monad is difficult, and therefore Haskell is difficult
You need to understand monad in order to use Haskell
You need to understand monad in order to use practical Haskell
Haskell is a mathematical language
Anyways you should learn monad
3 / 42

Fear, Uncertainty, and Doubt
Haskell is difficult to learn
Monad is difficult, and therefore Haskell is difficult
You need to understand monad in order to use Haskell
You need to understand monad in order to use practical Haskell
Haskell is a mathematical language
Anyways you should learn monad
None of the above is true.
3 / 42

Not my original idea.
Dan Piponi, The IO Monad for People who Simply Don't Care (2007)
Brent Yorgey, Abstraction, intuition, and the “monad tutorial fallacy” (2009)
tora, My how to give a 'monad tutorial' tutorial (2010)
scottw, Why I won't be writing a monad tutorial (2013)
Travis Hance, Write you a monad tutorial (2014)
~kqr, The "What Are Monads?" Fallacy (2015)
Justin Le, IO Monad Considered Harmful (2015)
The community began to recognize the problem: "Why do so many beginning Haskellers
ask the same (wrong) question and go through the same (unnecessary) difﬁculties?"
4 / 42

I've been organizing the South Korean
Haskellers' group for nearly a year
The two most frequently asked question from the newcomers:
5 / 42

1. If Haskell is so great, why's nobody
using it?
6 / 42

2. What the hell is monad?
7 / 42

Pedagogical catastrophe
Ask the Internet, "What is Haskell?"
Purely functional
Lazy
Uses monads
Type classes
etc.
8 / 42

Purely functional
Lazy
Uses monads
Type classes
etc.
In short, things that newcomers can't possibly have a clue of.
8 / 42

Purely functional
Lazy
Uses monads
Type classes
etc.
Using things you don't know in order to teach you something you don't know
8 / 42

Purely functional
Lazy
Uses monads
Type classes
etc.
?!
8 / 42

Purely functional
Lazy
Uses monads
Type classes
etc.
?!
It would be a miracle if there's no massive frustration.
8 / 42

Why was Haskell created?
9 / 42

Haskell 2010 Report
Preface
[...]
Goals
1. It should be suitable for teaching, research, and applications, including
building large systems.
10 / 42

Haskell 2010 Report
Preface
[...]
Goals
1. It should be suitable for teaching, research, and applications, including
building large systems.
Explicitly stated goal of usefulness in application development.
10 / 42

How the Haskell Committee happened
11 / 42

It is 1987. Non-strict purely functional languages are ﬂooding.
11 / 42

Too many choices, redundant independent efforts. None is chosen in the market.
11 / 42

Purely functional seems to be a good idea, and it's a pity it's not used. Let's unite and
create a language that gets chosen.
11 / 42

In other words, Haskell was not meant to be academia-only.
11 / 42

In other words, Haskell was not meant to be academia-only.
It was designed to be used in real-life.
11 / 42

Haskell: A practical tool that solves
real-world problems
A web server with higher performance that the ones written in C
Standard Chartered: "real time pricing, risk management, data analysis, regulatory
systems, desktop and web GUIs, web services, algo pricing, end-user scripting"
Facebook's data access tools and antispam tools
Haskell in ﬁnances: ABN AMRO, Bank of America, Barclays, Credit Suisse, Deutsche
Bank, Tsuru Capital
12 / 42

FUD
Haskell's I/O is
somehow special/weird/difﬁcult
13 / 42

Haskell
main = do
putStrLn "Hello. What is your name?"
x <- getLine
putStrLn ("The input was " ++ x)
14 / 42

Python
if __name__ == '__main__':
print ('Hello. What is your name?')
x = input()
print ('The input was ' + x)
15 / 42

Do the I/O in Haskell. It works.
There is NOTHING special about Haskell's I/O.
Do it as you did in other (imperative) languages.
Deliberately imperative “look and feel”
Simon Peyton Jones, Wearing the hair shirt: a retrospective on Haskell (2003)
We intentionally made it usable imperatively.
The misconception that Haskell's I/O is difﬁcult/special/weird does NOT come from
people who actually tried it.
One phrase caused all tragedy:
16 / 42

IO Monad Considered Harmful
Justin Le:
The phrase “IO monad” considered harmful. Please do not use it.
...
I’m going to say that this is probably the single most harmful and damaging
thing in Haskell ...
18 / 42

IO Monad Considered Harmful
Justin Le:
The phrase “IO monad” considered harmful. Please do not use it.
...
I’m going to say that this is probably the single most harmful and damaging
thing in Haskell ...
?!
18 / 42

Unix commands
echo STRING
cat FILENAME
rm FILENAME
mkdir DIRNAME
echo and cat are commands,
STRING and FILENAME are strings, which are argument for commands.
command and string are different types.
19 / 42

Unix pipe
find . | grep ".txt$"
tail -f app.log | grep "^system:" > output.txt
You want to feed the result output of one command as an input to another
command.
20 / 42

Haskell's command: action
putStrLn :: String -> IO ()
readFile :: FilePath -> IO String
main = do
x <- readFile "myname.txt"
putStrLn ("Hello, " ++ x ++ "!")
Just as echo is a command that takes one string as its argument, putStrLn is an
action that takes one String.
Just as cat takes a ﬁle path as its argument and prints its content, readFile is an
action that takes a FilePath and returns its content as a String.
Actions and Strings are different types.
Actions and the ++ operator are also different types.
21 / 42

Haskell's pipe
Haskell's pipe looks like this: >>=
main = readFile "myname.txt" >>= putStrLn
Feed the output of one command as an input of another command.
22 / 42

Haskell distinguishes pure functions
and actions by their types
-- pure function
not :: Bool -> Bool
(++) :: [a] -> [a] -> [a]
-- IO action
getLine :: IO String
putStrLn :: String -> IO ()
readFile :: FilePath -> IO String
23 / 42

Action is easy. Then why?
Just call them "IO action" or "IO type", and explain they are similar to Unix
commands, and there will be nothing more to teach.
But we call them IO monads and cause this chaos.
Bewildering number of beginners are asking "what is monad?" ﬁrst. (Because when
programmers see a strange jargon, they just have to understand it. It's their instinct)
"How do I deal with a sequence of multiple numbers in Haskell?"
"Use List." or "Use the List type."
No one replies with "Use the List monad" unless they're pure evil!
Therefore the answer to "How do I do the input/output in Haskell" should also be:
"Use the IO type."
24 / 42

Our biggest mistake: Using the scary term “monad” rather than “warm fuzzy
thing”
-- Simon Peyton Jones, Wearing the hair shirt: a retrospective on Haskell
(2003)
25 / 42

Historical background
Since when did Haskell have monads?
26 / 42

1987: The Committee is formed. They chose Miranda as the basis.
26 / 42

1987: The Committee is formed. They chose Miranda as the basis. No monads.
26 / 42

1990: The Haskell 1.0 report is published.
26 / 42

1990: The Haskell 1.0 report is published. No monads.
26 / 42

26 / 42

1996: The Haskell 1.3 report is published. Monadic I/O is introduced.
26 / 42

1996: The Haskell 1.3 report is published. Monadic I/O is introduced.
Monadic I/O has been in use in the community ﬁrst. (?!)
Haskell 1.3, reﬂecting such community status, completely abolished the
conventional [Response] -> [Request] I/O and introduced monadic I/O
and the do syntax.
26 / 42

The term "monadic I/O" or "IO monad" was originally made to distinguish the new
concept from the old I/O. The term became a new jargon, and the tragedy began.
27 / 42

Downfall
Haskell's I/O can be done without monads, and without knowing monads.
You can remove the type class Monad from Haskell and still do the I/O.
Because monad is no more than interface. You only need the >>= function (and
optionally the do notation) redeﬁned I/O only.
You can remove the type class itself and still do the I/O. Because type class is no
more than interface.
But we call them "IO monad" and people immediately look up "monad" ﬁrst.
If we called them IO type, this step could have been completely skipped.
The community is encouraging the yak shaving, or a "sidequest."
28 / 42

"To use Haskell one must understand
monad"
29 / 42

JavaScript
>>> ['10', '10', '10'].map(parseInt)
30 / 42

JavaScript
>>> ['10', '10', '10'].map(parseInt)
[10, NaN, 2]
30 / 42

JavaScript
>>> ['10', '10', '10'].map(parseInt)
[10, NaN, 2]
Just as you don't need to know JavaScript to use JavaScript
You don't need to understand monad to use Haskell
30 / 42

All code of do notation is translated
into monad.
Doesn't that mean monad is a required
concept?
31 / 42

All code of do notation is translated
into monad.
Doesn't that mean monad is a required
concept?
Sounds convincing at a glance...
31 / 42

All C/C++/D/Rust/Go code is
translated to Assembly.
Therefore, to learn C/C++/D/Rust/Go,
One must learn Assembly ﬁrst.
32 / 42

All C/C++/D/Rust/Go code is
translated to Assembly.
Therefore, to learn C/C++/D/Rust/Go,
One must learn Assembly ﬁrst.
... But now you see the problem.
32 / 42

Counting
(Source: Why I won't be writing a monad tutorial by scottw.)
33 / 42

What is fruit?
When you're trying to explain "What is fruit?" to someone who doesn't know what
fruit is:
Apple is fruit. Orange is fruit. Pear is fruit.
...
Fruit is the seed-bearing structure in angiosperms formed from the ovary after
ﬂowering, normally as a means of botanical reproduction, often edible and juicy with
the sweet or sour taste.
You don't do this.
It is a common intuitive pedagogy to derive abstract concepts from concrete
examples.
34 / 42

Even if you do understand...
Understanding the concept called monad, and actually using monadic types (IO, ST,
[], Maybe, ...) are a completely different matter.
Monad in category theory and monad in Haskell are, again, different.
35 / 42

Even if you do understand...
Understanding the concept called monad, and actually using monadic types (IO, ST,
[], Maybe, ...) are a completely different matter.
Monad in category theory and monad in Haskell are, again, different.
Attempting to learn how to use monads by understanding what they are is
like asking "What is a musical instrument?" and then assuming once you
know the answer to that, you'll be able to play all of the musical instruments.
~kqr, The "What Are Monads?" Fallacy (2015)
35 / 42

So this is what happens
36 / 42

Beginners believe they must understand monad.
36 / 42

They can't.
36 / 42

They can't. (Most people drop out here)
36 / 42

They continue to struggle to understand monad while writing codes in Haskell
36 / 42

At some point they do understand what monad is
36 / 42

Then everything feels easy
36 / 42

They ought to spread this Awakening widely and redeem the people
36 / 42

Another monad tutorial emerges
36 / 42

Another monad tutorial emerges (there can never be enough)
36 / 42

Monad tutorials
A 'newbie', in Haskell, is someone who hasn't yet implemented a compiler.
They've only written a monad tutorial.
Pseudonym
37 / 42

Monad tutorials
A 'newbie', in Haskell, is someone who hasn't yet implemented a compiler.
They've only written a monad tutorial.
Pseudonym
Tutorial on how to write a monad tutorial
tora, My how to give a 'monad tutorial' tutorial (2010)
Travis Hance, Write you a monad tutorial (2014)
37 / 42

Monad is
Monad is a type class.
A type class is a set of types.
A type is a set of values.
In Haskell, monad is a shared interface to multiple types that share something in
common.
Therefore, even when a type is monadic, they may look totally unrelated to other
monadic types.
38 / 42

Therefore, to learn monad
39 / 42

First use IO type.
39 / 42

First use IO type.
and Maybe type.
39 / 42

First use IO type.
and Maybe type.
and List type as well.
39 / 42

First use IO type.
and Maybe type.
Write enough Haskell code. (>1k lines?)
39 / 42

First use IO type.
and Maybe type.
Then all of a sudden you realize what they have in common. (Aha moment)
39 / 42

First use IO type.
and Maybe type.
It doesn't matter you still don't get it. Keep on.
39 / 42

First use IO type.
and Maybe type.
Never attempt to consciously learn what monad is.
39 / 42

First use IO type.
and Maybe type.
Never attempt to consciously learn what monad is. It would only lead to frustration
and confusion.
39 / 42

"Well, I did try Haskell, but that monad
thing..."
40 / 42

No! 😄
Don't let monad stop your adventure into Haskell!
41 / 42

The monad fear

Recommandé

Recommandé

Contenu connexe

Plus de LINE Corporation

Plus de LINE Corporation (20)

Dernier

Dernier (20)

The monad fear