14 ms·

This is an outstanding point. When watching this talk, I got the distinct impression that Rich has simply worked on a very different class of problems than the

This is an outstanding point. When watching this talk, I got the distinct impression that Rich has simply worked on a very different class of problems than the ones I have worked on. As we all are wont to do, we extrapolate our experience to the whole universe. But that's not always the right thing to do. I would say that for the most part, a statically typed language can do the same things a dynamic language can do, but not the other way around. Another commenter mentions the Any type, but I don't think that's it. It's maps. Rich wants to be able to combine maps with a union operation, take subsets of keys, etc. And that is exactly what maps afford. I'd rather work in a language like Haskell where I can use strong types when I need them and drop down to untyped maps when I need them than a language like Clojure where all I ever have is the maps. Another thing static types do for you is that they make things in your application more discoverable. Instead of tracing through to figure out which data is available and operations something supports, the compiler tells you. I'd rather work in a language where my compiler can help me this way than in one where it can't.

AriaMinaei 9y ago
Sorry to go off-topic, but this was a very nice sentence: "We extrapolate our experience to the whole universe."
- sova 9y ago
  Nicely sieved out! I too found this sentiment very essential.
stuartaxelowen 9y ago
Dynamism is certainly available to statically typed languages, but I believe the problem comes at how difficult it is to write dynamic code in static-typed languages, and to use the common building blocks that help you solve real problems. Writing dynamic code in static languages is like running through mud, just like writing static checking in dynamic languages is. I think both paradigms are important and valuable for different applications, but I have never seen a language that does both in any truly useful way.
- erokar 9y ago
  I think the gradual typing TypeScript provides is pretty useful, with relaitvely low friction.
weavejester 9y ago
"a statically typed language can do the same things a dynamic language can do, but not the other way around" It's interesting you'd say that, as I'd consider the opposite to be true. There are functions that are trivial to write in a dynamically typed language, but are hard to statically type. For instance, the `assoc-in` function in Clojure. "Another thing static types do for you is that they make things in your application more discoverable. Instead of tracing through to figure out which data is available and operations something supports, the compiler tells you." You don't necessarily need static typing to give functions some form of type signature or specification.
- flavio81 9y ago
  I also find the opposite to be true, as you do. The human mind and human problems, operate more like a dynamic language. To put it in a simple, silly example: When i tell you to "cut something with a scissor", the scissor doesn't specifically cut paper; there are many things that can get cut by a scissor. Or when you take a pot, put it over the stove and boil water, you do it and the pot is not specifically designed to boil water, the pot can heat anything; so you can say that many operations (verbs) in real life do not get performed in a "static typing" way, but in a "dynamic typing" or at least "duck typing" way.
  - bbatha 9y ago
    Both of those examples are trivially modeled with typeclasses (java style interfaces will also cut the mustard here too). Your paper example I would have a “Cutter” and “Cuttable” type classes to describe things that cut and can be cut. In languages like Haskell this only involves a couple extra lines of ceremony over writing a “cut” method on each type. The pot example is even cleaner with types and show the power of them. I’d have a Pot typeclass that can heat things. I’d have a liquid class for all liquids that water implements and finally a boil free function that takes a pot and a liquid. Exactly as expressive but now with compile time checking.
    - dragandj 9y ago
      All this is covered in Rich's talk. Your Cutter and Cuttable are different from my Knife and Cuttablito. When your program needs to talk to outside world, it all becomes messy.
DigitalJack 9y ago
I mainly program in clojure. The experience is just too good to be swayed by the bad points. That said, I wrote a moderately complex program recently where having dynamic types was a hindrance. I had to do mental book keeping in order to make sure I was constructing correct structures. I frequently didn't and the bugs were hard to track down. However, Clojure Spec came along, and I applied it to the problem. The difficulties became surmountable. It's a case where if I had been fluent in haskell, I probably would have used it. But I'm not, and this project was for work, so I didn't have the luxury of time to figure it out. Spec alleviates mental book keeping of structures by adding checkers and clarifying/codifying intent.
- hellofunk 9y ago
  How much Spec do you sprinkle in your code? I'm often using a keyword to query a map. Should I always spec/assert the return of this simple and common task? Because if you type the wrong keyword, a typo or just because you confuse different keywords in your mind, then it doesn't matter how much spec you have applied to the top-level data structure, the function arguments or other things, you still end up with a very easy nil or just incorrect value floating through your data transformations. The only way I see to have a lot of confidence is to add Spec to every new binding that is created, confirming that all named values are exactly what you think they are. Perhaps that is how most Spec users are working? That would mean asserting every item in a "let" for example.
  - GlennS 9y ago
    I would suggest that, rather using spec everywhere, you can use it as a barrier to contagion. That is, only checking that data conforms to your spec when it goes through the major interfaces between parts of your program. In this approach, you're not relying on spec to verifying the correctness of everything. Rather you use to reduce surprise bugs where a little change here makes something weird and unexpected happen all the way over there.
    - DigitalJack 9y ago
      Agree, this is my approach. Also, I do checks on the data structure, less on how they are used. So if a function expects a certain structure I’ll spec that. But I don’t do checks on getter setter type operations.
kaeluka 9y ago
My take: "a statically typed language can GUARANTEE the same things a dynamic language can GUARANTEE, but not the other way around. A dynamically typed language can PERMIT the same things a static language can PERMIT, but not the other way round."

AriaMinaei 9y ago

Sorry to go off-topic, but this was a very nice sentence: "We extrapolate our experience to the whole universe."

sova 9y ago
Nicely sieved out! I too found this sentiment very essential.

stuartaxelowen 9y ago

Dynamism is certainly available to statically typed languages, but I believe the problem comes at how difficult it is to write dynamic code in static-typed languages, and to use the common building blocks that help you solve real problems. Writing dynamic code in static languages is like running through mud, just like writing static checking in dynamic languages is. I think both paradigms are important and valuable for different applications, but I have never seen a language that does both in any truly useful way.

erokar 9y ago
I think the gradual typing TypeScript provides is pretty useful, with relaitvely low friction.

weavejester 9y ago

"a statically typed language can do the same things a dynamic language can do, but not the other way around" It's interesting you'd say that, as I'd consider the opposite to be true. There are functions that are trivial to write in a dynamically typed language, but are hard to statically type. For instance, the `assoc-in` function in Clojure. "Another thing static types do for you is that they make things in your application more discoverable. Instead of tracing through to figure out which data is available and operations something supports, the compiler tells you." You don't necessarily need static typing to give functions some form of type signature or specification.

flavio81 9y ago
I also find the opposite to be true, as you do. The human mind and human problems, operate more like a dynamic language. To put it in a simple, silly example: When i tell you to "cut something with a scissor", the scissor doesn't specifically cut paper; there are many things that can get cut by a scissor. Or when you take a pot, put it over the stove and boil water, you do it and the pot is not specifically designed to boil water, the pot can heat anything; so you can say that many operations (verbs) in real life do not get performed in a "static typing" way, but in a "dynamic typing" or at least "duck typing" way.
- bbatha 9y ago
  Both of those examples are trivially modeled with typeclasses (java style interfaces will also cut the mustard here too). Your paper example I would have a “Cutter” and “Cuttable” type classes to describe things that cut and can be cut. In languages like Haskell this only involves a couple extra lines of ceremony over writing a “cut” method on each type. The pot example is even cleaner with types and show the power of them. I’d have a Pot typeclass that can heat things. I’d have a liquid class for all liquids that water implements and finally a boil free function that takes a pot and a liquid. Exactly as expressive but now with compile time checking.
  - dragandj 9y ago
    All this is covered in Rich's talk. Your Cutter and Cuttable are different from my Knife and Cuttablito. When your program needs to talk to outside world, it all becomes messy.

DigitalJack 9y ago

I mainly program in clojure. The experience is just too good to be swayed by the bad points. That said, I wrote a moderately complex program recently where having dynamic types was a hindrance. I had to do mental book keeping in order to make sure I was constructing correct structures. I frequently didn't and the bugs were hard to track down. However, Clojure Spec came along, and I applied it to the problem. The difficulties became surmountable. It's a case where if I had been fluent in haskell, I probably would have used it. But I'm not, and this project was for work, so I didn't have the luxury of time to figure it out. Spec alleviates mental book keeping of structures by adding checkers and clarifying/codifying intent.

hellofunk 9y ago
How much Spec do you sprinkle in your code? I'm often using a keyword to query a map. Should I always spec/assert the return of this simple and common task? Because if you type the wrong keyword, a typo or just because you confuse different keywords in your mind, then it doesn't matter how much spec you have applied to the top-level data structure, the function arguments or other things, you still end up with a very easy nil or just incorrect value floating through your data transformations. The only way I see to have a lot of confidence is to add Spec to every new binding that is created, confirming that all named values are exactly what you think they are. Perhaps that is how most Spec users are working? That would mean asserting every item in a "let" for example.
- GlennS 9y ago
  I would suggest that, rather using spec everywhere, you can use it as a barrier to contagion. That is, only checking that data conforms to your spec when it goes through the major interfaces between parts of your program. In this approach, you're not relying on spec to verifying the correctness of everything. Rather you use to reduce surprise bugs where a little change here makes something weird and unexpected happen all the way over there.
  - DigitalJack 9y ago
    Agree, this is my approach. Also, I do checks on the data structure, less on how they are used. So if a function expects a certain structure I’ll spec that. But I don’t do checks on getter setter type operations.

kaeluka 9y ago

My take: "a statically typed language can GUARANTEE the same things a dynamic language can GUARANTEE, but not the other way around. A dynamically typed language can PERMIT the same things a static language can PERMIT, but not the other way round."