3 ms·

I've read the article and watched the video that it is a reply to. I both agree with the author and disagree. I disagree that Rich Hickey is wrong when it com

I've read the article and watched the video that it is a reply to. I both agree with the author and disagree. I disagree that Rich Hickey is wrong when it comes to whether those changes should be breaking or not. Those curves can be non-breaking, unlike what the author of the article claims. But I agree with the author that the fact that they are breaking doesn't really matter. Rich Hickey mentions this himself in his talk. He says that no one talks about the costs of using Option or Maybe. So then he lays out the costs. And I was...not that impressed. Sure, this change that should be non-breaking is breaking. And your downstream clients will have to change their code. That seems bad. Until you realize that the only change they would be forced to make is to delete what is now dead code. Sure, it's annoying; I don't deny that. But Rich Hickey claims that it increases code maintenance to have to make the change. I whole-heartedly disagree because any time you can safely delete code, you are making maintenance easier. Plus, despite all of his complaints that people don't considers costs, he never really considers the costs of his proposal, the biggest of which is the complexity of the language. I think the industry has rightly come to the conclusion that, all else being equal, and even sometimes when they are not, a more complex language is a worse language. I think proper union types, the kind needed here, would add enormous complexity to the language for little benefit in rare cases. (Because how often do programmers relax constraints? I don't think they do that often.) In my language, I'll keep Option as it is, and make such changes breaking, in order to avoid the complexity of union types.

pyrale 3y ago
> I think the industry has rightly come to the conclusion that, all else being equal, and even sometimes when they are not, a more complex language is a worse language. That was a theory behind golang, and the observed result is that you're better off having a little bit more language constructs that may be misused, than having essential complexity in your problem space that you can't easily describe in your solution space, for lack of tools.
- gavinhoward 3y ago
  That's why I said "all else being equal." Go took it too far.
dgb23 3y ago
It’s interesting that your definitions of complexity and simplicity are very different from Hickeys. In “Simple made easy” he defines complexity as entanglement and simplicity as the opposite of that. A proper union Option = T|None, is simpler than a sum type Option<T> = Option{T, None}, because the latter complects the types into a container. It’s even worse with nominal types because it complects both yhe structure and the name. I think you think of complexity of language implementation (compiler) or runtime complexity? That’s a fair argument! It highlights a different preference.
- gavinhoward 3y ago
  I meant that, but I also meant the definition he uses. Yes, it "complects" the types into a container, but then you write code to handle the container, and only the container, until you are ready to open it up. With union types, you must write code to handle all types in the union always. This complects the code written in the language. It is also an obvious entanglement and meets his own definition of complex.
nlitened 3y ago
> And your downstream clients will have to change their code. That seems bad. > Until you realize that the only change they would be forced to make is to delete what is now dead code. > Sure, it's annoying; I don't deny that. But Rich Hickey claims that it increases code maintenance to have to make the change. I whole-heartedly disagree because any time you can safely delete code, you are making maintenance easier. When every one of 100 libraries you depend on, does that once a month, you are forced to perform hours of daily unproductive and annoying busywork unrelated to your goals, just because every lib author wants to make your maintenance easier! Of course, at some point you get fed up and just freeze all your library versions and stop ever updating your dependencies—which is arguably the opposite of what everybody should strive for. > I think proper union types, the kind needed here, would add enormous complexity to the language for little benefit in rare cases. Yes, and there's another, simpler way which proved to be working well: dynamic typing.
- gavinhoward 3y ago
  > When every one of 100 libraries you depend on, does that once a month, That's not the rebuttal you think it is. I mention this specifically in my post: how often do programmers actually relax constraints? I don't think they do it very often. > Yes, and there's another, simpler way which proved to be working well: dynamic typing. Funny thing: I implemented something close to Clojure's map stuff in C. It really is dynamic, with checks at runtime. Having only dynamic typing in a language is as much a mistake as making it complex
  - nlitened 3y ago
    > I mention this specifically in my post: how often do programmers actually relax constraints? I don't think they do it very often. I think every time a new parameter is added to a function, or some new "mode" of calculation gets supported, or a new field is added to a struct, etc. I personally do that all the time, but it's very hard for me to estimate how often other programmers usually do that. > Having only dynamic typing in a language is as much a mistake as making it complex I am interested in your thoughts why.

pyrale 3y ago

> I think the industry has rightly come to the conclusion that, all else being equal, and even sometimes when they are not, a more complex language is a worse language. That was a theory behind golang, and the observed result is that you're better off having a little bit more language constructs that may be misused, than having essential complexity in your problem space that you can't easily describe in your solution space, for lack of tools.

gavinhoward 3y ago
That's why I said "all else being equal." Go took it too far.

dgb23 3y ago

It’s interesting that your definitions of complexity and simplicity are very different from Hickeys. In “Simple made easy” he defines complexity as entanglement and simplicity as the opposite of that. A proper union Option = T|None, is simpler than a sum type Option<T> = Option{T, None}, because the latter complects the types into a container. It’s even worse with nominal types because it complects both yhe structure and the name. I think you think of complexity of language implementation (compiler) or runtime complexity? That’s a fair argument! It highlights a different preference.

gavinhoward 3y ago
I meant that, but I also meant the definition he uses. Yes, it "complects" the types into a container, but then you write code to handle the container, and only the container, until you are ready to open it up. With union types, you must write code to handle all types in the union always. This complects the code written in the language. It is also an obvious entanglement and meets his own definition of complex.

nlitened 3y ago

> And your downstream clients will have to change their code. That seems bad. > Until you realize that the only change they would be forced to make is to delete what is now dead code. > Sure, it's annoying; I don't deny that. But Rich Hickey claims that it increases code maintenance to have to make the change. I whole-heartedly disagree because any time you can safely delete code, you are making maintenance easier. When every one of 100 libraries you depend on, does that once a month, you are forced to perform hours of daily unproductive and annoying busywork unrelated to your goals, just because every lib author wants to make your maintenance easier! Of course, at some point you get fed up and just freeze all your library versions and stop ever updating your dependencies—which is arguably the opposite of what everybody should strive for. > I think proper union types, the kind needed here, would add enormous complexity to the language for little benefit in rare cases. Yes, and there's another, simpler way which proved to be working well: dynamic typing.

gavinhoward 3y ago
> When every one of 100 libraries you depend on, does that once a month, That's not the rebuttal you think it is. I mention this specifically in my post: how often do programmers actually relax constraints? I don't think they do it very often. > Yes, and there's another, simpler way which proved to be working well: dynamic typing. Funny thing: I implemented something close to Clojure's map stuff in C. It really is dynamic, with checks at runtime. Having only dynamic typing in a language is as much a mistake as making it complex
- nlitened 3y ago
  > I mention this specifically in my post: how often do programmers actually relax constraints? I don't think they do it very often. I think every time a new parameter is added to a function, or some new "mode" of calculation gets supported, or a new field is added to a struct, etc. I personally do that all the time, but it's very hard for me to estimate how often other programmers usually do that. > Having only dynamic typing in a language is as much a mistake as making it complex I am interested in your thoughts why.