
Interview with Simon Peyton-Jones - jasim
http://www.cs.cmu.edu/~popl-interviews/peytonjones.html
======
professor_plum
I'm always curious what people are using the more exotic type system
functionality of e.g. Haskell or Idris for in practice. It was interesting to
hear that even Simon didn't expect such things to be used in industry quite
yet.

Still, I wish I could see more info on this. At what point does the additional
cognitive burden of advanced type system features become a worthwhile tradeoff
for program correctness? It seems to me that this depends wholly on the
complexity of the program.

Further to that point, the most complex programs I can think of (perhaps you
may be able to offer other opinions, which I welcome) are AAA game engines.
What are the reasons why the big engines out there are not using higher-kinded
types, dependent types and the like? Is this just because of pragmatic issues
such as the languages the developers learned in school not supporting these
features, or because here-to-date functional languages supporting these
features lacked the appropriate throughput of C/C++, where one can layout data
for cache-efficiency?

~~~
danharaj
> Still, I wish I could see more info on this. At what point does the
> additional cognitive burden of advanced type system features become a
> worthwhile tradeoff for program correctness?

As a professional Haskell programmer, I find the cognitive burden to be lower
in Haskell than in, say, Java, where I have to do a lot more bookkeeping about
design patterns and how they're glued together than in standardish Haskell
where compositional forms fall into a compact set of powerful concepts
amenable to reasoning.

I say standardish Haskell because the sweet spot in my experience is a few
lightweight GHC extensions but mostly shunning some of the seriously
experimental stuff in the language. For example, i agree with your doubt when
it comes to dependent types and in particular singletons, a halfway house
implementation that can be used in Haskell today.

Some of my coworkers had unsuccessfully attempted to write mobile games in
Haskell. That was 10 or so years ago and many of the technical hurdles that
impeded them then are no longer there.

The only major one I know of at the moment that prevents Haskell from being
used in a AAA game engine is a guaranteed low latency garbage collector. I
expect someone to implement such a thing for Haskell in the next 10 years.

The space is moving fast, our understanding of how to write _big_ Haskell apps
has advanced drastically since when I first started using the language! I
expect big things to come in the next couple of years.

This is not to say that the space is getting _rewritten_ all the time, it's
just that more useful concepts are being discovered and matured. For example,
Applicative only 11 years ago and scalable FRP like 4 years ago or so.

I should say what type concepts compose my compact tool set:

* higher order functions with syntax optimized for using them.

* algebraic data types (sparingly generalized algebraic data types)

* type classes + higher kinds (The synergy is far greater than the individual features)

* monad transformers (the promise of aspect oriented programming actually realized)

~~~
hota_mazi
> monad transformers (the promise of aspect oriented programming actually
> realized)

I hardly see any overlap between these two concepts.

AOP is about cross cutting concerns and being able easily insert similar
functionalities in unrelated areas of the code.

Monad transformers are the hack you need to use to make monads compose.

~~~
tathougies
How are monad transformers a hack? They have a solid theory behind them.

i'm not sure where you got the idea that they 'make monads compose'. Monads
don't compose. It's nonsensical to talk about monad composition in general,
because there is nothing about the structure of a monad that allows it to
compose (quite the opposite, really). Some things which may form some monads
do compose with certain other things that form monads, but this is like saying
'Abelian groups' are the 'hack' you need to make groups commutative -- it's a
meaningless statement.

~~~
mavelikara
Agree that monads don't compose.

I am not the OP, and not a Haskell programer, but my understanding is that
Monad Transformers exist _because_ Monads don't compose, and when you want
monadic effects to compose, you use Monad Transformers (the other option is a
go crazy writing every combination and ordering of effects you want by hand).

I got this impression from the papers I have read, particularly this one [1]

    
    
        Monad transformers offer an additional benefit to monadic 
        programming: by providing a library of different monads and 
        types and functions for combining these monads, it is possible 
        to create custom monads simply by composing the necessary monad 
        transformers. For example, if you need a monad with state and 
        error handling, just take the StateT and ErrorT monad transformers 
        and combine them.
    

Notice the last line of the snippet I posted above. What am I missing?

[1]: Monad Transformers Step by Step [https://page.mi.fu-
berlin.de/scravy/realworldhaskell/materia...](https://page.mi.fu-
berlin.de/scravy/realworldhaskell/materialien/monad-transformers-step-by-
step.pdf)

~~~
tathougies
Monad transformers exist independent of the fact that monads don't compose.
Can you explain what you mean by 'monad transformers exist because monads
don't compose'? Are you saying the concept of a monad transformer wouldn't
exist if monads did compose? This makes no sense, as there are applicative
transformers despite the fact that you can compose applicatives freely.

~~~
mavelikara
> Monad transformers exist independent of the fact that monads don't compose.
> Can you explain what you mean by 'monad transformers exist because monads
> don't compose'?

I see what you mean.

You are right - the concept of Monad Transformers exist independent of the
fact that monads don't compose.

What I meant was that MTs exist _in Haskell programs_ because Monads don't
compose. Of course, there probably exists a Haskell program where this is not
the case, but I am certain MTs are largely used in Haskell because Monads
don't compose.

BTW, the grandparent is not the first to coin "MTs are .. use(d) to make
monads compose" usage. The late Paul Hudak et al writes in [1] that:

    
    
         A ground-breaking attempt to better solve the overall
         problem began with Moggi’s proposal to use monads to
         structure denotational semantics. Wadler popularized
         Moggi’s ideas in the functional programming community
         by showing that many type constructors (such as List) were
         monads and how monads could be used in a variety of
         settings, many with an “imperative” feel (such as in Peyton
         Jones & Wadler). Wadler’s interpreter design, however,
         treats the interpreter monad as a monolithic structure which
         has to be reconstructed every time a new feature is added.
         More recently, Steele proposed pseudomonads as a way
         to compose monads and thus build up an interpreter from
         smaller parts, but he failed to properly incorporate important
         features such as an environment and store, and struggled
         with restrictions in the Haskell type system when trying
         to implement his ideas. In fact, pseudomonads are really
         just a special kind of monad transformer, first suggested by
         Moggi as a potential way to leave a “hole” in a monad
         for further extension.
    

Notice the usage _Steele proposed pseudomonads as a way to compose monads_. So
this usage has been established in the Haskell community at least from 1995.
Why are you, presumably a Haskell programmer, surprised when someone repeated
that usage in 2018 on an internet forum?

[1]: Monad Transformers and Modular Interpreters
([http://haskell.cs.yale.edu/wp-
content/uploads/2011/02/POPL96...](http://haskell.cs.yale.edu/wp-
content/uploads/2011/02/POPL96-Modular-interpreters.pdf))

~~~
tathougies
> Why are you, presumably a Haskell programmer, surprised when someone
> repeated that usage in 2018 on an internet forum?

I hate the way monads in general are talked about in the Haskell community (I
also do not like the language for other algebraic terms). In particular, it is
common to say 'data type X is a monad'. This statement is completely
nonsensical. A monad is a thing along with some operations. Haskell data is a
concrete description of how to store a thing. By itself, a piece of data has
no operations associated with it. There is no way a particular data type could
be a monad, since a data type is just a thing.

The proper terminology is 'X forms a monad along with these functions' or 'X
has an instance for the Monad type class' (this is different, because the
monad type class allows for a subset of monads, not general monads). I am on a
personal mission to rid the Haskell world of sloppy language because it
confuses beginners, in my opinion. For a long time, I thought monads were a
thing. Then I realized they're just an algebraic structure, like groups or
rings.

When we say things like 'monads don't compose' it makes it seem like there is
some deficiency in the idea of a monad that makes them not compose, rather
than a realization that monad composition results in zero or more ways to
combine two arbitrary monads. Thinking just the former makes you wonder if
monads ought to be fixed. Realizing the latter means you realize that the lack
of a fix indicates that putting two monads together can accomplish a variety
of tasks, only one of which is likely suited to your use case.

~~~
evincarofautumn
> …it is common to say 'data type X is a monad'. This statement is completely
> nonsensical…

I think the reason for this is that in Haskell we model algebraic structures
using typeclasses, which are dispatched by type. So we say “X is a monoid,
with mempty and mappend defined as follows”:

    
    
        instance Monoid X where
          mempty = …
          mappend = …
    

Instead of “X, emptyX, and appendX form a monoid”:

    
    
        instance Monoid X emptyX appendX
        emptyX = …
        appendX = …
    

This leads to what I call the “newtype hack” for distinguishing different
monoids (resp. monads, &c.) on the same underlying type.

------
tm1810
"So, my friend Thomas Clarke (he's now at Imperial College) and I spent a lot
of time hacking on this"

Interesting, never released Tom Clarke was childhood friends with Simon
Peyton-Jones. He mentioned on a few occasions that we should all go learn
Haskell.

~~~
pjsg
Neither did I! Thomas Clarke, Duncan Maclean, Arthur Norman and I built the
SKIM (S,K,I Machine) at Cambridge in around 1980. This directly executed a
whole set of combinators -- it was built out of TTL and it had 32k 16-bit
words of memory and the microcode lived in 4k words of eprom -- it was maybe
100 ICs in all one two cards. I wonder where it is....

------
kwhitefoot
Well I never! I used that Elliott 803 at Swindon Technical College in 1973.
Before that (back to 1969) we used their terminal room in the evenings to dial
up to the Leasco service in London. We had written a time table program in
Leasco Basic (still have the quick reference card somewhere) for Park Senior
High School that did in one evening what a teacher used to spend a week doing.
It worked out the time table for 750 pupils, trying to satisfy the demand for
courses, class rooms, teachers, and laboratories. Telephone time to London was
so expensive then that we couldn't afford to print the results (300 baud
acoustic modem and teletype) so we had the results printed out on the line
printer in London and posted back to us.

------
pjungwir
I haven't read the link yet, but I'm curious if anyone here knows of any
research comparing Three-Valued Logic or SQL NULL to Category Theory and
Haskell's Maybe monad? They seem very similar to me: like mapping Nothing, the
SQL NULL is "contagious". It doesn't crash your program. I'd love to find a
paper comparing the two, but maybe they are just two untouching worlds of
research. Any thoughts?

Sometimes I think, "It'd be cool to define some custom types for Postgres that
are Maybe<Text>, Maybe<Integer>, etc." But then I think, "Actually, that's how
the built-in types work already!"

~~~
unhammer
Then you may find the discussion of NULL vs DEFAULT and Maybe's in
[https://ren.zone/articles/opaleye-sot](https://ren.zone/articles/opaleye-sot)
interesting.

------
Bye_Felicia
wrong thread.

~~~
stevejb
Did you post this to the wrong thread?

~~~
Bye_Felicia
Hey! How did this happen!? Mods move entire threads for folks?

That's pretty cool, I'm used to things being like the archaic TechDirt
commenting system...

