"The Trouble With Types" by Martin Odersky (2013)

[@gzoechi]

TypeScript and even more Dart moved towards stronger and sound types. any is now even frowned upon in both languages by many

[@JanusTroelsen]

Why was this uploaded so many years after recording?

[@StrangeLoopConf]

This talk (and all Strange Loop 2010-2013 talks) were recorded in collaboration with InfoQ and the talk has been available on that site since 2013. We reached an agreement recently to also allow them to be uploaded to KZbin.

[@JasonUnderdown]

@@StrangeLoopConf It would be helpful viewers to put the year in the title.

[@StrangeLoopConf]

Done

[@X_Baron]

After a quick research it seems that since this talk, Dotty has been (mostly) renamed to Scala 3 but hasn't gained a lot of traction, probably because of compatibility issues. Scala 2.x is still being developed and is the Scala that is packaged for various operating systems.

[@ArthurBugorski]

Scala3 is currently at rc2 so no one should using it yet but library maintainers who are curious and proactive

[@avi3681]

At 24:00 he claims that TypeScript mishandles a function getEmployer which takes employees and returns his/her/their employer. However, this is not the case. It is true that if Employee is a more specific version of Person then TS lets you assign an employee object to a variable p with Person type. However, if you then try to call getEmployer(p) you get a compiler error "Argument of type 'Person' is not assignable to parameter of type 'Employee'." So this maintains type safety. If you think in terms of sets, the Person type is the set of all JS objects that have at least the defined properties, while the Employee type is a subset of Person since it adds additional properties which constrain membership. So, TypeScript assignment says that you can use an Employee anywhere you could use a Person since it is in the "set" of Person-shaped objects, but you can't use a Person where you need an Employee since the Person might or might not contain the added properties required to be an Employee. This behaviour is both intuitive and mathematically sound. One thing I didn't get is how this relates to covariance and contra-variance. It would be nice to have an example to illustrate this.

[@ayazhafiz8298]

I believe that what the speaker is claiming is that TypeScript admits functions from Employees to Employers where we would expect a function from a Person to an Employer. Consider the following example: www.typescriptlang.org/play?#code/C4TwDgpgBAChBOBnA9gOygXigbwL4G4AoUSKAUQFswAbZECaLOJNAMmwH0AjALgHIIVWvQh8CxcNEo06CTLAQpU7bv0Ez68MUUIAzAK6oAxsACWaKAHMIwacIQAKdfYg9yQ2RACUbu7Pg4UPA2+vDoqPrU1ACE+FC4hHqGJuboAIZgNCAAKsjMSg66qG4OkCzFCuVemAB87hoIADRQZUpu+WjV2IRQvX29RaWKnYQJhBlZuR2oDta2HprNeF74QA. Today, both of you are right -- with the strictFunctionTypes flag, this is indeed an error. But in 2013, before TS 2.6 (IIRC), TypeScript would always admit this. This problem demonstrates the type relation between a function T->U and a subtype of that function, say S->W. For a S->W to fit in T->U, it is necessary that anything that could fit into a T could also fit into an S. Thus we have that T is a subtype of S, and so the parameter of the function type S->W is contravariant to the function type T->U. Moreover we have that it is necessary that anything that anything that our function type S->W gives back must fit into what the function type T->U gives back, which means W must fit into U and so we have that the return type of S->W must be covariant to the return type of T->U. This describes the fact that function types are contravariant in parameter types and covariant in return types.

[@AaronNGray]

Trying to find end of 1990's paper and name of author mentioned @39:48, Kristen Captoro ??? goto conference organizer.

[@StrangeLoopConf]

I think that's Kresten Krab Thorup

[@AaronNGray]

@@StrangeLoopConf Thanks !

[@Nellak2011]

At a developer meetup, the devs there told me to learn TS but I expressed my concerns. I told them that JS is like living in a house without a fence, so as a result you are naturally more guarded and on edge for potential threats. TS is like having a fence, but there is a massive hole in it. I argue that this is even worse because you think you are safe but you are not, so you let bugs slip in due to your false safety. So therefore, using TS is actually worse than using JS that has no guard rails. I argued that if you want to use static typing in JS, you should go with a solution that has a sound type system, or else you will have a false sense of security. I recommended ReScript and said it has a sound type system and is based on OCaml and has a very nice syntax.