1. 14
  1.  

  2. 4

    As a Ruby community and as the Ruby language, we try to satisfy both needs at the simultaneously: we’re going to have the type information file separate from the Ruby program — the Ruby program itself doesn’t contain any static type information. Instead, a separate type information file, we call it “Ruby signature file”, contains the type information about the library, Gems and your programs.

    We’re going to provide a tool, called the “type profiler”, which can collect the type information about your software. After collecting the type information for the library and your software, the type profiler has all the information it needs about all of the classes and methods, so it can then detect type contradictions — type conflicts. You can even refine the type information in your signature file by hand to afford better type checking.

    I’m interested to see how that works out.

    1. 4

      Works pretty well in OCaml!

    2. 3

      Meanwhile, are there things in Ruby’s design or evolution that you dislike? What would you call the biggest design failure that should be fixed, or is already fixed?

      Yukihiro: I have some. Global variables: they were useful for a “scripting language”, but now they are more like an appendix. I also regret adding threads to the language, we should have had a better concurrency abstraction. My other design mistake is some objects that are needlessly mutable. For example, there is a possibility to change a time zone for the existing time object, instead of creating a new one. I regret that.

      I remember the day I ripped out all threads from my ruby code…..

      Made it a lot better.

      Then I got into the habit of putting “freeze” at the end of my constructors and only removing it if I could convince myself my code would be better. Spoiler alert: I hardly ever remove it.

      I’m hopeful that Samuel William’s initiatives may improve things… https://www.codeotaku.com/journal/2019-12/ruby-concurrency-progress-report/index