10

What are the things you wish Ruby (and more generally the Ruby community) would improve?

I read somewhere that Ruby is the love-child of Smalltalk and LISP, with Miss Perl as the Nanny.

I have a lot of respect for Ruby's parents, but I'm not sure I like the influence Miss Perl had on the child. Specifically, I don't like the predefined variables: I need a cheat sheet to know what they mean. You could say "just don't use them". Well, I don't... but other people do. And when I download a plugin on the Web, I have no choice but to fetch my cheat-sheet if I ever need to go and touch the source code. I just wish they would remove those from the language itself.

Also, I think that Ruby is too much of a moving target. My code breaks on every new Ruby upgrade, even on minor releases. This is true also of Ruby on Rails and most Rails plugins I have worked with: they just change all the time, and nobody seems to care whether the changes break everything or not. IMHO, although I love a lot of things in Ruby, this lack of stability is almost a show-stopper.

random
  • 9,774
  • 10
  • 66
  • 83
MiniQuark
  • 46,633
  • 36
  • 147
  • 183
  • You can answer your own questions, but if you worry not to be rude, make them in community answers. – Slartibartfast Feb 25 '09 at 10:49
  • Hey, I never noticed that checkbox before! Thanks for the hint. – MiniQuark Feb 25 '09 at 11:13
  • I think it's more a case of Perl & Smalltalk being the direct parents, with Lisp as a friend of the family. – Mike Woodhouse Feb 25 '09 at 12:01
  • Hey, I don't know. I think Ruby's got Lisp's eyes. ;-) One symptom is that I keep defining lambdas all over the place, and I tend to use recursion more than I used to. – MiniQuark Feb 25 '09 at 21:13
  • For the record: Ruby's blocks seem to be more closely related to Smalltalk's blocks than Lisp's lambda functions. – Chuck Mar 01 '10 at 21:44

10 Answers10

7

I wish people would consider backward compatibility between minor releases as an unbreakable rule when releasing a new language (or library or framework) version.

MiniQuark
  • 46,633
  • 36
  • 147
  • 183
  • Do you mean by "minor releases" changes between 1.8.x and 1.8.y? What kind of issues have you encountered? – Andrew Grimm Feb 25 '09 at 11:37
  • Yes, I mean changes between 1.8.x and 1.8.y. Those changes should be 100% painless, and they are not. Changes from 1.x to 1.y may involve some minor refactoring. Changes from 1. to 2. can break everything, that's ok. – MiniQuark Feb 25 '09 at 17:57
  • What kind of issues have you encountered changing between 1.8.x and 1.8.y? – Andrew Grimm Feb 25 '09 at 23:27
  • I don't know if this is what MiniQuark was referring to, but there were major changes between 1.8.6 and 1.8.7. – Andrew Grimm May 10 '10 at 23:42
3

Make require-ing files less painful. Don't ask me how, but maybe have one file dedicated to knowing the paths involved and just get rid of the relative path crud from everything else.

Andrew Grimm
  • 78,473
  • 57
  • 200
  • 338
  • Ruby 1.9 has `require_relative`, which made requiring external files painless most of the time for me, but I do agree that there should be some kind of `project root` or `application path` to work from. – Matheus Moreira Mar 27 '11 at 05:38
3

I wish that some of the lesser used modules of the standard library were documented.

Allyn
  • 20,271
  • 16
  • 57
  • 68
2

Getting rid of the artificial distinction between Modules and Classes would be nice.

Both Modules and Classes are Namespaces. Modules are also Mixins, while Classes aren't. Classes can also be instantiated while Modules can't. This distinction is unnecessary. Just get rid of Modules and allow Classes to be used as Mixins.

An example of a language where this works is Newspeak.

Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653
  • +1 Interesting. I use mixins in Python: they're simply classes. You just use inheritance to "include" them. – MiniQuark Feb 25 '09 at 18:10
  • 3
    Inheritance and mixins are different. – nitecoder Feb 27 '09 at 11:12
  • You can't mix a class into a class, even though `Class < Module`? Surely this violates the liskov substitution principle? – Cameron Martin Apr 16 '14 at 06:50
  • @CameronMartin: `Class` subclasses `Module`, but it is not a *subtype* of `Module`. Class inheritance and subtyping are different things. The LSP applies to subtypes, not subclasses. – Jörg W Mittag Apr 16 '14 at 08:05
  • What's the different between a subclass and a subtype in ruby? The wikipedia article on subtype doesn't shed any light on the matter for me since in ruby, aren't types represented as classes? – Cameron Martin Apr 17 '14 at 12:55
  • The protocol (i.e. the methods an object responds to) of an object is its type (or rather its types, since an object can have more than one type). If an object responds to all methods that another object responds to, plus some more, then that object's type is a subtype of the other object's type. In other words: it's the LSP viewed from the other direction: if an object is Liskov-substitutable for another object, then its type is a subtype of that other object's type. Subclassing simply is for implementation reuse. It's just a vehicle for sharing code. – Jörg W Mittag Apr 17 '14 at 13:00
  • An object's type(s) are however nowhere represented in Ruby. You cannot express an object's type, you cannot query it, you cannot check it. It's a matter of documentation and "type-checking inside the programmer's head". For example, there is a type `Appendable` which has a method `<<` that returns `self` and appends its argument to receiver. `String`s are `Appendable` as are `Array`s, even though they don't share any common superclass except from `Object`, `Kernel` and `BasicObject`. – Jörg W Mittag Apr 17 '14 at 13:06
  • Likewise, the type `StringIO` is a subtype of type `IO`, even though the *class* `StringIO` is not a subclass of class `IO`, just by virtue of the fact that `StringIO` has the same methods and behaves the same way as `IO`. – Jörg W Mittag Apr 17 '14 at 13:06
1

I'd appreciate being able to install ruby 1.9 as an RPM rather than having to use the source.

Andrew Grimm
  • 78,473
  • 57
  • 200
  • 338
  • Your distribution is responsible for providing you with packages. If they don't, a quick search will yield results for Ruby 1.9.1 RPMs. This has nothing to do with Ruby at all. – Nathan de Vries Feb 25 '09 at 14:22
  • @Nathan: I see what you mean. But the fact that it has nothing to do with the language itself doesn't mean that it's an irrelevant complaint about Ruby usage. For example, I could complain that Ruby developers are expensive: I am not complaining about the language itself, but about its environment. – MiniQuark Feb 25 '09 at 18:06
  • BTW, the "rubygems versus debian" war has to end. – MiniQuark Feb 25 '09 at 18:07
  • Really, we should all just use RVM. I completely abandoned Fedora's packages and haven't looked back, not even once. – Matheus Moreira Mar 27 '11 at 05:48
1

Make Ruby completely Message Sending based, get rid of everything that is not a message send: local variables, global variables, instance variables, class hierarchy variables, constants, magic globals, magic constants, builtin operators, builtin keywords, even literals. See Self, Ioke or Newspeak for the incredible power and elegance this gains.

Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653
0

I wish they would get rid of the predefined variables: $!, $&, $+, etc.

MiniQuark
  • 46,633
  • 36
  • 147
  • 183
  • You could always include English.rb (which is part of the standard library) if you don't like the cryptic global variables. http://www.ruby-doc.org/core/files/lib/English_rb.html – Charles Roper Feb 25 '09 at 18:53
  • 1
    Interesting, thanks for the link. But my point is that as long as *anyone* uses those predefined variables, I'll still have to keep my cheat-sheet ready. – MiniQuark Feb 25 '09 at 21:07
0

I would like to have support for static compile-time metaprogramming. The Converge Programming Language might be a good starting point.

Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653
0

Replace the Mixin system with a Traits system.

Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653
-2

Replace Exceptions with a Common Lisp style Conditions system.

Jörg W Mittag
  • 363,080
  • 75
  • 446
  • 653