4 ms·

> Now I say "strong typing is a wonderful test suite you get for free and automatically stays up to date". Not that it replaces tests; but it literally a wonder

> Now I say "strong typing is a wonderful test suite you get for free and automatically stays up to date". Not that it replaces tests; but it literally a wonder how Haskell's HM-typesystem it rejects broken code at compile time. Ruby is strongly typed.

ssmoot 12y ago
That's true. But in practice I've come to the idea it's a meaningless distinction if you're not going to bother to declare the types on your methods/functions. Instances may be Strongly typed in Ruby. Methods are not. So you get almost none of the benefit. It's like Types only exist in Ruby to support Mixins and inheritance chains. Prefer Composition over Inheritance right? But what if through Composition you effectively lost all your Type information? That's the issue Ruby presents.
- YorickPeterse 12y ago
  > Instances may be Strongly typed in Ruby. Methods are not. Sure they are, just not all of them: [].first('wat') # => TypeError: no implicit conversion of String into Integer What Ruby lacks is _static typing_ and compile time checks of these types. Instead we have runtime checks in a few places. > Prefer Composition over Inheritance right? But what if through Composition you > effectively lost all your Type information? That's the issue Ruby presents. This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour. For example: class MyArray < Array end m = MyArray.new([10, 20, 30]) p m.map { |number| number * 2 }.class # => Array Here one would probably expect an instance of MyArray to be returned, but instead we get a vanilla Array.
  - oh_sigh 12y ago
    Why would you expect that if you didn't implement map in MyArray?
  - yxhuvud 12y ago
    > This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour No. It is advocated because it produces simpler code in the long term in most cases. It is a quite different question to inheritance from core classes.
  - saraid216 12y ago
    Using introspection in Ruby is generally against convention. There's no reason to care about the class name if it #responds_to? the method you care about calling.
  - ssmoot 12y ago
    That's not an example of a strongly typed method in Ruby. That's an example of an assertion (most likely implemented in C). Though in hindsight you're right anyways. Methods define an implicit type for the arguments they operate over. It's just you don't know what it is without reading the whole method. Which I think gets to "expressiveness".
dllthomas 12y ago
I agree with the push to get people on the same page with regards to terminology. However, this comment would be far more useful if it suggested an alternate term for the real difference the parent was intending to indicate, or made explicit a claim that the difference was in fact not real.
cies 12y ago
> Ruby is strongly typed. I think one has to bend backward in order to defend that claim; but you probably have some ground somewhere since the term "strongly" is weakly defined :) By strong _I_ meant HM-typesystem strong, or stronger... (for instance I dont think the NullPointerException-king Java is strongly types either -- though it is strictly typed -- again a matter of personal definition)

ssmoot 12y ago

That's true. But in practice I've come to the idea it's a meaningless distinction if you're not going to bother to declare the types on your methods/functions. Instances may be Strongly typed in Ruby. Methods are not. So you get almost none of the benefit. It's like Types only exist in Ruby to support Mixins and inheritance chains. Prefer Composition over Inheritance right? But what if through Composition you effectively lost all your Type information? That's the issue Ruby presents.

YorickPeterse 12y ago
> Instances may be Strongly typed in Ruby. Methods are not. Sure they are, just not all of them: [].first('wat') # => TypeError: no implicit conversion of String into Integer What Ruby lacks is _static typing_ and compile time checks of these types. Instead we have runtime checks in a few places. > Prefer Composition over Inheritance right? But what if through Composition you > effectively lost all your Type information? That's the issue Ruby presents. This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour. For example: class MyArray < Array end m = MyArray.new([10, 20, 30]) p m.map { |number| number * 2 }.class # => Array Here one would probably expect an instance of MyArray to be returned, but instead we get a vanilla Array.
- oh_sigh 12y ago
  Why would you expect that if you didn't implement map in MyArray?
- yxhuvud 12y ago
  > This is mainly advocated because subclassing core classes (e.g. Array) can lead to weird behaviour No. It is advocated because it produces simpler code in the long term in most cases. It is a quite different question to inheritance from core classes.
- saraid216 12y ago
  Using introspection in Ruby is generally against convention. There's no reason to care about the class name if it #responds_to? the method you care about calling.
- ssmoot 12y ago
  That's not an example of a strongly typed method in Ruby. That's an example of an assertion (most likely implemented in C). Though in hindsight you're right anyways. Methods define an implicit type for the arguments they operate over. It's just you don't know what it is without reading the whole method. Which I think gets to "expressiveness".

dllthomas 12y ago

I agree with the push to get people on the same page with regards to terminology. However, this comment would be far more useful if it suggested an alternate term for the real difference the parent was intending to indicate, or made explicit a claim that the difference was in fact not real.

cies 12y ago

> Ruby is strongly typed. I think one has to bend backward in order to defend that claim; but you probably have some ground somewhere since the term "strongly" is weakly defined :) By strong _I_ meant HM-typesystem strong, or stronger... (for instance I dont think the NullPointerException-king Java is strongly types either -- though it is strictly typed -- again a matter of personal definition)