4 ms·
> You have to keep track of whether you compared against nil yourself. that's true in the case of comparing against nil, which I've already agreed with. I nev
by zemo 14y ago
> You have to keep track of whether you compared against nil yourself.
that's true in the case of comparing against nil, which I've already agreed with. I never said that Go is as safe as or safer than Haskell, I said that your assertion that there's "no way to branch and get type information" is a factual inaccuracy that misrepresents the language.
The fact that you haven't commented on type switches in any way shows that you're not really interested in anything other than your own sense of superiority.
Haskell is a better programming language. As a programmer of a programming language that is not Haskell, I am inferior to you.
There.
- Peaker 14y agoIt's not just comparing against nil, it's any comparison or switch-case besides a type-switch. A type-switch seems to be non-boolean-blind indeed, but it seems to have too much syntactic overhead, as Go code generally uses if branches when a type-safe case is due (e.g: When analyzing return codes).
- zemo 14y ago>it seems to have too much syntactic overhead yeah, it's pretty ugly. I don't think anyone in the Go community would disagree with you there. >Go code generally uses if branches when a type-safe case is due (e.g: When analyzing return codes). Sure, that's mostly true of that use case. The difference is that if you return multiple values, one of which is an error, the other returned value is often the zero-value for that type. If you have an error, the other value isn't de facto nothing. I have to admit that I've never used that "feature" and I can't even contrive a hypothetical situation where I would want to. The reality is that it's not a sin to branch on a value. If you want to do something based on whether one date is earlier than the other, I can't see why you would need to bring a type system to a boolean party. I think Rob Pike summed it up really well, when he said something to the effect of "people ask me why we would make a language that's not theoretically interesting, and they're right; Go isn't very interesting from a theoretical standpoint, it's just useful". They're not really setting out to revolutionize programming theory; they're setting out to revolutionize programming practice. Go is designed to let large numbers of non-genius-level programmers make concurrent software that's pretty stable, while Haskell is designed to scare the everliving shit out of anyone that sucks at programming. From my experiences, the Haskell programmers that I know are probably the smartest programmers I know that have never made anything that's of any interest to non-programmers. That's not really meant to say something about the value of that type of programming; I think it's valuable, it's just not the type of programming that I'm interested in doing. A friend of mine that is a Haskell programmer once showed me how great of a programming language Coq is by showing me how to prove that multiplication is commutative, which is probably the most intellectually masturbatory thing I've ever seen anyone do with programming. Of course, some of my other friends who were into that type of programming thought it was very, very cool. By contrast, I made some toy that I showed to my infant niece and it made her giggle and that made me happy. The happiness of my users is more important to me than the purity of my code. So... it just depends what you want to do. I think you're actually correct, and I appreciate what I've learned about Haskell's type system, but I think you're just missing the point of the Go project or what makes people like it. They haven't set out to make the most perfectly safe, beautiful and pure programming language, because Haskell already did that and the world doesn't need two Haskells; we just need a saner Java for writing big concurrent programs that can quickly compiled to machine code.