3 ms·

>Ok, it’s only a few characters, big deal. Now what does this do? >b.Mul(b).Sub(big.NewInt(4).Mul(a).Mul(c)) >Or in Haskell >b * b - 4 * a * c umm.. correct

>Ok, it’s only a few characters, big deal. Now what does this do? >b.Mul(b).Sub(big.NewInt(4).Mul(a).Mul(c)) >Or in Haskell >b * b - 4 * a * c umm.. correct me if I'm wrong, since I'm not well versed in either Haskell or Go, but doesnt the Golang version read better in terms of scoping. I mean just by reading the Go version, I know what it will evaluate to, but in the Haskell version I dont know the precedence order just by reading.

Dewie 13y ago
I'm pretty sure that the precedence is the same as in the usual convention of arithmetics. You can ask for it in GHCi (the REPL): > :i (-) > [...] infixl6 > :i ( * ) > [...] infixl7 So ( * ) has precedence over (-). The expression is then: (b * b) - (4 * a * c) Personally, I don't know if infix syntax is truly overall more readable than purely prefix/postfix syntax, or other such uniform representations. It might be for arithmetic, because it is so ingrained, but the precedence order was never hammered into me to such a degree that I learned it automatically by heart; I used to defensively make more parenthesise than I really needed to, just in case.
grayclhn 13y ago
I do, and I don't even know Haskell: (b * b) - (4 * a * c) edit: I don't know go, but I assume the go example is intentionally unreadable. But complaining about infix multiplication and subtraction is... curious.
- jerf 13y ago
  No, that's pretty much what the Go would look like, for any non-standard numeric type. (Though it does need to be a non-standard type, like a "bigint"... a merely type-wrapped standard type ("type Feet uint32") can still have arithmetic done to it.)In fact the default go fmt rules won't even let you put whitespace in there. However, my general call on that is that if you need your language to provide overloaded arithmetic operators, stick to languages that actually want to give that to you. It comes up a lot in language discussions because it's such an easy example to type out in a couple of lines, but in practice I don't think you see a lot of need for exotic int types being used pervasively throughout your code. Don't use Go for that. Don't use any language that doesn't do operator overloading. But this is far less a common use case than seems to be supposed... a variant of the "look under the streetlight" fallacy, I think. Go's really for heterogeneous concurrent business- or server-like programming. It isn't a language for mathematics, and the burst of libraries I've seen in the last couple of weeks that seem to be focused on that is bizarre to me. Go isn't good at that, isn't meant for that, and probably never will be. Go's nice for the very large niche that "business- and server-like programming" is but it's not so fantastically wonderful in every way that I'd want to work too hard to make it work in a niche it's not really suited for.
- khyryk 13y ago
  It really does get that ugly. Check out http://golang.org/pkg/math/big/ http://golang.org/pkg/math/big/.
  - grayclhn 13y ago
    Yikes.
timruffles 13y ago
BIDMAS is worth memorising - http://en.wikipedia.org/wiki/Order_of_operations http://en.wikipedia.org/wiki/Order_of_operations

Dewie 13y ago

I'm pretty sure that the precedence is the same as in the usual convention of arithmetics. You can ask for it in GHCi (the REPL): > :i (-) > [...] infixl6 > :i ( * ) > [...] infixl7 So ( * ) has precedence over (-). The expression is then: (b * b) - (4 * a * c) Personally, I don't know if infix syntax is truly overall more readable than purely prefix/postfix syntax, or other such uniform representations. It might be for arithmetic, because it is so ingrained, but the precedence order was never hammered into me to such a degree that I learned it automatically by heart; I used to defensively make more parenthesise than I really needed to, just in case.

grayclhn 13y ago

I do, and I don't even know Haskell: (b * b) - (4 * a * c) edit: I don't know go, but I assume the go example is intentionally unreadable. But complaining about infix multiplication and subtraction is... curious.

jerf 13y ago
No, that's pretty much what the Go would look like, for any non-standard numeric type. (Though it does need to be a non-standard type, like a "bigint"... a merely type-wrapped standard type ("type Feet uint32") can still have arithmetic done to it.)In fact the default go fmt rules won't even let you put whitespace in there. However, my general call on that is that if you need your language to provide overloaded arithmetic operators, stick to languages that actually want to give that to you. It comes up a lot in language discussions because it's such an easy example to type out in a couple of lines, but in practice I don't think you see a lot of need for exotic int types being used pervasively throughout your code. Don't use Go for that. Don't use any language that doesn't do operator overloading. But this is far less a common use case than seems to be supposed... a variant of the "look under the streetlight" fallacy, I think. Go's really for heterogeneous concurrent business- or server-like programming. It isn't a language for mathematics, and the burst of libraries I've seen in the last couple of weeks that seem to be focused on that is bizarre to me. Go isn't good at that, isn't meant for that, and probably never will be. Go's nice for the very large niche that "business- and server-like programming" is but it's not so fantastically wonderful in every way that I'd want to work too hard to make it work in a niche it's not really suited for.
khyryk 13y ago
It really does get that ugly. Check out http://golang.org/pkg/math/big/ http://golang.org/pkg/math/big/.
- grayclhn 13y ago
  Yikes.

timruffles 13y ago

BIDMAS is worth memorising - http://en.wikipedia.org/wiki/Order_of_operations http://en.wikipedia.org/wiki/Order_of_operations