3 ms·

>If there is an error, it doesn’t matter what the value is. Who said that? In Go the type system let me return both error and value, and there is no static gua

>If there is an error, it doesn’t matter what the value is. Who said that? In Go the type system let me return both error and value, and there is no static guarantee that value is invalid if error is not nil. >Monads are famously difficult to wrap one’s head around. What's exactly difficult about them? If you do understand this code x := proc1 (arg); y := proc2 (x); return y; what's confusing about this do x <- proc1 (arg) y <- proc2 (x) return y ? Monad is nothing but a pattern (pretty simple in comparison to the majority of GOF patterns, it has only one function for binding two computations of given semantics together) for describing an operational semantics which is just baked in in many imperative languages and could be described by a programmer according to his or her needs with monads (i.e. you don't need to bake don-deterministic, async or parallel computations in a language, you could describe it's semantics with a monad and use it freely). Its closest counterpart is the iterator pattern, which is a generalization of the iteration semantics. It really sounds crazy that it's hard for a programmer to wrap his or her head around operational semantics.

weberc2 8y ago
> there is no static guarantee that value is invalid if error is not nil There doesn’t need to be. An error was returned computing the return value, so it doesn’t make sense to use the value. And if there is something useful to be returned, then you’re dealing with a product type anyway. RE monads, I don’t know why they’re hard to understand, but they are notorious. Probably because they’re more abstract than is helpful in the majority of programs, and they’re often just used to play code golf, removing bits of boilerplate that were never really harmful to begin with (like error handling). I actually like monads and excessive abstraction in general, but that’s because I appreciate a sort of mathematical elegance beyond what is helpful for shipping a product. When I program to feel clever, I use languages like Haskell. When I want to get things done, I use languages like Go. It doesn’t mean Go is better than Haskell or that monads are bad in some absolute sense; only that in general they cost more than they contribute when the objective is shipping a product. Similarly, Go is totally lacking when I want to build something very abstract.
- ernst_klim 8y ago
  >And if there is something useful to be returned, then you’re dealing with a product type anyway. And how do I know if I'm dealing with the product or sum type if the former is absent and emulated by the latter? >I don’t know why they’re hard to understand, but they are notorious. Citation needed. >more abstract than is helpful in the majority of programs They are neither more abstract nor less useful than the iterator pattern. I.e. you don't need either if your programs are trivial or your language has baked in constructs for the semantics they ought to provide, though both are unavoidable when you need to implement iteration or operational semantics in general for the case not foreseen by the language creators. It's a shame that both are neglected in Go, and Go programmers would write these `if (err != nil)` snippets all the way making dozens of errors due to lack of DRY or iterate over a tree using loops. >only that in general they cost more than they contribute when the objective is shipping a product. Citation needed. Need an evidence of clear, generic, literate and domain-driven code being more expensive that a typical Go spaghetti of loops and if (err!=nil). I could believe that its cheaper because of Go developers being cheaper,but the technical debt couldn't be smaller due to verbosity, code repeat and lack of expressiveness to separate the domain logic from the low level programming stuff like iteration and error checking.
  - weberc2 8y ago
    It is just based on experience and common sense (although I’m sure you can come up with some awkward justification for why Haskell has only delivered a fraction of the successful products Go has done despite having been around so much longer and despite being The One True Programming Language). I’m not bothered about whether you believe me or not to be honest. Frankly, I’ve lost interest in the conversation. You seem very defensive and threatened by the success of a programming language, and that’s just the saddest and most disinteresting thing I can think of.
    - ernst_klim 8y ago
      What are you talking about? Go is a niche language [1] just like Haskell, and the amount of successful projects in it could be counted on one hand (aka docker and kubernetes). Popular languages are Python, Java, Javascript, and they all use either monads (java, C#) or exceptions (Java, C#, Python, Js). Also Java, C# as well as the new languages like scala, rust or swift are all influenced by haskell or ML in some way (option/result types, variants), while `if err != nil` is indeed a very obscure and opinionated way of signaling error, which exists in Go and in some very legacy langs only. Java wants to be more like ML than like Go [2] [3]. [1] https://trends.google.com/trends/explore?date=today%205-y&q=Golang,java,javascript,python,php https://trends.google.com/trends/explore?date=today%205-y&q=... [2] https://www.youtube.com/watch?v=HSk5fdKbd3o https://www.youtube.com/watch?v=HSk5fdKbd3o [3] https://www.youtube.com/watch?v=n3_8YcYKScw https://www.youtube.com/watch?v=n3_8YcYKScw

weberc2 8y ago

> there is no static guarantee that value is invalid if error is not nil There doesn’t need to be. An error was returned computing the return value, so it doesn’t make sense to use the value. And if there is something useful to be returned, then you’re dealing with a product type anyway. RE monads, I don’t know why they’re hard to understand, but they are notorious. Probably because they’re more abstract than is helpful in the majority of programs, and they’re often just used to play code golf, removing bits of boilerplate that were never really harmful to begin with (like error handling). I actually like monads and excessive abstraction in general, but that’s because I appreciate a sort of mathematical elegance beyond what is helpful for shipping a product. When I program to feel clever, I use languages like Haskell. When I want to get things done, I use languages like Go. It doesn’t mean Go is better than Haskell or that monads are bad in some absolute sense; only that in general they cost more than they contribute when the objective is shipping a product. Similarly, Go is totally lacking when I want to build something very abstract.

ernst_klim 8y ago
>And if there is something useful to be returned, then you’re dealing with a product type anyway. And how do I know if I'm dealing with the product or sum type if the former is absent and emulated by the latter? >I don’t know why they’re hard to understand, but they are notorious. Citation needed. >more abstract than is helpful in the majority of programs They are neither more abstract nor less useful than the iterator pattern. I.e. you don't need either if your programs are trivial or your language has baked in constructs for the semantics they ought to provide, though both are unavoidable when you need to implement iteration or operational semantics in general for the case not foreseen by the language creators. It's a shame that both are neglected in Go, and Go programmers would write these `if (err != nil)` snippets all the way making dozens of errors due to lack of DRY or iterate over a tree using loops. >only that in general they cost more than they contribute when the objective is shipping a product. Citation needed. Need an evidence of clear, generic, literate and domain-driven code being more expensive that a typical Go spaghetti of loops and if (err!=nil). I could believe that its cheaper because of Go developers being cheaper,but the technical debt couldn't be smaller due to verbosity, code repeat and lack of expressiveness to separate the domain logic from the low level programming stuff like iteration and error checking.
- weberc2 8y ago
  It is just based on experience and common sense (although I’m sure you can come up with some awkward justification for why Haskell has only delivered a fraction of the successful products Go has done despite having been around so much longer and despite being The One True Programming Language). I’m not bothered about whether you believe me or not to be honest. Frankly, I’ve lost interest in the conversation. You seem very defensive and threatened by the success of a programming language, and that’s just the saddest and most disinteresting thing I can think of.
  - ernst_klim 8y ago
    What are you talking about? Go is a niche language [1] just like Haskell, and the amount of successful projects in it could be counted on one hand (aka docker and kubernetes). Popular languages are Python, Java, Javascript, and they all use either monads (java, C#) or exceptions (Java, C#, Python, Js). Also Java, C# as well as the new languages like scala, rust or swift are all influenced by haskell or ML in some way (option/result types, variants), while `if err != nil` is indeed a very obscure and opinionated way of signaling error, which exists in Go and in some very legacy langs only. Java wants to be more like ML than like Go [2] [3]. [1] https://trends.google.com/trends/explore?date=today%205-y&q=Golang,java,javascript,python,php https://trends.google.com/trends/explore?date=today%205-y&q=... [2] https://www.youtube.com/watch?v=HSk5fdKbd3o https://www.youtube.com/watch?v=HSk5fdKbd3o [3] https://www.youtube.com/watch?v=n3_8YcYKScw https://www.youtube.com/watch?v=n3_8YcYKScw