Hacker News Reader

Comment by YorickPeterse | Hacker News Reader

> 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.

View on HN

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.

> 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.

> 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.

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.

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".

Why would you expect that if you didn't implement map in MyArray?

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.

> 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)

Reply on news.ycombinator.com