0:00 / 0:00
#scala#typesystems#martinodersky
"The Trouble With Types" by Martin Odersky (2013)
Strange Loop Conference
88K subscribers • 114 videos on Hallway • Conference channel
- Recommended by 1 person: 1 in engineering communities.
- Presented by Martin Odersky
- An opinion. It argues one side of a question engineers disagree on.
Intermediate. Assumes working knowledge.
17K views5 years ago1 recommendation
Programming languagesComputer scienceLanguage design and type systemsComputation and complexity
Martin Odersky discusses the debate between static and dynamic typing, exploring the challenges and future of type systems.
[Recorded at Strange Loop conference (thestrangeloop.com) in St. Louis, MO, Oct 2013.] It's hard to find a topic that divides programming language enthusiasts more than the issue of static typing. To about one half of the community, types are a godsend. They provide structure to organize systems, and reduce the tedium of having to write unit tests. They prevent classes of runtime errors, make IDEs more helpful and provide a safety net for refactorings. To the other half, static types are pointless ceremony or worse. They limit the freedom of expression, are in the way of rapid prototyping, and make program code bulkier. Static types tend to increase the complexity of languages and their compilers and making sense of opaque type error message is often an exercise in frustration. Personally I am in the camp of static type advocates, even though I respect the opinions of the static type antagonists and sympathize with them. The question is: What needs to happen to make static typing less controversial than it is today? Ideally, a type system should refuse as many erroneous programs as possible, but accept all correct programs one would want to write. It should provide useful documentation about interfaces but get out of the way otherwise. It should be simple to define, with a clear semantics and a guarantee of correctness. But it should also be easy to learn and natural to use. The problem is that each of these criteria can be met in isolation but combining them requires many difficult tradeoffs. In the talk I will give an outline of the main categories of static type systems as well as some new developments, and discuss the tradeoffs they make. Martin Odersky Typesafe @odersky Martin Odersky is a co-founder of Typesafe, the creator of the Scala programming language, and a professor in the programming research group at EPFL, the leading technical university in Switzerland. Throughout his career, Martin's singular objective has been to make the basic job of writing programs faster, easier and more enjoyable. He wrote javac, the compiler used by the majority of today's Java programmers, and scalac, the compiler used by the fast-growing Scala community. He authored "Programming in Scala," the best-selling book on Scala. Previously he held positions at IBM Research, Yale University, University of Karlsruhe and University of South Australia, after having obtained his doctorate in 1989 from ETH Zürich as a student of Niklaus Wirth, the creator of Pascal.Why it's here
1 person recommends thisWhat people say. Recommended as a classic talk by Scala's creator on the trade-offs and design of static type systems.
Moments people linked to
u/georgreenin r/scala • Mentions
On “I don't get contravariance”
From Martin: [video
- Covers covariance
Demonstrates the concept (few seconds), it's all about being able to substitute types for other related types e.g
- If we have Type hierarchy of Person <- Employee, where Person in base and Employee is a child
- Then variance answers 2 question
- if we have a function that accepts a Person type as input, can it also take Employee as input?
- if we have a function that produces a Person type as output, can it also produce Employee as output?
- Answers question 1 Covariance (seems to make sense in input types)
- Given a function that accepts Employee as input, then it also accepts Person as input, this can be generalized as the most specifi…
u/sideEffffECtin r/scala • Mentions
On “"The Trouble With Types" by Martin Odersky”
Maybe it's related to the whole endeavour of encoding type parameters as type members
Talked about at link to this video
https://contributors.scala-lang.org/t/scala-3-type-parameters-and-type-members/3472
It would still be interesting to know more
/cc /u/odersky