4 ms·

Oh well, he should try a language with types ... /me runs ...

• 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!
• pjmlp 9y ago
  All my favorite languages are typed and I do agree with him.
  • tome 9y ago
    Really? How so? If you have abstract types then you can easily make internal changes without making those changes visible externally.
    • pjmlp 9y ago
      Some examples, 1 - Not all changes can be kept internal, for example adding a new case to an ADT 2 - Internal changes can still alter the semantic of the API, even if from the outside everything still looks the same from the type system point of view
      • tome 9y ago
        Yes, both are true. 2 is a particularly good example.
    • gmfawcett 9y ago
      As a simple example, suppose I swap out one container type with another one in the internal code. Both implement the same interface/traits, so the change isn't visible to users. But the time complexity of the container operations are different on the new type, and the user was depending upon the time characteristics of the old container. E.g., deletions are now O(n) instead of O(1). I've violated a user expectation without breaking type safety.
      • tome 9y ago
        Nice counterexample!