3 ms·

I would say that adding inches and feet is a well-defined operation, you just need to take the different scales into consideration. How much more complicated do

I would say that adding inches and feet is a well-defined operation, you just need to take the different scales into consideration. How much more complicated does the Go code get if you want to allow for addition of inches and feet, but still prevent nonsensical things like adding inches and seconds? How much more complicated does the code get if you then want to allow for the division of length and time to produce velocity? An example: http://www.boost.org/doc/libs/1_54_0/doc/html/boost_units.html http://www.boost.org/doc/libs/1_54_0/doc/html/boost_units.ht...

jerf 13y ago
I don't know, because I don't use them that way. I used units in my example because everybody is used to seeing them but I'm regretting it now, because what I really use it for looks more like this: type FirstName string type LastName string type SomeUniqueIdentifier uint32 type AnIdentifierInAnEntirelySeparateNamespace uint32 Usually I'm using it on types that I want to be fundamentally immiscible, like that, not units. The point is that I use the type system so that FirstName and LastName aren't just "string", and I can't cross up which thing gets passed to which function, ever, because the type system stops me. An error the compiler won't allow me to make at all is an error I can stop worrying about, and I have plenty to worry about. I can fit more useful things to worry about into my mental buffers if I don't have to carry around things the compiler can do not only as well as me, but better.
pcwalton 13y ago
> How much more complicated does the Go code get if you want to allow for addition of inches and feet, but still prevent nonsensical things like adding inches and seconds? You can't do it, because Go doesn't have operator overloading. Also, I'd argue that the automatic promotion of bare numbers to a wrapped type is not really "a matter of taste" but rather severely hurts the ability of Go's newtype feature to catch bugs. In languages that have stricter newtypes, such as ML or Haskell, you can design your APIs such that the caller has to think about which unit to use. Someone using your code might accidentally write the number "12" to mean 12 inches when your API takes feet, but the Go compiler will silently let this mistake pass.
- jerf 13y ago
  "Also, I'd argue that the automatic promotion of bare numbers to a wrapped type is not really "a matter of taste" but rather severely hurts the ability of Go's newtype feature to catch bugs." I agree, but in general, Go is a pragmatic language rather than a pure one. In Haskell it would certainly be the wrong choice. You can pull some fun tricks in Go, such as http://www.jerf.org/iri/post/2923 http://www.jerf.org/iri/post/2923 , but it's not interested in a Haskellian "correctness" in general.
  - pcwalton 13y ago
    I see nothing pragmatic about the automatic wrapping in Go, though. It feels like a pure loss--language complexity, safety, correctness--over not doing it.

jerf 13y ago

I don't know, because I don't use them that way. I used units in my example because everybody is used to seeing them but I'm regretting it now, because what I really use it for looks more like this: type FirstName string type LastName string type SomeUniqueIdentifier uint32 type AnIdentifierInAnEntirelySeparateNamespace uint32 Usually I'm using it on types that I want to be fundamentally immiscible, like that, not units. The point is that I use the type system so that FirstName and LastName aren't just "string", and I can't cross up which thing gets passed to which function, ever, because the type system stops me. An error the compiler won't allow me to make at all is an error I can stop worrying about, and I have plenty to worry about. I can fit more useful things to worry about into my mental buffers if I don't have to carry around things the compiler can do not only as well as me, but better.

pcwalton 13y ago

> How much more complicated does the Go code get if you want to allow for addition of inches and feet, but still prevent nonsensical things like adding inches and seconds? You can't do it, because Go doesn't have operator overloading. Also, I'd argue that the automatic promotion of bare numbers to a wrapped type is not really "a matter of taste" but rather severely hurts the ability of Go's newtype feature to catch bugs. In languages that have stricter newtypes, such as ML or Haskell, you can design your APIs such that the caller has to think about which unit to use. Someone using your code might accidentally write the number "12" to mean 12 inches when your API takes feet, but the Go compiler will silently let this mistake pass.

jerf 13y ago
"Also, I'd argue that the automatic promotion of bare numbers to a wrapped type is not really "a matter of taste" but rather severely hurts the ability of Go's newtype feature to catch bugs." I agree, but in general, Go is a pragmatic language rather than a pure one. In Haskell it would certainly be the wrong choice. You can pull some fun tricks in Go, such as http://www.jerf.org/iri/post/2923 http://www.jerf.org/iri/post/2923 , but it's not interested in a Haskellian "correctness" in general.
- pcwalton 13y ago
  I see nothing pragmatic about the automatic wrapping in Go, though. It feels like a pure loss--language complexity, safety, correctness--over not doing it.