4 ms·

This makes sense, although there are downsides to not naming types, as these serve as documentation. Python documentation has a strong tendency to using descrip

by Yoric 4y ago

This makes sense, although there are downsides to not naming types, as these serve as documentation. Python documentation has a strong tendency to using descriptions to avoid giving names to types, which imho makes the documentation needlessly confusing. Note that I'm writing "types" and not "classes". Interfaces do just as well, if not better! For what it's worth, in the static realm, OCaml introduce features that let code check for presence of a method (instead of implementing an interface) ~25 years ago. Unfortunately, this proved rather unwieldy and, to the best of my knowledge, nobody uses that feature.

vidarh 4y ago
The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise. When there is a meaningful name to give, in Ruby you might define a module, and include it and use that as an interface: module HelloWorld def hello raise "Not implemented" end end class Foo include HelloWorld end Foo.new.hello # Raises an exception Foo.new.kind_of?(HelloWorld) # Returns true (And anytime you want something that behaves somewhat like an ordered collection, you typically just want object.kind_of?(Enumerable)). There are plenty of contract-checking frameworks for Ruby [1] but they see little use, because most of our contracts tend to be extremely simple. Along the line of "implements method X" or "includes module Y". Sorbet w/inference tools and optionally storing the types in a separate files (it supports inline too) might slowly change that (and effectively let you use modules as "proper" interfaces), since the biggest opposition to types in Ruby tends to be visual noise and forcing refactoring, and if it can be turned on/off in your IDE and regenerated, a lot of the objections fall away. It's not that we (well many of us) don't want the extra type checks, but that we don't want to pay the cost of making the code less readable. [1] Here's one: http://egonschiele.github.io/contracts.ruby/ http://egonschiele.github.io/contracts.ruby/ and of course there's Sorbet: https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet
- Yoric 4y ago
  > The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise. Do you have examples? That's not my experience. Of course, we may simply be working on very different types of code :)
  - vidarh 4y ago
    It's hard to give a neat example, because it really changes how you write code and it's been a long time since I had to suffer through much static code. But e.g consider basically almost any case with abstract member functions / methods. While that happens in Ruby (or the equivalent: Leaving a method which raises an exception unless overridden) it's far less common. Typically you'll instead implement defaults in a module if there is lots of functionality that a client might want for itself). These are generally fine to name, and type check by the module name. But when that is not* the case (any class consisting mostly of abstract methods), a Ruby implementation would be more likely to instead expect the presence of a single method and embed the default functionality in the calling class. That's the kind of scenarios where you end up with the kind of long, contrived class names people tend to mock Java for in particular. But going further, a Ruby implementation will instead often take an argument that is expected to support "to_proc" or a block argument, so that you can provide a lambda/closure to do what you'd otherwise put in an "adapter" or "shim" class. Conversely, any time where you demand (whether in a static language by type annotiations or in a dynamic one by checking for the class) an object of a very specific class and only call one or a few methods on it, you're sidestepping this problem by avoiding the creation of a more precise interface that'd clutter up the code. You don't create and name interfaces that encompass the specific operations needed by each method because it'd be a total mess.
    - Yoric 4y ago
      Fair enough. A few common examples for which I rely upon static typing: - I have a proof that operation X is complete, because I have a protocol to follow; - this string is a Matrix room id (and not a Matrix user id or a Matrix server id, also strings); - this time is in milliseconds. Sounds like very different use cases :)

by Yoric 4y ago

vidarh 4y ago

The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise. When there is a meaningful name to give, in Ruby you might define a module, and include it and use that as an interface: module HelloWorld def hello raise "Not implemented" end end class Foo include HelloWorld end Foo.new.hello # Raises an exception Foo.new.kind_of?(HelloWorld) # Returns true (And anytime you want something that behaves somewhat like an ordered collection, you typically just want object.kind_of?(Enumerable)). There are plenty of contract-checking frameworks for Ruby [1] but they see little use, because most of our contracts tend to be extremely simple. Along the line of "implements method X" or "includes module Y". Sorbet w/inference tools and optionally storing the types in a separate files (it supports inline too) might slowly change that (and effectively let you use modules as "proper" interfaces), since the biggest opposition to types in Ruby tends to be visual noise and forcing refactoring, and if it can be turned on/off in your IDE and regenerated, a lot of the objections fall away. It's not that we (well many of us) don't want the extra type checks, but that we don't want to pay the cost of making the code less readable. [1] Here's one: http://egonschiele.github.io/contracts.ruby/ http://egonschiele.github.io/contracts.ruby/ and of course there's Sorbet: https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet https://sorbet.org/blog/2020/07/30/ruby-3-rbs-sorbet

Yoric 4y ago
> The problem to me of naming types is that a lot of the time there is no meaningful name to give, and so it becomes noise. Do you have examples? That's not my experience. Of course, we may simply be working on very different types of code :)
- vidarh 4y ago
  It's hard to give a neat example, because it really changes how you write code and it's been a long time since I had to suffer through much static code. But e.g consider basically almost any case with abstract member functions / methods. While that happens in Ruby (or the equivalent: Leaving a method which raises an exception unless overridden) it's far less common. Typically you'll instead implement defaults in a module if there is lots of functionality that a client might want for itself). These are generally fine to name, and type check by the module name. But when that is not* the case (any class consisting mostly of abstract methods), a Ruby implementation would be more likely to instead expect the presence of a single method and embed the default functionality in the calling class. That's the kind of scenarios where you end up with the kind of long, contrived class names people tend to mock Java for in particular. But going further, a Ruby implementation will instead often take an argument that is expected to support "to_proc" or a block argument, so that you can provide a lambda/closure to do what you'd otherwise put in an "adapter" or "shim" class. Conversely, any time where you demand (whether in a static language by type annotiations or in a dynamic one by checking for the class) an object of a very specific class and only call one or a few methods on it, you're sidestepping this problem by avoiding the creation of a more precise interface that'd clutter up the code. You don't create and name interfaces that encompass the specific operations needed by each method because it'd be a total mess.
  - Yoric 4y ago
    Fair enough. A few common examples for which I rely upon static typing: - I have a proof that operation X is complete, because I have a protocol to follow; - this string is a Matrix room id (and not a Matrix user id or a Matrix server id, also strings); - this time is in milliseconds. Sounds like very different use cases :)