All Quiet on the Western Front: Is Rails overshadowing Ruby?

ruby-talk
1

Jim Freeze <jim freeze.org> wrote:

I've seen others make this same comment. I find it interesting
that at RubyConf 2001 (the first Ruby conference) I heard multiple
times that Ruby was not ready for web development.

Yep, I remember that. It is pretty amazing that a web framework could all of a
sudden make Ruby so much more marketable. The irony about myself is that it
took hearing about Rails from a coworker (and we don't even do web development
professionally) to bring me back into the Ruby fray. Not that I'd abandoned
what is still my favorite language, I just found it hard to keep up when I have
to do Java at work.

I know rails is new, but I'm not sure that the language has made
any significant changes to justify such an about face in opinion.

I think I'd have a pretty good perspective on that since I was around in the
RubyConf 2001 days and have been pretty much out of the Ruby community until
now. I agree, not too much has changed in the language (though I love
Enumerable#inject.) Even the list of libraries isn't that different. Though I'm
certainly aware of the additions that made RubyGems Part Deux easier to
implement than when I made the first RubyGems (of course I never really got
past prototype stage.)

However, I think it is a lesson in how people can take
their own opinion (or a common opinion) and believe in it as fact.

Rails has opened the eyes of to many to what they could not see.
David and his RubyOnRails is to Ruby what Michaelangelo and
Michaelangelo's David are to a large of stone.

While the metaphor is colorful and amusing, I don't think I'd even go so far as
to say that. David is no doubt a smart guy and Rails is a cool system (from
what I've seen, I'm still a Rails newbie), but I think the success of Rails has
more to do with its simplicity and utility than any inherent "artistry."

David had a problem (implementing BaseCamp using Ruby), and he just solved his
own problem by creating Rails. I think too many people create solutions that
are looking for a problem instead of solving real problems.

The only difference is that Ruby has more value than a large rock. :slight_smile:

It is also clear that some people just see the statue.
But me, I see the process. I am waiting to see what gets
created when another Michaelangelo comes along and finds Ruby.

I think Rails is just the tip of the iceberg. There are too many brilliant
people involved with Ruby for it not to have a bright future. The problem maybe
that too many of those people are "too close" to the language to create the
next Rails, so I agree we may need new blood to move forward. Or more of the
old hats need to learn how to step back and see Ruby from a fresh light.

Ryan Leavengood

···

__________________________________
Do you Yahoo!?
Plan great trips with Yahoo! Travel: Now over 17,000 guides!
http://travel.yahoo.com/p-travelguide

2

Ryan Leavengood wrote:
...

I think I'd have a pretty good perspective on that since I was around in the
RubyConf 2001 days and have been pretty much out of the Ruby community until
now. I agree, not too much has changed in the language (though I love
Enumerable#inject.) Even the list of libraries isn't that different. Though I'm
certainly aware of the additions that made RubyGems Part Deux easier to
implement than when I made the first RubyGems (of course I never really got
past prototype stage.)

Rubygems has made a big difference for me. Whereas trying a new lib or application was often a series of downloads, dependency searches, and installation headaches, most libraries nowadays are a snap to install and explore. Would Rails , for example, have been as successful if people had to manually install the half-dozen or so required libraries?

Half the battle is getting people to at least try things.

Without rubygems, many a fine application would go underused.

However, I think it is a lesson in how people can take
their own opinion (or a common opinion) and believe in it as fact.

Rails has opened the eyes of to many to what they could not see. David and his RubyOnRails is to Ruby what Michaelangelo and Michaelangelo's David are to a large of stone.

While the metaphor is colorful and amusing, I don't think I'd even go so far as
to say that. David is no doubt a smart guy and Rails is a cool system (from
what I've seen, I'm still a Rails newbie), but I think the success of Rails has
more to do with its simplicity and utility than any inherent "artistry."

Rails offers a good solution for a set of common problems, with excellent packaging and promotion. The assorted code generators and default settings lower the barrier to use, and you can get started without having to think about too many things.

David had a problem (implementing BaseCamp using Ruby), and he just solved his
own problem by creating Rails. I think too many people create solutions that
are looking for a problem instead of solving real problems.

The only difference is that Ruby has more value than a large rock. :slight_smile:

It is also clear that some people just see the statue.
But me, I see the process. I am waiting to see what gets
created when another Michaelangelo comes along and finds Ruby.

Aside from Matz, Ruby has yet to have its Michaelangelo. Maybe some Warhols and Duchamps, though.

James

3

Hi --

···

On Sun, 17 Apr 2005, Ryan Leavengood wrote:

Jim Freeze <jim freeze.org> wrote:

I've seen others make this same comment. I find it interesting
that at RubyConf 2001 (the first Ruby conference) I heard multiple
times that Ruby was not ready for web development.

Yep, I remember that. It is pretty amazing that a web framework could all of a
sudden make Ruby so much more marketable. The irony about myself is that it
took hearing about Rails from a coworker (and we don't even do web development
professionally) to bring me back into the Ruby fray. Not that I'd abandoned
what is still my favorite language, I just found it hard to keep up when I have
to do Java at work.

Welcome back! Glad to see you, and hope to see you at RubyConf 2005
:slight_smile:

(For those who don't know, Ryan is the originator of RubyGems. Its
first incarnation, and its name, came entirely from Ryan, and were
presented at the first RubyConf in Tampa in 2001.)

David

--
David A. Black
dblack@wobblini.net

4

Aside from Matz, Ruby has yet to have its Michaelangelo. Maybe some Warhols and Duchamps, though.

Arg. Please, everybody: It's "Michelangelo".

_why_ might be the closest we've got to a Duchamp, though he's probably not ironic enough. But let's not conjecture as to who might be the "Andy Warhol of Ruby": That might get nasty.

Francis Hwang

5

James Britt wrote:

Rubygems has made a big difference for me. Whereas trying a new lib or application was often a series of downloads, dependency searches, and installation headaches, most libraries nowadays are a snap to install and explore. Would Rails , for example, have been as successful if people had to manually install the half-dozen or so required libraries?

Half the battle is getting people to at least try things.

Without rubygems, many a fine application would go underused.

I definitely agree, as that is why I came up with the original idea for RubyGems. Not that is was all that original, just a combination of a few different things. The main point I was making was that the resurrection of RubyGems after I stopped working on the original was helped along by some useful new libraries, though nothing really extraordinary was needed. Mostly I stopped because I just got overwhelmed and lazy and moved on :wink:

Also as useful as it is, RubyGems is really a facilitator and not necessarily a piece of software that will draw people into using Ruby. Originally I thought it would be a draw, but in reality I'm not so sure (I'm a few years older and wiser.) But as you say it certainly does help people to use things like Rails that are more of a draw.

Aside from Matz, Ruby has yet to have its Michaelangelo. Maybe some Warhols and Duchamps, though.

I don't know, there are some people who can write some pretty fine pieces of code. I'm just not sure how you can just the artistry of any piece of code. Maybe it is just one of those QWAN (Quality Without A Name) type things. Rubyists (or even people in general) just KNOW when something is good.

Ryan Leavengood

6

James Britt <james_b@neurogami.com> writes:

Rubygems has made a big difference for me. Whereas trying a new lib
or application was often a series of downloads, dependency searches,
and installation headaches, most libraries nowadays are a snap to
install and explore. Would Rails , for example, have been as
successful if people had to manually install the half-dozen or so
required libraries?

Eh, there is one tar.gz that contains all of Rails libraries, where's
the problem with that?

···

James

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

7

Would Rails , for example, have been as successful if people had to manually install the half-dozen or so required libraries?

Eh, there is one tar.gz that contains all of Rails libraries, where's
the problem with that?

Further more, Rails didn't support RubyGems until a couple of releases in.

Where RubyGems has made a big difference, I think, is for upgrading and trying out new versions of libraries you already have. So basically, it's the library versioning that, to me, is one of the biggest draws of RubyGems.

It's funny, though. I remember some early discussion on RubyGems where someone pointed out that while library versioning was nice in theory, but who would _really_ want to have multiple versions of the same library installed? Hehe.

Killer features often only reveal themselves after people try it out on real problems.

So while I don't think its significantly easier to first install RubyGems, then gem Rails over just installing Rails from files, I think RubyGems makes it much more enjoyable to follow the development of a library or framework.

Of course, when RubyGems is included in 1.8.3 (hopefully or, pain, pain, 1.8.4), I think that's when RubyGems will make its mark for increasing the first-time visit of libraries on newbies coming to Ruby.

And thanks for all the kind words about Rails. Ruby is ripe to make a similar splash in other areas than web applications. Can't wait to see the next triumph push Ruby even further.

···

--
David Heinemeier Hansson,
http://www.basecamphq.com/ -- Web-based Project Management
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.loudthinking.com/ -- Broadcasting Brain

8

Christian Neukirchen wrote:

James Britt <james_b@neurogami.com> writes:

Rubygems has made a big difference for me. Whereas trying a new lib
or application was often a series of downloads, dependency searches,
and installation headaches, most libraries nowadays are a snap to
install and explore. Would Rails , for example, have been as
successful if people had to manually install the half-dozen or so
required libraries?

Eh, there is one tar.gz that contains all of Rails libraries, where's
the problem with that?

Still too much typing of 'ruby install.rb'

I picked Rails as an example because it was the first that came to mind when recalling an installation that had 4+ dependencies.

When doing a survey of Ruby XML libs a few years ago, I encountered too many episodes of "Install: CSI" , and would often have to first go get lib 'foo' (not included), which in turn insisted I get lib 'bar', and so on down the food chain.

With gems, when everyone is playing along, I can write an app that depends on rubyzip and builder and og and orbjson, and rubygems handles the tedious hunt and fetch cycle.

Overall, it should encourage people to write small apps, simple but focused and useful, that lend themselves to being hooked together in interesting ways, so people can wire up tools for the various tasks they need done.

James

9

Oh no, RubyGems is going to be included by default in Ruby? :frowning:

No offense, but I would really hate to *have* to use those stupid
looking RubyGem requires to use Ruby libraries...

-N.

···

David Heinemeier Hansson <david@loudthinking.com> wrote:

Of course, when RubyGems is included in 1.8.3 (hopefully or, pain,
pain, 1.8.4), I think that's when RubyGems will make its mark for
increasing the first-time visit of libraries on newbies coming to Ruby.

10

David Heinemeier Hansson <david@loudthinking.com> writes:

Would Rails , for example, have been as successful if people had to
manually install the half-dozen or so required libraries?

Eh, there is one tar.gz that contains all of Rails libraries, where's
the problem with that?

Further more, Rails didn't support RubyGems until a couple of releases
in.

Where RubyGems has made a big difference, I think, is for upgrading
and trying out new versions of libraries you already have. So
basically, it's the library versioning that, to me, is one of the
biggest draws of RubyGems.

Now, I didn't get too deep into Rails, but how would one practically
do that: Have several Rails projects, which all use different
versions of AR, AC etc...?

···

And thanks for all the kind words about Rails. Ruby is ripe to make a
similar splash in other areas than web applications. Can't wait to see
the next triumph push Ruby even further.

David Heinemeier Hansson,

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

11

Hi --

···

On Mon, 18 Apr 2005, Christian Neukirchen wrote:

David Heinemeier Hansson <david@loudthinking.com> writes:

Would Rails , for example, have been as successful if people had to
manually install the half-dozen or so required libraries?

Eh, there is one tar.gz that contains all of Rails libraries, where's
the problem with that?

Further more, Rails didn't support RubyGems until a couple of releases
in.

Where RubyGems has made a big difference, I think, is for upgrading
and trying out new versions of libraries you already have. So
basically, it's the library versioning that, to me, is one of the
biggest draws of RubyGems.

Now, I didn't get too deep into Rails, but how would one practically
do that: Have several Rails projects, which all use different
versions of AR, AC etc...?

Yes. You can specify version numbers in your configuration for each
app, which is nice because it means you don't have to upgrade all your
Rails apps as soon as a new version of Rails comes out. I've done
this quite a lot (with the Ruby FAQ, RCRchive, etc.).

David

--
David A. Black
dblack@wobblini.net

12

You miss the point: if RubyGems were included in Ruby's default
distribution, it would be integrated, and you'd never have to use
require_gem again (though, you could still use require_gem to load a
specific version of a library).

···

On 4/17/05, Navindra Umanee <navindra@cs.mcgill.ca> wrote:

David Heinemeier Hansson <david@loudthinking.com> wrote:
> Of course, when RubyGems is included in 1.8.3 (hopefully or, pain,
> pain, 1.8.4), I think that's when RubyGems will make its mark for
> increasing the first-time visit of libraries on newbies coming to Ruby.

Oh no, RubyGems is going to be included by default in Ruby? :frowning:

No offense, but I would really hate to *have* to use those stupid
looking RubyGem requires to use Ruby libraries...

--

Chad Fowler
http://chadfowler.com

http://rubygems.rubyforge.org (over 100,000 gems served!)

13

Navindra Umanee ha scritto:

···

David Heinemeier Hansson <david@loudthinking.com> wrote:

Of course, when RubyGems is included in 1.8.3 (hopefully or, pain, pain, 1.8.4), I think that's when RubyGems will make its mark for increasing the first-time visit of libraries on newbies coming to Ruby.

Oh no, RubyGems is going to be included by default in Ruby? :frowning:

No offense, but I would really hate to *have* to use those stupid
looking RubyGem requires to use Ruby libraries...

once it is builtin you would not need those. But AFAIK there are no plans to include it yet.

14

Chad Fowler wrote:

You miss the point: if RubyGems were included in Ruby's default
distribution, it would be integrated, and you'd never have to use
require_gem again (though, you could still use require_gem to load a
specific version of a library).

I kind of wondered why you added require_gem instead of just overriding require like I originally did, but I see that until RubyGems is in the default distribution, it is the friendly thing to do.

Also once you get to that point you still wouldn't need require_gem, even for the version specification:

alias :__old_require__ :require
def require(name, version = nil)
    if version
       puts "Would call new version of require!"
    else
       puts "Calling old version of require!"
       __old_require__(name)
    end
end

require 'singleton'
require 'foo', '0.5.6'

Ryan Leavengood

15

"David A. Black" <dblack@wobblini.net> writes:

Hi --

David Heinemeier Hansson <david@loudthinking.com> writes:

Where RubyGems has made a big difference, I think, is for upgrading
and trying out new versions of libraries you already have. So
basically, it's the library versioning that, to me, is one of the
biggest draws of RubyGems.

Now, I didn't get too deep into Rails, but how would one practically
do that: Have several Rails projects, which all use different
versions of AR, AC etc...?

Yes. You can specify version numbers in your configuration for each
app, which is nice because it means you don't have to upgrade all your
Rails apps as soon as a new version of Rails comes out. I've done
this quite a lot (with the Ruby FAQ, RCRchive, etc.).

And how is that a major advantage over linking to them in vendor/ ?

···

On Mon, 18 Apr 2005, Christian Neukirchen wrote:

David A. Black

--
Christian Neukirchen <chneukirchen@gmail.com> http://chneukirchen.org

16

> Of course, when RubyGems is included in 1.8.3 (hopefully or, pain,
> pain, 1.8.4), I think that's when RubyGems will make its mark for
> increasing the first-time visit of libraries on newbies coming to Ruby.

Oh no, RubyGems is going to be included by default in Ruby? :frowning:

No offense, but I would really hate to *have* to use those stupid
looking RubyGem requires to use Ruby libraries...

You miss the point: if RubyGems were included in Ruby's default
distribution, it would be integrated, and you'd never have to use
require_gem again (though, you could still use require_gem to load a
specific version of a library).

Does not sound that well-integrated :slight_smile: Maybe #require could
take an additional parameter or simply magick out a version
string from require('mylib-2.03')?

Chad Fowler

E

···

Le 17/4/2005, "Chad Fowler" <chadfowler@gmail.com> a écrit:

On 4/17/05, Navindra Umanee <navindra@cs.mcgill.ca> wrote:

David Heinemeier Hansson <david@loudthinking.com> wrote:

--
template<typename duck>
void quack(duck& d) { d.quack(); }

17

Hi --

···

On Mon, 18 Apr 2005, Christian Neukirchen wrote:

"David A. Black" <dblack@wobblini.net> writes:

Hi --

On Mon, 18 Apr 2005, Christian Neukirchen wrote:

David Heinemeier Hansson <david@loudthinking.com> writes:

Where RubyGems has made a big difference, I think, is for upgrading
and trying out new versions of libraries you already have. So
basically, it's the library versioning that, to me, is one of the
biggest draws of RubyGems.

Now, I didn't get too deep into Rails, but how would one practically
do that: Have several Rails projects, which all use different
versions of AR, AC etc...?

Yes. You can specify version numbers in your configuration for each
app, which is nice because it means you don't have to upgrade all your
Rails apps as soon as a new version of Rails comes out. I've done
this quite a lot (with the Ruby FAQ, RCRchive, etc.).

And how is that a major advantage over linking to them in vendor/ ?

I'm not claiming that it is. You can do whatever works for you and
you're comfortable with.

David

--
David A. Black
dblack@wobblini.net

18

Actually, there is an important difference between require_gem and require. A
require statement is a request to load a particular file into the ruby image.
A require_gem statement activates (enables, selects) a versioned package.
The key point is that a package name is not the same as a file name.
Although there is some overlap, there are many cases where this is not true.

I think Rails is doing the smart thing w.r.t. package management. All the
require_gems are located in the environment section of the application. When
a rails app wants to explicitly switch to a different library version, there
is only one place to go to make that change. If we allowed version specs on
each and every require statement throughout the application, changing
versions would be painfull indeed.

I think the separation of versioning statements from require statements is a
good thing to maintain ... even in an integrated system.

BTW, if you don't want to use require_gem statements, you don't have to.
RubyGems will, by default, use the latest loaded version of a gem library.
What you *do* need to do is make sure RubyGems is loaded in order to take
advantage of any installed gems. That's the pain that would go away with an
integrated rubygems library.

···

On Sunday 17 April 2005 11:58 am, Ryan Leavengood wrote:

Chad Fowler wrote:
> You miss the point: if RubyGems were included in Ruby's default
> distribution, it would be integrated, and you'd never have to use
> require_gem again (though, you could still use require_gem to load a
> specific version of a library).

I kind of wondered why you added require_gem instead of just overriding
require like I originally did, but I see that until RubyGems is in the
default distribution, it is the friendly thing to do.

Also once you get to that point you still wouldn't need require_gem,
even for the version specification:

--
-- Jim Weirich jim@weirichhouse.org http://onestepback.org
-----------------------------------------------------------------
"Beware of bugs in the above code; I have only proved it correct,
not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)

19

See Jim Weirich's reply to this thread for reasoning not to change
:require's semantics.

···

On 4/17/05, Saynatkari <ruby-ml@magical-cat.org> wrote:

Le 17/4/2005, "Chad Fowler" <chadfowler@gmail.com> a écrit:
>On 4/17/05, Navindra Umanee <navindra@cs.mcgill.ca> wrote:
>> David Heinemeier Hansson <david@loudthinking.com> wrote:
>> > Of course, when RubyGems is included in 1.8.3 (hopefully or, pain,
>> > pain, 1.8.4), I think that's when RubyGems will make its mark for
>> > increasing the first-time visit of libraries on newbies coming to Ruby.
>>
>> Oh no, RubyGems is going to be included by default in Ruby? :frowning:
>>
>> No offense, but I would really hate to *have* to use those stupid
>> looking RubyGem requires to use Ruby libraries...
>>
>
>You miss the point: if RubyGems were included in Ruby's default
>distribution, it would be integrated, and you'd never have to use
>require_gem again (though, you could still use require_gem to load a
>specific version of a library).

Does not sound that well-integrated :slight_smile: Maybe #require could
take an additional parameter or simply magick out a version
string from require('mylib-2.03')?

--

Chad Fowler
http://chadfowler.com

http://rubygems.rubyforge.org (over 100,000 gems served!)

20

Jim Weirich ha scritto:

I kind of wondered why you added require_gem instead of just overriding
require like I originally did, but I see that until RubyGems is in the
default distribution, it is the friendly thing to do.

Also once you get to that point you still wouldn't need require_gem,
even for the version specification:

Actually, there is an important difference between require_gem and require. A require statement is a request to load a particular file into the ruby image. A require_gem statement activates (enables, selects) a versioned package.

I think I already said this once long time ago, but I forgot the answer.. why name this method "require_gem" ? It is not the first time people get confused about it, and I think something like "use_gem" or "Gem.load" would be much better, showing that it does not really act like "require" but more like a configuration step.