
Bracha v Felleisen “Types for an Untyped World” (2015) [video] - mpweiher
https://www.youtube.com/watch?v=JBmIQIZPaHY
======
mpweiher
Some highlights:

Q: "Do you hate static types" GB: "No" MF: "No"

GB: "Types are useful for: 1\. Doc for human 2\. Doc for machine 3\. Making
things faster … 4\. Correctness"

This was experience from the Strongtalk project, which implemented a fast,
typed Smalltalk. Strongtalk was purchased by Sun and the tech. was the basis
for Java's Hotspot. They actually _expected_ the correctness factor to be much
higher, but in practice the static type system only helped to find one or two
minor bugs in largely unused code-paths in the libraries. I also find it
interesting that "making things faster" is on the list, because the mantra
from that part of the discipline has always been that static types do not help
for performance, because the JIT will fix it all.

MF: “Research on Types and Soundness _smothers_ research on programming
languages”

Clarifying, says something along the lines that you have to figure out more
powerful/better language mechanisms first, then later start thinking about how
to type them properly.

~~~
Crazywater
They're so right about that. As a frontend dev, I don't care about that extra
1-2% of bugs that, say, ownership types could catch if it kills my
productivity by having to annotate everything.

However, if I can figure out what a method actually returns and click through
to it in the IDE, that's the real gain from types for me. Type analysis has to
be fast to be able to do that.

My impression of research in academia is that it's disproportionately focused
on even stronger types that are even harder to compute. Not everyone builds
spaceships.

~~~
hacker_9
Just going to point out here that you are conflating Javascript problems with
dynamic language problems. Try Clojure, a well designed dynamic language, and
you'll find you are a lot more productive with it than any statically typed
language.

Indeed over the weekend I was able to design and build a GUI DSL, layout
system, model-view databinding, command event system, and
serialisation/deserialisation logic for a side project of mine. This sort of
stuff would have taken weeks of effort in a static language.

~~~
wtetzner
Clojure is a fine language, and I wrote it professionally for a few years.

However, I don't see why this would be true:

> This sort of stuff would have taken weeks of effort in a static language.

I've also written plenty of things in typed languages, and in many ways they
can be faster to develop in than dynamic languages. Of course, you do need to
change the way you program a bit to really take advantage of types.

I think the main advantage Clojure has over most typed languages is macros,
but there is work being done to rectify even that.

~~~
hacker_9
I used to think this, until I used Clojure. I'm surprised you used it
professionally and have that mindset, I write far less code in Clojure and get
far more done. The productivity gains are amazing, especially when I can just
upload new code on the fly as the program is running.

~~~
wtetzner
Part of the issue is maintenance. Coming back to code you haven't worked on in
a while can require more time to load back into your head than a typed
language. And speaking from experience [1], refactoring in a typed language
also tends to go more smoothly.

> I'm surprised you used it professionally and have that mindset

I used to have your mindset when I first started working with Clojure :)

Keep in mind that not all typed languages are created equal. Clojure is still
much better than Java. But I find I'm quite productive with OCaml, due in
large part to the simple but powerful type system, plus the fantastic module
system. OCaml does have some drawbacks compared to Clojure, but they're not
related to static typing. The main disadvantages are the macro system (even
the new extension point stuff is cumbersome compared to a proper macro system)
and the smaller library ecosystem.

[1] I've done a lot of refactoring in Clojure, and while it wasn't terrible,
types can help a lot.

[Edit] To be clear, I do think Clojure has a lot going for it, but I don't
think any of it's advantages are due to being dynamically typed, and there's
no reason a statically typed language can't have the same benefits.

------
agentultra
I think it's tragic how easily dismissed ML/Miranda-evolved languages are
considered _a priori_ bad.

What is more interesting about a sound type system is what category theory
enables. Proven composition, sound abstractions, etc. I'm not a huge fan of
category theory but it undeniably useful. In practice this means we get very
rich, provable composition.

It's quite liberating how far good, reasonable constraints can take you.

~~~
mafribe

       it's tragic 
    

Fortunately, this is a minority opinion in programming language research
today. Bracha/Felleisen have lost this fight.

------
hota_mazi
Dart could have been such a great language if it was statically typed but
Bracha's obsession with dynamic types ruined that effort.

~~~
Crazywater
They pivoted a lot in that direction. Dart's strong mode is statically typed
and sound and all that, except that you can say "dynamic" if you really need
to.

~~~
hota_mazi
Yes, so they realized that statically typed languages are superior years after
creating the language, which is something we've learned and known for more
than ten years.

Retrofitting a type system into a dynamically typed language has never been
done successfully and it's unlikely Dart will invalidate that claim.

It's really a pity, Dart could have been a game changer.

~~~
rbehrends
I don't think they had any such "realization" about a superiority of static
typing, especially as research indicates that there are tradeoffs between
dynamic and static typing, not that there is superiority of one or the other
model. Both Bracha and Felleisen tend to fall in the soft [1] or gradual [2]
typing camp, after all. See, for example, Bracha's paper on pluggable type
systems [3].

As for retrofitting a type system into a dynamically typed language, Dart had
gradual typing from the beginning (with types being checked at runtime), so
it's an entirely different beast from (say) Ruby or Python.

[1] [http://wiki.c2.com/?SoftTyping](http://wiki.c2.com/?SoftTyping)

[2]
[https://en.wikipedia.org/wiki/Gradual_typing](https://en.wikipedia.org/wiki/Gradual_typing)

[3]
[http://bracha.org/pluggableTypesPosition.pdf](http://bracha.org/pluggableTypesPosition.pdf)

~~~
hota_mazi
> especially as research indicates that there are tradeoffs between dynamic
> and static typing

Not really.

How come there are plenty of dynamically typed languages that are migrating
toward optionally static typing but never the other way around?

Even Bracha himself, a very strong advocate of dynamically typed languages,
has felt the need to work on Strongtalk and then later, to have Dart support
optional static types.

Today, we have very good type inference engines and there is really no reason
to ever want to use a dynamically typed language. This is the trend, this is
the present and the future.

Javascript is going to be around for a while for legacy reasons but in a few
years, we'll look back at dynamically typed languages with a fond "Yeah, it
was a good idea at the time but we know better now" look.

~~~
rbehrends
> Not really.

Can you provide support for this claim? Existing research [1] seems to
indicate that it isn't clear-cut at all.

> Today, we have very good type inference engines and there is really no
> reason to ever want to use a dynamically typed language.

Type inference has its shares of issues once you're dealing with non-local
type inference, subtype polymorphism or parametric polymorphism.

[1] [https://danluu.com/empirical-pl/](https://danluu.com/empirical-pl/)

~~~
wtetzner
> Type inference has its shares of issues once you're dealing with non-local
> type inference, subtype polymorphism or parametric polymorphism.

Just wanted to point out that actually, type inference works quite well with
parametric polymorphism, like in ML. Even non-local type inference can work
fine given other constraints, also like in ML.

~~~
rbehrends
1\. Only for unconstrained parametric polymorphism. For constrained parametric
polymorphism, ML requires functors (don't get me wrong, I think ML functors
are brilliant, but they do require you to be rather explicit about your
typing).

2\. I wouldn't say that it's without problems even for unconstrained
parametric polymorphism. Consider the value restriction [1] and the fact that
if you add subtyping to the mix (as in OCaml), you're getting some really non-
trivial issues (as Scala found out the hard way).

[1] [http://mlton.org/ValueRestriction](http://mlton.org/ValueRestriction)

~~~
wtetzner
Yes, subtyping makes everything more complicated. I think there was a paper
about type inference for subtyping posted on HN a while back, but I don't
remember much about it.

