
The Little Typer - kakashi19
https://mitpress.mit.edu/books/little-typer
======
KirinDave
The book is fantastic. If you think this model is interesting, please consider
trying Idris and reading the Idris book:

[https://www.manning.com/books/type-driven-development-
with-i...](https://www.manning.com/books/type-driven-development-with-idris)

~~~
etatoby
I learned a bit of Idris on the book you link, but I gave up after trying to
implement Quicksort (the classical Haskell one-liner) in Idris vectors. You
need to manually write a page of theorems for Idris to accept it. It's crazy.

~~~
KirinDave
So don't write quicksort in Idris. It's not going to work very well anyways.
It's not at all well-suited, and isn't really even an especially important
sorting algorithm in a world where linear time sorting and constant time
indexed searches are a thing.

But most of the work you'd be doing to write quicksort is writing the
machinery for structurally recursive sorting, which a lot of tutorials write
not because you have to, but because it's a very good exercise for learning
how to write total functions that are recursive in a way DT systems can prove
totality on.

Most of these tools are in the contrib library (and the book mentions this).
For example the preorder interface you need:

[https://github.com/idris-lang/Idris-
dev/blob/master/libs/con...](https://github.com/idris-lang/Idris-
dev/blob/master/libs/contrib/Decidable/Order.idr)

------
cmrx64
This book is a real joy to read. I got to peek at a draft at OPLSS 2017 and
have been waiting impatiently for it to come out. The detailed, carefully
worked examples one after another that this style of book is famous for is
adapted beautifully to dependent type theory. Check it out! The code
implementing the language in the book is here: [https://github.com/the-little-
typer/pie](https://github.com/the-little-typer/pie)

~~~
dunham
Does the book discuss the implementation of the language or just usage of the
language?

~~~
bjz_
I believe it's more just how to use a dependently typed language (my copy is
still in the mail). Like the Little Schemer, it's written in the Socratic
style. I think the idea is that you can do it all in your head if you want,
with a piece of paper covering up the column with the answers.

If you are interested in the implementation, you can read more about it from
one of the authors:
[http://davidchristiansen.dk/tutorials/nbe/](http://davidchristiansen.dk/tutorials/nbe/)

------
plafl
I'm going to order it right now. I highly recommend the little schemer and the
seasoned schemer too! I have read all the titles (MLer and Java too) in the
series and those are my favorites. The only one I have not finished is the
reasoned schemer although I hope to try again in the future.

~~~
jsntrmn
I am just now (as of reading your comment) becoming aware of the "Little"
series. Is there a particular order in which one should read the books?

~~~
plafl
Little Schemer first and Seasoned Schemer second. The other ones are about
different independent topics and can be read in any order once you have read
the first two ones.

------
jedharris
Several comments elaborate on the big gap between normal programming practice
(e.g. structurally recursive algorithms) and the great difficulty of dependent
typing those practices. Some of these comment on how dependent types are "just
out of the lab".

This brings into focus a question I've had for a long time: Why this gap, and
especially in this direction? E.g. in aerodynamics we had Bernoulli's
principle for a couple of hundred years before we could build airplanes, which
depend on it. In formal language theory we had lambda calculus, Turing's
universality results, etc. decades before we had Lisp and Fortran.

We often see the difficulty of building a practice to exploit theory.

So it seems very strange to me that we are able to write / plug together
literally world-spanning software systems -- which do have bugs but fact work
correctly nearly all the time. But we can't easily well-type even simple
algorithms with extremely well understood properties.

Why this huge gap, in this direction?

~~~
KirinDave
I'd argue that there aren't many "simple" programs with "well-understood"
properties in use in industry.

Software is a bit different from architecture in that partial failures tend to
work and can be refined around repeatedly (a partially failed building tends
to rip itself apart, partial failures in software can linger for years and
only cease when their dependencies fault out). People are just more amenable
to altering their processes, products and lives around bad software.

I think dependent typing reveals to us, to some extent, what a house of cards
we truly have built for ourselves.

~~~
jedharris
Several interesting points but maybe they show something different from what
you intend.

Network stacks, databases etc. that correctly handle trillions of
interactions, some of them adversarial, have indeed been "refined around
[their failures] repeatedly" and have gotten pretty robust along the way.

On the other hand useful formal accounts of their behavior (distributed,
highly parallel, loosely coupled, asynchronous) seem far, far way.

It would be helpful to have an account of approximation to formal properties,
especially if that can help us understand how repair and refactoring can lead
to progressively better approximations.

Perhaps the house of cards that is revealed is formal methods not software.

~~~
KirinDave
> Network stacks, databases etc. that correctly handle trillions of
> interactions,

But they have also _incorrectly_ handled a similar order of magnitude of
transactions! Routing failures and issues that people troubleshoot around,
misconfigurations and bugs, and simple electromechanical glitches exist in the
real world and they're not some kind of zebra, you can force them by pining a
server.

Our networking systems "mostly work" because they're persistent, and because
(interestingly) the difference between a perfectly coordinated networking
system and a purely chaotic networking system with random traffic is actually
rather small compared to other domains.

> On the other hand useful formal accounts of their behavior (distributed,
> highly parallel, loosely coupled, asynchronous) seem far, far way.

Generally what makes a difference between a "robust" program and a brittle
program that simply falls over is how much of its own failure it attempts to
take into account. Even bad models of self-failure (pre-OTP erlang, for
example) are better than no model at all.

> Perhaps the house of cards that is revealed is formal methods not software.

Given that almost no one applies formal methods and dependent typing is by no
means a part of that discipline, I'm not sure it's fair to draw those
comparisons in this conversation.

Dependent Typing is not formal methods, nor is it verifcation. It's code that
allows for automated reasoning. It's closer to the machinery of formal
methods, like datalog or an SMT solver.

~~~
jedharris
Again lots of interesting points. Only time for one response.

You highlight networking but I also mentioned databases. Schematizing your
comment "Our... systems "mostly work" because... the difference between a
perfectly coordinated... system and a purely chaotic... system... is actually
rather small".

I think banks and customers would disagree rather violently regarding the
(distributed, asynchronous) system that handles credit card transactions.

And yet this system is certainly subject to a lot of attacks, not just random
errors.

~~~
KirinDave
> I think banks and customers would disagree rather violently regarding the
> (distributed, asynchronous) system that handles credit card transactions.

Do they? Most customers accept without question the idea that they have an
"available" balance distinct from their "current" balance.

It's also the case that when attacked the system typically fails and then the
fungibility of currency combined with the massive power of insurance is used
to pave over it.

------
DoofusOfDeath
I can't tell if my question is off-topic or not, but..

Can anyone recommend a book (or whatever) that introduces the aspects of type
theory relevant to a would-be language designer?

~~~
etatoby
I recommend these introductory lectures to Category Theory. I'm going through
them right now.

I assume you know some math/set theory and some Haskell, otherwise you may
want to work though some of the chapters in Real World Haskell first.

Oh and put the videos at 1.25× or 1.5× otherwise you will fall asleep.

[https://www.youtube.com/user/DrBartosz](https://www.youtube.com/user/DrBartosz)

~~~
bjz_
Don't get me wrong - CT is a super handy thing to learn, and it pops up a ton
when thinking about any software, including type checkers and compilers, but
the OP was specifically asking about type theory and programming language
implementation. Yes, you _can_ express lots of category theory in terms of
type theory (the dream is to implement all of it in terms of TT so that we can
mechanise it), but it won't be the best use of your time if you want to build
a type system.

~~~
etatoby
I probably phrased my suggestion wrong. Yes, it's not central to OP's enquiry.
But I did find a basic understanding of CT to help a lot when reasoning about
types, and that lecture series gives just that in a relatively simple way.

~~~
bjz_
Fair enough! Yeah, I've heard good things about that series.

------
zitterbewegung
Source code of pie (used in the book) at [https://github.com/the-little-
typer/pie](https://github.com/the-little-typer/pie)

------
Mythroat
Is there a reason dependent types are not more common?

~~~
daxfohl
They can make libraries a pain. Like imagine if someone write a library in
C#2025 with dependent types where functions took parameters like [i: i%2 == 0]
or whatever. And your big project has no existing dependent types. There's no
way to adopt this library unless you pull dependent types all the way in.

Or even if you did, but _your_ types were [i: i%4 == 0] or [i: (i+1)%2 == 1]
or whatever, you'd have to write proofs that they types were compatible. Even
some simple things are just not worth it.

~~~
danidiaz
If the project had no existing dependent types at all, couldn't you just
perform a runtime check before calling the library? The check would return
evidence that [i: i%2 == 0] for the particular i, or fail at runtime. If it
succeeded, then you could invoke the library using the new evidence.

One appealing aspect of dependent types is that they let you decouple
validation of inputs from the function calls themselves, while still
disallowing passing wrong inputs to the function by mistake.

~~~
bjz_
Yup, lots of people are under the impression that you need to prove everything
when it comes to DTs. That's not true - you can indeed push these checks to
runtime, and just have the compiler make ensure you do it.

------
mcguire
As an aside, it's great that Duane Bibby is still providing the art for these.
Without him, nothing would be the same.

~~~
leoc
Here's a 2006 TeX-user-group interview with Bibby:
[http://tug.org/interviews/bibby.html](http://tug.org/interviews/bibby.html)

------
nigwil_
Will there be a Kindle edition eventually?

~~~
kqr2
There doesn't appear to be kindle versions of older books including _The
Little Schemer_ , _The Seasoned Schemer_ , etc. so most likely not.

~~~
nikofeyn
there is one for _the little mler_.

------
lylecubed
> An introduction to dependent types, demonstrating the most beautiful
> aspects, one step at a time.

Is there a companion book detailing the ugly downsides of dependent types and
how to avoid them, one step at a time?

~~~
zem
I feel like people are misreading this comment, which is asking how to avoid
the pitfalls of dependent types, not how to avoid dependent types.

~~~
lylecubed
This. Thank you. I'm being rate limited, so this is the only post I'll be
making on this thread. My question was genuine. I want to learn both the
positives and the pitfalls of dependent types. I mimicked the book's
description because it amused me from a linguistic perspective. Looking back,
I probably should have phrased it differently.

------
urda
I'm glad I checked HN today because this sounds like a fantastic read. I went
ahead and picked up a copy of it for myself!

------
georgewsinger
What language does this book use? A dependently typed LISP? Or something
Haskelly?

~~~
cmrx64
it’s a pretty standard type theory lambda calculus, written as sexps because
it’s inside racket, but it’s its own thing.

------
zitterbewegung
Is there a place where you can download the source code that is used in the
book?

~~~
mullr
[https://github.com/the-little-typer/pie](https://github.com/the-little-
typer/pie)

------
jedharris
See related HN thread
<[https://news.ycombinator.com/item?id=18050706>](https://news.ycombinator.com/item?id=18050706>)

------
pkrumins

        This space reserved for JELLY STAINS!

------
sandGorgon
I know that typescript doesn't have advanced types, but can a book like this
be adapted to use typescript ?

~~~
IlGrigiore
This book does not talk about static typing, but about dependent types.
Dependent types are more powerful and expressive than simple types because
they convey more information. For example you could have [Int] to represent a
list of numbers, but you could also have [x: Int, x > 20 && x < 50]. Or you
could have an ordered array and know this fact by the type associated to the
array. Moreover, you need to use a theorem prover to show that applying a
function to a particular dependent type will result in the output dependent
type. This kind of programming is not well suited to be implemented into
typescript.

~~~
k__
So dependent types aren't static?

How does Idris solve this problem when compiling to JavaScript?

~~~
nardi
Dependent types are static. GP was trying to say that this book is about more
than just normal static typing (of the kind that TypeScript adds to
JavaScript).

There is no problem compiling dependent (or static) types to JaveScript, as
the type checks are done at compile time, and don’t require any support from
the JavaScript runtime.

------
sillysaurus3
Sad to say the book isn't on Library Genesis, so you'll have to drop $40 if
you want the knowledge.
[http://libgen.io/search.php?req=little+typer](http://libgen.io/search.php?req=little+typer)

Also Library Genesis is amazing:
[http://libgen.io/search.php?req=knuth](http://libgen.io/search.php?req=knuth)

It's everything I dreamed of when I was a kid. I used to spend hours at the
local library scouring through crummy "Learn C++ in 24 hours" type books.

[http://custodians.online/](http://custodians.online/) is worth a read too.

~~~
xevb3k
I feel like there’s so much to say about this comment, that I don’t even know
where to start.

So firstly I agree, $40 seems like a lot. I personally couldn’t justify it at
the moment. Particularly when the reproduction cost is nearly zero.

But $40 also doesn’t seem like a lot to pay for a book that will probably not
sell more than a few thousand copies. Most likely revenue generated won’t
fully cover the time and effort required to create such a book.

But... the author is also a professor at MIT. I feel like if this work wasn’t
somewhat publicly funded, it really should have been.

In the end, I’m left morally confused. But it feels like something is wrong in
the world when a book like this is available only to a select few, when for
the same capital outlay it could be available to everybody.

~~~
billsix
> In the end, I’m left morally confused. But it feels like something is wrong
> in the world when a book like this is available only to a select few, when
> for the same capital outlay it could be available to everybody.

Only to a select few? For $40? The book costs less than most console video
games.

~~~
sillysaurus3
Another way of phrasing that: The book costs as much as work that took dozens
of people years to make.

Also if you were to somehow poll everyone reading this and ask "Did you buy
this book?" you'd get some number, x. But if the book were priced at $5, then
$5 _y would be much greater than $40_ x.

I bought a bamboo fineline pencil for $50 the other day. It's a tool that will
serve me for at least a year. It's unclear whether this book would.

I want work like this to exist, and for the author to be rewarded for it. But
ultimately, in an era when words are infinitely and instantaneously copyable,
the economic value of words seems to drop.

Given the choice between stealing knowledge and not stealing knowledge, when
you wouldn't have paid for it anyway, where's the harm?

~~~
mjfl
The harm is less people writing books like this in the future. Every dollar
this book gets in revenue not only goes partly to the author, but goes into
the record as profits for that "genre" of books. Every dollar of revenue for
this book increases the value of the advance the author receives for the next
book, increases the probability that another author writing the same kind of
material will get accepted for publication. The harm you create by stealing
this book is that the market for that knowledge is destroyed.

~~~
sillysaurus3
Technology destroyed the market, not users of it.

I think you could've made the same sort of argument against movies or music
before netflix and napster, but here we are, and the markets still seem
thirsty for new content.

~~~
billsix
> I think you could've made the same sort of argument against movies or music
> before netflix and napster, but here we are, and the markets still seem
> thirsty for new content.

Because reasonable adults are paying for content which they want, directly via
movie tickets, indirectly via e.g. Netflix and Spotify.

~~~
xevb3k
Libraries, the same arguments apply to libraries. Which by your logic are not
morally justified.

