3 ms·

2. Nullability is an implicit sum you have everywhere. One that is not checked for exhaustiveness by the compiler. What do you mean "a zero value would be impo

by Peaker 13y ago

2. Nullability is an implicit sum you have everywhere. One that is not checked for exhaustiveness by the compiler. What do you mean "a zero value would be impossible"? The whole idea is that sometimes you need it, and sometimes you don't, so you want your language to let you distinguish these 2 cases and then check for your program's exhaustiveness in checking it when you do have a zero value. The fact dereferences are checked converts one runtime error into another. Proper sum types convert a runtime error into a compile-time error. How do you possibly view this as "most of the same benefits"? 3. No, they allow you to use the wrong value when there actually was an error and the value has a different meaning than intended (or just another nil dereference). The type system forces you to have either error checking or you can use explicit type system escape hatches which are then greppable. For example, Haskell does have unsafe functions like "fromJust" which unsafely assume a result value is not an error -- but these functions are rightly considered a code smell. If you want to use them, you can, at least making the smelly parts of the code easily findable. In Go, all the code is smelly, instead. 4. Type switch statements are so clunky I don't think they can, with a straight face, be considered "effective" alternatives for pattern matching. Consider: myFunction Nothing = ... myFunction (Just x) = ... This is understandable. This is effective. Do you think the equivalent type switch in Go is? Type systems don't become cages and aren't "crutches". They are tools that you can use as much as you want. A program in Haskell can be written to be type-unsafe and put all the code in useless types. Or it can encode any amount from very little to a lot in the type system. It's just a tool you get to choose how much of your invariants you want to verify. Go doesn't offer you that tool.

taliesinb 13y ago
2. Re zero value: If pointers were by default not nullable, then the zero value of a struct containing pointers would have to recursively allocate objects to fill those pointers. That's a deal-breaker for the notion of zero values. 3. Null values are almost always what result, as opposed to undefined or incorrect values. So it's a product type that is effectively a sum type. As for code smells: actually, there is a greppable equivalent in Go, and it is "... , _ := ... ". Future Go compilers might allow for a flag that treats "error" types specially in this regard. Interesting to hear about fromJust, didn't know about it. My own experience is that unchecked errors aren't where Go's 'debugging load' lies. The load is often in reasoning about concurrence, causal dependancies, and state machines. 4. If you're saying that because pattern matching isn't a core feature of Go, you wouldn't use it for everyday code, you're right. I'm a fan of pattern matching, I use it in Mathematica all the time (albiet unchecked). But my point stands: you can build sum types through interfaces, and when that makes a design significantly cleaner, a decent Go programmer will use it. 5. "Type systems don't become cages": well, a lot of people will disagree with you there. Ask C++ programmers about const. Ask Java programmers about checked exceptions. Ask Haskell programmers about logging. So I guess that's just, like, your opinion, man. :) 5.1. Go may not offer you as rich type verification as Haskell, but it does things Haskell can't: it can detect race conditions, for example, in concurrent code [I shudder to think how you even write concurrent code in Haskell]. Another closing thought: you focus a lot on Haskell. Haskell seems to be a very fecund place to devise type-theoretic patterns and techniques. And it seems to have taken the niche of "programming-language research testbed", which also results in a lot of interesting ideas. But there isn't nearly as much evidence that it is a smart choice for production code. I've been impressed by what I've seen, read, and understood about Haskell. Still, I have an unshakable impression that a lot of the quality that is associated with Haskell code is explained better by the hypothesis that the bar for writing Haskell code is very high: bad programmers can't write Haskell programs that do the things they want to do, so we see a lot of nice Haskell code and little bad Haskell code because of the base competency of the audience. But that doesn't imply that an experienced programmer would write higher quality code in Haskell than in Clojure or Go. We all have a complexity budget to spend on using tools to their full potential and doing things a certain 'proper' way. Simple languages leave more of that budget to spend on your program itself. Type-heavy languages leave less, with the promise that the cost is amortized. Calling Go a "sad language" and implying its authors are incompetent because you don't agree with their particular choice of budget demonstrates, to me, a certain arrogance and lack of imagination.
- Peaker 13y ago
  2. Why does the struct need a zero value? If it does, why not wrap it in an option/Maybe? 3. So that means you might get both a success and error value at the same time? And ignore one of them? As for concurrent problems being worse than nullability, that sounds very plausible -- as Go also messed up concurrency by making any guarantee about immutability of shared state impossible. 4. That means the threshold for using sum types is pretty high -- which means you end up not using them when you ought to (e.g: error products rather than sums). Sum types would make error handling significantly cleaner, but are not used that way in Go. 5. I think C++ programmers rather like const. Maybe you are confused with C programmers? C just got const all wrong. Java got checked exceptions wrong, too. Haskell logging is not a serious problem in my experience. Debug logging is done the same impure way as in other languages. Production logging is easy to add as a feature to your monad stack. Some bad type systems become cages -- and then people hate all type systems. Ironically, Go also has a type system, and since it is a rather poor one, it is a cage as well. 5.1: I'm sorry but this point of yours shows rather extreme ignorance about Haskell. Haskell can statically prevent race conditions. The facilities for writing concurrent code in Haskell are far more advanced than those of Go. > But there isn't nearly as much evidence that it is a smart choice for production code. I use a bunch of languages for production code, including Haskell. In my experience, Haskell is the best choice for production code of most kinds. There is likely a selection bias in Haskell. That isn't why Haskell code tends to be good. As an example of a measure of quality: Haskell makes it easy to verify there are no runtime crashes in your program. Even excellent programmers will not be able to make that guarantee in Python, Java or Go. This is a pretty huge thing -- having a guarantee of no runtime crashes. The same Haskellers who can give this guarantee for Haskell code would have no hope of giving this guarantee in these other languages. I'm not talking about a big "try: except:" clause -- but about a compiler exhaustiveness check that verifies all functions are total, and a cursory check that all recursions are well-founded.

by Peaker 13y ago

taliesinb 13y ago

2. Re zero value: If pointers were by default not nullable, then the zero value of a struct containing pointers would have to recursively allocate objects to fill those pointers. That's a deal-breaker for the notion of zero values. 3. Null values are almost always what result, as opposed to undefined or incorrect values. So it's a product type that is effectively a sum type. As for code smells: actually, there is a greppable equivalent in Go, and it is "... , _ := ... ". Future Go compilers might allow for a flag that treats "error" types specially in this regard. Interesting to hear about fromJust, didn't know about it. My own experience is that unchecked errors aren't where Go's 'debugging load' lies. The load is often in reasoning about concurrence, causal dependancies, and state machines. 4. If you're saying that because pattern matching isn't a core feature of Go, you wouldn't use it for everyday code, you're right. I'm a fan of pattern matching, I use it in Mathematica all the time (albiet unchecked). But my point stands: you can build sum types through interfaces, and when that makes a design significantly cleaner, a decent Go programmer will use it. 5. "Type systems don't become cages": well, a lot of people will disagree with you there. Ask C++ programmers about const. Ask Java programmers about checked exceptions. Ask Haskell programmers about logging. So I guess that's just, like, your opinion, man. :) 5.1. Go may not offer you as rich type verification as Haskell, but it does things Haskell can't: it can detect race conditions, for example, in concurrent code [I shudder to think how you even write concurrent code in Haskell]. Another closing thought: you focus a lot on Haskell. Haskell seems to be a very fecund place to devise type-theoretic patterns and techniques. And it seems to have taken the niche of "programming-language research testbed", which also results in a lot of interesting ideas. But there isn't nearly as much evidence that it is a smart choice for production code. I've been impressed by what I've seen, read, and understood about Haskell. Still, I have an unshakable impression that a lot of the quality that is associated with Haskell code is explained better by the hypothesis that the bar for writing Haskell code is very high: bad programmers can't write Haskell programs that do the things they want to do, so we see a lot of nice Haskell code and little bad Haskell code because of the base competency of the audience. But that doesn't imply that an experienced programmer would write higher quality code in Haskell than in Clojure or Go. We all have a complexity budget to spend on using tools to their full potential and doing things a certain 'proper' way. Simple languages leave more of that budget to spend on your program itself. Type-heavy languages leave less, with the promise that the cost is amortized. Calling Go a "sad language" and implying its authors are incompetent because you don't agree with their particular choice of budget demonstrates, to me, a certain arrogance and lack of imagination.

Peaker 13y ago
2. Why does the struct need a zero value? If it does, why not wrap it in an option/Maybe? 3. So that means you might get both a success and error value at the same time? And ignore one of them? As for concurrent problems being worse than nullability, that sounds very plausible -- as Go also messed up concurrency by making any guarantee about immutability of shared state impossible. 4. That means the threshold for using sum types is pretty high -- which means you end up not using them when you ought to (e.g: error products rather than sums). Sum types would make error handling significantly cleaner, but are not used that way in Go. 5. I think C++ programmers rather like const. Maybe you are confused with C programmers? C just got const all wrong. Java got checked exceptions wrong, too. Haskell logging is not a serious problem in my experience. Debug logging is done the same impure way as in other languages. Production logging is easy to add as a feature to your monad stack. Some bad type systems become cages -- and then people hate all type systems. Ironically, Go also has a type system, and since it is a rather poor one, it is a cage as well. 5.1: I'm sorry but this point of yours shows rather extreme ignorance about Haskell. Haskell can statically prevent race conditions. The facilities for writing concurrent code in Haskell are far more advanced than those of Go. > But there isn't nearly as much evidence that it is a smart choice for production code. I use a bunch of languages for production code, including Haskell. In my experience, Haskell is the best choice for production code of most kinds. There is likely a selection bias in Haskell. That isn't why Haskell code tends to be good. As an example of a measure of quality: Haskell makes it easy to verify there are no runtime crashes in your program. Even excellent programmers will not be able to make that guarantee in Python, Java or Go. This is a pretty huge thing -- having a guarantee of no runtime crashes. The same Haskellers who can give this guarantee for Haskell code would have no hope of giving this guarantee in these other languages. I'm not talking about a big "try: except:" clause -- but about a compiler exhaustiveness check that verifies all functions are total, and a cursory check that all recursions are well-founded.