
Types, and Why You Should Care [video] - matt_d
https://www.youtube.com/watch?v=0arFPIQatCU
======
nordsieck
This[0] slide from Rich Hickey's Effective Programs talk[1] has really got me
thinking about the benefits of costs of typing.

    
    
      "The Problems of Programming"
    
      Domain Complexity
      Misconception
    
      10x
    
      Place Oriented Programming
      Weak support for information
      Brittleness/Coupling
      Language model complexity
      Parochialism/context
      weak support for Names
      Distribution
      Resource utilization
      Runtime intangibility
      Libraries
      Concurrency
    
      10x
    
      Inconsistency
      Typos
    

There are some type systems, for example Rust's, which integrate RAII into the
language as a first class concept and are able to address some of the upper
level concerns like concurrency and place oriented programming. In general,
however, there are many problems on this list where more complex type systems
doesn't help, or even makes it worse.

[0]
[https://twitter.com/stuarthalloway/status/926065084652228609](https://twitter.com/stuarthalloway/status/926065084652228609)
[1]
[https://www.youtube.com/watch?v=2V1FtfBDsLU](https://www.youtube.com/watch?v=2V1FtfBDsLU)

~~~
s6o
After watching that talk, I would have loved somebody in the audience to point
out instance like this [https://raygun.com/blog/10-costly-software-errors-
history/](https://raygun.com/blog/10-costly-software-errors-history/) and ask
for Hickey's comments.

Needless to say I really don't agree with that list, as history shows the
inconsistency, typos, lack basic units and the ability to express them in a
computation etc., have been more catastrophic than he believes them to be. And
these issues cannot really be fixed without a proper type system, that will
not allow stuff like that to get into production.

And a good type system cannot be optional, e.g. clojure's spec, There are
number of studies that show that will power, is not enough, there needs to be
and environment - a type system - that helps to avoid and catch mistakes.

~~~
flavio81
>After watching that talk, I would have loved somebody in the audience to
point out instance like this [https://raygun.com/blog/10-costly-software-
errors-history/](https://raygun.com/blog/10-costly-software-errors-history/)
and ask for Hickey's comments. Needless to say I really don't agree with that
list, as history shows the inconsistency, typos, lack basic units and the
ability to express them in a computation etc., have been more catastrophic
than he believes them to be.

From the list you cite, only three of 10 errors are caused by "typos", "lack
of basic units" and type errors.

And this is just a particular list.

Recalling Rich Hickey list, the things that cause more problem in code, from
worst to less damaging:

    
    
      Domain Complexity
      Misconception
    
      10x
    
      Place Oriented Programming
      Weak support for information
      Brittleness/Coupling
      Language model complexity
      Parochialism/context
      weak support for Names
      Distribution
      Resource utilization
      Runtime intangibility
      Libraries
      Concurrency
    
      10x
    
      Inconsistency
      Typos
    

I'm pretty sure that if we compile a list of real-life cases where the major
reasons of failure according to Rich Hickey have caused trouble, the list of
examples would be immense, compared to "typos".

------
dnautics
I strongly recommend reading about the Julia type system, which has had a lot
of thought put into it:

[https://docs.julialang.org/en/stable/manual/types/](https://docs.julialang.org/en/stable/manual/types/)

Although it's "untyped" (in the sense of the video), because it's _strongly_
typed, there are plenty of nonbrittle optimizations that are performed by the
compiler on account of the type system, and the result is something that's
often within 1~1.5x speed of C.

At the same time, I had to write my own numerical system and because of
Julia's type system i could immediately plug it into the standard library's
matrix algebra and fast fourier transform algorithms and do comparative
analyses out of the box. You can even do exotic things -- I was testing some
reed-solomon encoding and created a galois field type, and the standard
library matrix solve algorithm worked out of the box on my custom type.

~~~
dnautics
Addendum: Also really good is this video about how one should treat vectors
and matrices in a type system.

Has good lessons for python, R, and Matlab. Seriously anyone who does anything
with vectors should watch this.

[https://www.youtube.com/watch?v=C2RO34b_oPM](https://www.youtube.com/watch?v=C2RO34b_oPM)

------
mbrodersen
There are a lot of smart, experienced, thoughtful developers who _know_ from
experience that they are more productive using types. And there are smart,
experienced, thoughtful developers who _know_ from experience that they are
more productive _not_ using types. So something interesting is going on here.
Obviously this is not a situation where one of those choices is "objectively
correct". It is very likely that both groups are right. So what can we learn
from this? Perhaps that it depends on the developer _and /or_ the kind of
software they develop whether types make sense or not. It might also depend on
how well the developer understands type systems and the kind of exposure they
have had to them. I think THAT is a much more interesting conversation to have
than the usual "my way is better than yours" typical conversation we have had
SOOOOOOO many times.

~~~
kod
I have yet to see reliable commentary from developers who used a good static
type system for an extended period of time and still willingly prefer dynamic
types. For instance, Rich Hickey makes fun of how long it takes to learn
Haskell. I'm not aware of him having done significant work in anything better
than Java.

~~~
tome
I think Rich Hickey has significant experience with Haskell and there's at
least one former Haskell user on HN who has transitioned to Clojure. I still
don't quite get their point but I don't think they're speaking from ignorance.

~~~
kod
What are you basing the assertion about Rich Hickey's haskell experience on?
His github doesn't have any haskell code, for instance.

~~~
tome
It was reported here by some Clojurists and I took their word for it.

------
nnq
Didn't go through it all yet, but _its premise_ seems kind of off: you _can
't_ really discuss "types in isolation of the language"!

Just a basic example of two dynamic languages: In Python I can get a lot done
and really don't _miss types at all._ In JS otoh, I feel lost until I pull in
TypeScript to tame it, the language makes it even hard to _think clearly_
without types, like, "is that an object or a dict" or "is it a map? from what
to what?" etc. For most usual programmer mistakes that would be type errors in
typed language, Python still throws a meaningful and debuggable runtime error,
whereas JS carries on an breaks much further from the cause of the problems,
leaving you to debug WTF after WTF...

And static typing is great, as long as _it doesn 't require you to type
variables and anonymous or small utility functions/methods_... eg. _it sucks
without inference!_

Some languages work better with types, some don't gain much from them...

~~~
klmr
> In Python I can get a lot done and really don't miss types at all

No wonder, because Python _has_ types (well … most everything does; but Python
isn’t unityped [1]). It’s even relatively strongly typed. It’s just not
_statically_ typed (what the video calls “typed”).

That said, I _do_ miss static type checking in Python, and a lot of the
tooling and methodology around Python (pylint, TDD…) are a direct consequence
of that lack of static checking.

— You seem to be aware of this but the distinction between “has types” and
“has static typing” is actually fairly important. APIs in general often take
advantage of Python’s extensible type system.

[1] See e.g. [https://existentialtype.wordpress.com/2011/03/19/dynamic-
lan...](https://existentialtype.wordpress.com/2011/03/19/dynamic-languages-
are-static-languages/)

~~~
willtim
Read the article again. He says Python _is_ unityped. The word "type" in
mathematics and computer science has a meaning which is not the same as your
usage of the word.

Well-typed programs should not go wrong. Python programs can crash at runtime
due to simple type errors (expected integer but got a string). A crash is a
crash, from a theoretical point of view it matters not that the error is
prettier than a segmentation fault. Python is _not_ strongly typed, it just
has good error messages.

~~~
klmr
Blah you’re right. That’s quite a serious oversight on my part, it’s been too
long since I’ve read that article and I had apparently forgotten its core
idea.

------
nxc18
Skimmed the video, and it's interesting.

I find the (implicit) premise that you might not already care about types hard
to believe... Migrating a JavaScript project of any complexity to typescript
almost always reveals errors "for free" because of the typing. Certainly any
experience hacking on python would also teach you the lesson of declaring your
types ahead of time.

Is this old-fashioned thinking? Are types the SQL of yesteryear (in the
context of the crazy rush to "web scale" mongodb)?

~~~
Zyst
For the most part I feel that for 99% of problems types just “get in my way”.

It feels like I already know what is going to go in where, and having to type
it is just a waste of time.

That said, when I have to work with APIs that can not guarantee their data
integrity throwing in a quick @flow annotation of top of the file, and taking
the time to write out what is optional has proven very valuable to make sure
my functions, and subsequent code is not going to throw.

Another reason I like flow more is because I don’t need to convonce my team to
use it, I can just use it myself, and then delete it after I am done writing
my code.

~~~
kerkeslager
I think what you're talking about here is _static_ types getting in your way,
not just types getting in your way.

Strong/weak types and dynamic/static types are really two different spectrums.
People conflate strong types with static types and weak types with dynamic
types, but they aren't really the same thing.

Static/dynamic just has to do with whether the types are checked at compile
time or run time. Examples: Static: C, Haskell. Dynamic: Javascript, Python.

Weak/strong has to do with what kinds of checks the type system does. A strong
type system is capable of checking a lot of different things for you. Static
types are often stronger, but not always: for example, C is statically typed
but its type system checks hardly anything: int* + int is perfectly valid. A
list of programming languages from weakest-typed to strongest-typed might look
something like: JavaScript, C, C++, Common Lisp, Perl, Scheme, Ruby, Python,
Java, C#, OCaml, Haskell.

Static types are nice for projects which will grow large and where bugs are a
big problem, but I think for the average HN person, static types aren't really
necessary.

Strong types, on the other hand, are extremely useful. Even in a dynamically
typed language, they aid in debugging a lot, because type errors occur much
closer to where they're caused. In Python, for example, `"foo" \+ 42`
immediately fails. But in JavaScript, you don't get an error until much later,
perhaps when your webpage is mysteriously displaying "foo42".

Of course, there's a small cost to strong types: in the case where I actually
do want to append a number to a string, I have to do `"foo" \+ str(42)`. But I
think people tend to overstate this cost because it's visible. But if you look
at the big picture, typing five extra characters takes a lot less time than
debugging almost anything.

~~~
naasking
Strong/weak is generally not a useful distinction because it has no formal
meaning. What you're probably after is "expressiveness" and "soundness". So
C's type system is unsound and it's types are inexpressive. Haskell's type
system is sound and moderately expressive. Agda's type system is sound and
expressive.

~~~
kerkeslager
> Strong/weak is generally not a useful distinction because it has no formal
> meaning.

"This doesn't have a formal meaning, therefore it's not useful" is quite a
logical leap you've got there.

I've got over a decade of professional programming experience in which "strong
types" is a useful enough concept to help me do my job. "Soundness" certainly
gives stronger guarantees, but it's more than I've needed.

I'm not aware of "expressiveness" having a formal meaning, but my informal
definition has functioned for me so far.

~~~
naasking
> "This doesn't have a formal meaning, therefore it's not useful" is quite a
> logical leap you've got there.

It means that everyone defines strong and weak in their own way, which has
happened in every type system debate I've seen over the past 15 years.

> "Soundness" certainly gives stronger guarantees, but it's more than I've
> needed.

Soundness is exactly the metric you need. Either you can rely on your type
system not to lie to you, or you can't.

Programming language expressiveness means "Felleisen expressiveness". It's a
metric approximated by source code compression, which is why the great
programming shootout includes gzip metrics for source programs.

~~~
kerkeslager
> It means that everyone defines strong and weak in their own way, which has
> happened in every type system debate I've seen over the past 15 years.

Okay, that's fair. Part of the reason I gave examples and defined the spectrum
I was talking about was to address this problem, because I know people don't
necessarily know what I'm talking about.

------
iamjs
better audio:
[https://www.youtube.com/watch?v=yVuEPwNuCHw](https://www.youtube.com/watch?v=yVuEPwNuCHw)

~~~
TwoNineFive
OP link should be replaced with this one.

------
meuk
The video is an okay discussion of type systems and the pro's and cons, but
for me it didn't bring anything new to the table.

------
superlopuh
I think a lot of problems with types could be avoided if the package
management system / linking system required typing of imported functions, even
if the actual language doesn't.

Maybe there'll be a "safe" subset of the pip/npm registry that will only let
typed APIs in, to promote the concept.

As a side-note: is there data on how many dependencies there are of framework
on npm, on average? If it's anywhere past two, I'd say that the extra time
spent typing is more than compensated by the time saved by the user of the
API.

------
TwoNineFive
F __KING VOLUME WARNING !!!

This video will blow your f __king eardrums out because at the 4:37 minute
mark, the presenter switches on his microphone system and the input source of
the video changes to be about 400% what it was previously.

The fact that nobody has mentioned this is a pretty strong indication that
none of these people have actually watched this video.

