3 ms·

What are you trying to say? There are already a lot of explanations for why Clojure is dynamically typed and how it fills its role nicely that way.

by spraak 9y ago

tome 9y ago
I know, I know. We've been having some interesting discussions about Clojure, Haskell and dynamic and static typing on these stories https://news.ycombinator.com/item?id=15602658 https://news.ycombinator.com/item?id=15602658 https://news.ycombinator.com/item?id=15593069 https://news.ycombinator.com/item?id=15593069 My comment was intended to be a wry one referencing those very interesting discussions and hinting that if you have types then you can more easily make breaking changes internally that aren't visible externally.
- nickbauman 9y ago
  Dubious. The maintenance argument is weak. https://www.youtube.com/watch?v=2V1FtfBDsLU&feature=youtu.be&t=1h8m15s https://www.youtube.com/watch?v=2V1FtfBDsLU&feature=youtu.be...
  - tome 9y ago
    I'm not sure what you mean. I thought it was self-evident that if your interface is an abstract type then you can change the implementation without breaking consumers. If you don't think it's true then please can you explain how? I thought the Clojure argument is not that types don't provide beneficial encapsulation, but that it's not worth paying the cost for them. Again if you know any different I'd be pleased to hear.
    - nickbauman 9y ago
      Apples and Oranges. We're talking about changing the interface. Did you watch the video segment?
      - tome 9y ago
        > We're talking about changing the interface. Who's "we"? I'm talking about changing the implementation. > Did you watch the video segment? I watched the bit where he said if you add a constructor to a sum type you have to change everywhere it's pattern matched. True. I'd love to see Clojure's solution where you don't have to change any existing code! EDIT: Oh wait, I think it's even worse than that. I think he's talking about product types. In which case you should use projection functions and indeed you need to make no changes to old code!

What are you trying to say? There are already a lot of explanations for why Clojure is dynamically typed and how it fills its role nicely that way.

by spraak 9y ago

What are you trying to say? There are already a lot of explanations for why Clojure is dynamically typed and how it fills its role nicely that way.

tome 9y ago

I know, I know. We've been having some interesting discussions about Clojure, Haskell and dynamic and static typing on these stories https://news.ycombinator.com/item?id=15602658 https://news.ycombinator.com/item?id=15602658 https://news.ycombinator.com/item?id=15593069 https://news.ycombinator.com/item?id=15593069 My comment was intended to be a wry one referencing those very interesting discussions and hinting that if you have types then you can more easily make breaking changes internally that aren't visible externally.

nickbauman 9y ago
Dubious. The maintenance argument is weak. https://www.youtube.com/watch?v=2V1FtfBDsLU&feature=youtu.be&t=1h8m15s https://www.youtube.com/watch?v=2V1FtfBDsLU&feature=youtu.be...
- tome 9y ago
  I'm not sure what you mean. I thought it was self-evident that if your interface is an abstract type then you can change the implementation without breaking consumers. If you don't think it's true then please can you explain how? I thought the Clojure argument is not that types don't provide beneficial encapsulation, but that it's not worth paying the cost for them. Again if you know any different I'd be pleased to hear.
  - nickbauman 9y ago
    Apples and Oranges. We're talking about changing the interface. Did you watch the video segment?
    - tome 9y ago
      > We're talking about changing the interface. Who's "we"? I'm talking about changing the implementation. > Did you watch the video segment? I watched the bit where he said if you add a constructor to a sum type you have to change everywhere it's pattern matched. True. I'd love to see Clojure's solution where you don't have to change any existing code! EDIT: Oh wait, I think it's even worse than that. I think he's talking about product types. In which case you should use projection functions and indeed you need to make no changes to old code!