This is an area where so many other languages like Python[1], Go[2], etc. get it right. The only semblance of an online language reference is a version of the Pickaxe book that was already out of date back when Rails was a screaming v1.0 newborn.

[1] Python language ref: http://docs.python.org/3/reference/index.html

[2] Go language ref: http://golang.org/ref/spec

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

http://bugs.ruby-lang.org/issues/2080

E.g. calling with ->(i){ i * (2 + i / 4) } returns 'x * (2 + (x / 4))'

https://gist.github.com/cheald/6674718

https://github.com/pry/pry/wiki/Source-browsing

Or to get the source as a string:

    > require 'pry'
    > Nokogiri.method(:HTML).source
      => "    def HTML thing, url = nil, encoding = nil, options = XML::ParseOptions::DEFAULT_HTML, &block\n      Nokogiri::HTML::Document.parse(thing, url, encoding, options, &block)\n    end\n"

[1] https://github.com/ngty/sourcify

https://bugs.ruby-lang.org/issues/7716

In fact, after 10 years of dedication, b/c of this and a few other issues (and attitudes) I don't use Ruby any more.

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.

I wrote my one load system but have never been able to use it 100% with other projects b/c I could not override autoload require. Though I've begged for years Matz just keeps blowing it off.

Beyond that I've decide it's also time to step up work on my own language. Something I've always wanted to do for a while.

Crystal looks pretty interesting, statically typed Ruby with extreme type inference. Of course that begs the question, why not JRuby?

As for JS/CS, I love me some coffeescript, just a drag to debug the fat fingered typos, indentation mishaps, etc. wtf is going on moments.

A TypeScript/Coffeescript hybrid would be truly awesome.

As for JRuby, fair point, but I'd rather steer clear of Java as much as possible. I have to use Java for Android development and it makes me cry big hippo tears every day.

scala> Random.shuffle(List(1,2,3)) res7: List[Int] = List(2, 3, 1)

Scala-Android google group may be of interest: https://groups.google.com/forum/#!forum/scala-on-android

Obviously I've been converted to the static side, only client-side remains dynamic for me at present, and that's only because there's not yet a statically typed Coffeescript-like language available.

...and as far as its static typed mode introduced in version 2, written by only one person but bundled with the dynamic compiler as if it was part of the same software. is concerned. Grales doesnt use any of it and Gradle still ships with Groovy 1.x.

...and as far as a lot of other stuff about Groovy such as its lexer/parser imlemented in Antlr 2.7, two major releases behind Antlr 4, the latest version. is concerned.

The lack of static typing became an issue when I spent 6 months in the underworld (aka Grails in the v1.3 days) attempting to decipher voluminous stack traces whose origins lay somewhere deep in 10 layers of Grails MOP, far from one's reach.

Anyway, I was frustrated with Grails, deeply so; one day on the Grails user group someone mentioned Scala. Had no idea what that was, checked it out, bought the stairway book, started hacking around in the REPL and was quickly sold.

What is the course of this delay?

Is there a patch?

    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

The 128bit number support is cool, I mean if you want to work with Quadruple-precision floating-point numbers... I know I do.

* 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

IIRC, there were concerns about the performance impact and maybe some other issues of the semantics of refinements -- particularly from maintainers of other Ruby implementations -- which is why there were originally marked "experimental". I believe that those have been addressed with input from the other implementors in 2.1.0.

http://bugs.ruby-lang.org/projects/ruby-trunk/issues?set_fil...

https://github.com/ruby/ruby/blob/v2_1_0_preview1/NEWS

The notable changes are:

* VM (method cache)

* RGenGC

* refinements

* syntax

* Decimal Literal

* Frozen String Literal

* def's return value

* Bignum

* 128bit

* GMP

* String#scrub

* Socket.getifaddrs

* new Rubygem

private def foo

end

will now work?

http://en.wikipedia.org/wiki/Decorator_pattern

I remember reading a while back that Ruby was going to make an effort to separate stdlib components from the language, which I think is pretty exciting.

The more boring side of this would be a newer version of RubyGems.

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.

However, when you get a bundle install conflict error about json, one gem needing a higher version, and one needing a lower version... adding json to _my_ Gemfile/gemspec to fix it when I'm not using json directly is also not the right answer. Sometimes, even that doesn't work at all.