Ruby 2.1.0 preview1 released

Not to be an ungrateful d*ck, I think the progress made is fantastic and supported by a bunch of extremely dedicated, talented and courageous people, but there is something of a void in terms of Ruby-as-formally-specified-language, hard to deny. But as usual, I guess it's hard to find the manpower, the time and the money to support such efforts.

We're already starting to see third-party sources bitrotting. E.g. eigenclass' 1.9 pages are now gone. Without an authoritative source for "What's new in 1.9.x?" and later, this bitrot will get worse and make it needlessly painful for folks who still need to move 1.8 code (or brains...) to 1.9/2.0.

Part of my point is that the sources directly linked from ruby-lang.org are a mish-mash as well. There's virtually nothing authoritative, maintained by ruby-lang.org itself. The links at [1] are a mix of ok, good, and rather out of date. ruby-doc.org, not linked from [1] (wat.), is about as good as we've got for a standard reference. Sadly, it's missing the language reference piece and it's auto-generated information architecture sucks hard.

An example of that last point: hit [2]. What's above the fold? A useless list of files. Scroll down and you'll eventually get to the filterable lists of core classes and methods. Click on "Array"[3] and we actually get a nice summary doc with examples that walks us through this class.

For comparison, we'll go to the standard library[4]. Click on "net/http" in the left sidebar[5]. Instead of getting a nice summary page, instead we get an opaque class and method list. The reader is left to divine which, if any, link might provide some clues about the use and organization of this library. (Hint: it's "Net::HTTP", third from the top on the left.) If you already know which is the "main" class for this library, then you can usually guess right.

It's ridiculous for reference material to assume the user is already familiar with it in order to successfully navigate it. Again, other languages' library references do a much better job w.r.t. navigability.

Coda: I don't mean to harsh on ruby-doc.org too much; it's just a central example in the Ruby world. Nevertheless I feel the need to highlight how the Ruby community's disconnected, scattershot approach to documentation presents both a user education and a marketing problem.

[1] https://www.ruby-lang.org/en/documentation/

[2] http://ruby-doc.org/core-2.0.0/

[3] http://ruby-doc.org/core-2.0.0/Array.html

[4] http://ruby-doc.org/stdlib-2.0.0/

[5] http://ruby-doc.org/stdlib-2.0.0/libdoc/net/http/rdoc/index....

Is there a patch?

I work on a large Ruby software project and we've had to move away from any autoload except for very specific cases for this reason- troubleshooting autoload bugs are the WORST.

Maybe this is the reason it hasn't been looked at.

    irb(main):001:0> RUBY_VERSION
    => "2.0.0"
    irb(main):002:0> class Foo; def hello; puts "hello"; end; end
    => nil
    irb(main):003:0> X = Foo.new.method(:hello)
    => #<Method: Foo#hello>
    irb(main):004:0> X.class
    => Method
    irb(main):005:0> class Bar; define_method(:hello, &X); end
    => #<Proc:0x007f93d087a2d8 (lambda)>
    irb(main):006:0> Bar.new.hello
    hello
    => nil

* IO

  * extended methods:

    * IO#seek supports SEEK_DATA and SEEK_HOLE as whence.

    * IO#seek accepts symbols (:CUR, :END, :SET, :DATA, :HOLE) for 2nd argument.

    * IO#read_nonblock accepts optional `exception: false` to return symbols

    * IO#write_nonblock accepts optional `exception: false` to return symbols

private def foo

end

will now work?

1. Rubygems now has a dependency resolution mechanism similar to Bundler.

2. Rubygems has something called StubSpecification which means that complete gemspec of all the gems need not be loaded when using rubygems now. The idea is, we just need dependency from gemspec. Author name, URL etc are irrelevant details which used to get loaded before. So this should make it bit lightweight.