All Quiet on the Western Front: Is Rails overshadowing Ruby?
Trans
the ruby-talk mailing list has become rather "calm" in recent months.
While Ruby-core appears to have a bit of activity, much of it seems a
response to the stillness on talk. And alternate Ruby lists seem to
have fallen largely silent, with one expection: Rails. So I wonder, is
Ruby at risk of becoming little more than a subset techonolgy of Rails?
T.
David A. Black
On Sun, 17 Apr 2005, Trans wrote:
> Perhaps I have a skewed perspective (it happens :-), but it seems as if
> the ruby-talk mailing list has become rather "calm" in recent months.
Please -- don't jinx us, just enjoy it :-)
David
--
David A. Black
dbl...@wobblini.net
Jim Freeze
> Ruby's a nice language, but I think it's particularly well suited for
---------------------------------
> web development. I can't say I see anything wrong with the direction
---------------
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.
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.
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.
The only difference is that Ruby has more value than a large rock. :)
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.
--
Jim Freeze
Code Red. Code Ruby
Pat Maddox
> * Pat Maddox <per...@gmail.com> [2005-04-17 05:21:52 +0900]:
>
> > Ruby's a nice language, but I think it's particularly well suited for
> ---------------------------------
> > web development. I can't say I see anything wrong with the direction
> ---------------
>
> 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.
That was four years ago. Certainly things can change enough in that
time to make Ruby a serious consideration for web development.
> 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.
Languages don't need to make significant changes to gain usefulness.
Language maturity comes with the development of new libraries and
frameworks, and it's these libraries and frameworks that add value to
the language itself, and further the popularity. And as a language
becomes more popular, new libs and frameworks get developed, and it
goes around and around until everyone loves it :)
That's what Rails has done in the area of web development. Ruby
itself isn't well-suited for web development - the fact that there's a
very nice framework for web apps adds that value. We all know that
you can write web apps in any language. There's just no point when
other languages provide effective mechanisms for doing so.
> 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.
My opinion comes from writing web applications for 7 years now, using
C and Perl CGIs, PHP, Java, and ASP. Again, the usefulness of each
language increases with the emergence of development frameworks, and I
find that Rails is by far the simplest and most effective. That is,
however, just my opinion.
> 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.
>
> The only difference is that Ruby has more value than a large rock. :)
>
> 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 have no doubt that more people will come along and add value to
Ruby. It really is a nice language, and I think we'll see that people
will want to incorporate it into other areas of development. As that
happens, new frameworks will be developed, and we'll see it increase
in popularity in areas besides the web.
James Britt
> David and his RubyOnRails is to Ruby what Michaelangelo and
> Michaelangelo's David are to a large of stone.
That is the funniest thing I've read all week.
James
Lothar Scholz
T> Perhaps I have a skewed perspective (it happens :-), but it seems as if
T> the ruby-talk mailing list has become rather "calm" in recent months.
T> While Ruby-core appears to have a bit of activity, much of it seems a
T> response to the stillness on talk. And alternate Ruby lists seem to
T> have fallen largely silent, with one expection: Rails. So I wonder, is
T> Ruby at risk of becoming little more than a subset techonolgy of Rails?
No, we need a good "plone" clone, then we can use this list for
talking about this subset of Rails technology.
--
Best regards, emailto: scholz at scriptolutions dot com
Lothar Scholz http://www.ruby-ide.com
CTO Scriptolutions Ruby, PHP, Python IDE 's
James Britt
> Perhaps I have a skewed perspective (it happens :-), but it seems as if
> the ruby-talk mailing list has become rather "calm" in recent months.
Really? There seems to me to be steady increase in traffic on ruby-talk.
> While Ruby-core appears to have a bit of activity, much of it seems a
> response to the stillness on talk. And alternate Ruby lists seem to
> have fallen largely silent, with one expection: Rails.
Well, there's steady discussion on the Nitro/Og list, but ruby-musings
does seem quite.
> So I wonder, is
> Ruby at risk of becoming little more than a subset techonolgy of
> Rails?
There may be some chance of Ruby "Strutsification", where increasing
numbers of people are familiar with a specific API or tool but have
little understanding of the underlying technology.
That may be good news for people looking for work customizing or fixing
up Rails sites when needs outgrow basic skills. (Or it may be mixed
news: lots of Ruby jobs, but you'll be required to use Rails even when
there are better Ruby options.)
Some of the Rails fanboy behavior may put a few people off Ruby in
general, though I expect that over time the intrinsic value of the
language itself will outshine any particular application.
(I suppose, of course, we'll be having the same discussion when the next
generation of Ruby application framework makes a splash. The more, the
merrier.)
James
Ryan Leavengood
> 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. :)
>
> 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
James Britt
..
> 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. :)
>>
>>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
Francis Hwang
> 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
http://fhwang.net/
Ryan Leavengood
> 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 ;)
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
Adelle Hartley
I feel my perspective is skewed too, as I have only been using a subset of
Rails (ActiveRecord).
I stumbled across Ruby when I was looking for Windows-friendly scripting
languages in which to use the COM-based ORM layer that I was developing.
Then I discovered ActiveRecord which was practically a prototype of what I
was working on. A couple of hours of coding later (spread very thinly
between other work) and I'd written a few extensions to AR that made it into
exactly what I wanted.
Now I'm using Ruby to prototype other parts of my application stack. It's a
brilliant language.
The web isn't the only platform that people write software for.
Adelle.
Joao Pedrosa
> The web isn't the only platform that people write software for.
Agreed!
Ruby rocks soooooooo much. It's a pity that the most used languages
suck in comparison to Ruby. Matz is a genius. Ruby is the most
precious gem of the world.
To me, Ruby is "The Matrix" or "The Matrix" is Ruby... hehehe.
Ruby makes OO work, not the other way around...
A code in Ruby is almost alive. It's like playing "The Sims" with code
in Ruby. :-)
If Ruby is a programming language, I don't know how to call the
others... Maybe almost useless programming languages? :-) Maybe dead
programming languages? :-)
People want to tame this beast called Ruby, but Ruby has been made to
be free... Please, let it be free and live it's own life.
Cheers,
Joao
David A. Black
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
:-)
(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.)
Christian Neukirchen
> 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 <chneuk...@gmail.com> http://chneukirchen.org
David Heinemeier Hansson
>> 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
Navindra Umanee
> 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? :(
No offense, but I would really hate to *have* to use those stupid
looking RubyGem requires to use Ruby libraries...
-N.
Christian Neukirchen
>>> 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,
David A. Black
On Mon, 18 Apr 2005, Christian Neukirchen wrote:
> David Heinemeier Hansson <da...@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.).
gabriele renzi
once it is builtin you would not need those. But AFAIK there are no
plans to include it yet.
Chad Fowler
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).
--
Chad Fowler
http://chadfowler.com
http://rubycentral.org
http://rubygarden.org
http://rubygems.rubyforge.org (over 100,000 gems served!)
Ryan Leavengood
>
> 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
Christian Neukirchen
And how is that a major advantage over linking to them in vendor/ ?
> David A. Black
James Britt
> James Britt <jam...@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
David A. Black
On Mon, 18 Apr 2005, Christian Neukirchen wrote:
> "David A. Black" <dbl...@wobblini.net> writes:
>
>> Hi --
>>
>> On Mon, 18 Apr 2005, Christian Neukirchen wrote:
>>
>>> David Heinemeier Hansson <da...@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.
Jim Weirich
> 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:
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.
--
-- Jim Weirich j...@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)
gabriele renzi
>>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.
Christian Neukirchen
Now, that is really nice of you that you don't force me into anything.
I really mean it. :-)
Saynatkari
Le 17/4/2005, "Chad Fowler" <chadf...@gmail.com> a écrit:
>On 4/17/05, Navindra Umanee <navi...@cs.mcgill.ca> wrote:
>> David Heinemeier Hansson <da...@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? :(
>>
>> 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 :) Maybe #require could
take an additional parameter or simply magick out a version
string from require('mylib-2.03')?
>Chad Fowler
E
--
template<typename duck>
void quack(duck& d) { d.quack(); }
Jim Weirich
> 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.
I agree. I don't know if it is too late to change the name or not.
Chad Fowler
See Jim Weirich's reply to this thread for reasoning not to change
:require's semantics.
Chad Fowler
> On Sunday 17 April 2005 02:29 pm, gabriele renzi wrote:
> > 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.
>
> I agree. I don't know if it is too late to change the name or not.
>
Same here.
Ryan Leavengood
> On 4/17/05, Jim Weirich <j...@weirichhouse.org> wrote:
>
>>On Sunday 17 April 2005 02:29 pm, gabriele renzi wrote:
>>
>>>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.
>>
>>I agree. I don't know if it is too late to change the name or not.
>>
>
>
> Same here.
>
If everyone agrees, why not "deprecate" (a la Java) require_gem and
replace it with a better name. The deprecated version can print out a
warning then call the new version.
On v1.0 or when RubyGems is distributed with Ruby that deprecated method
can be removed (or not...)
Ryan
Trans
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.
On the other hand, what is being accomplished for the end user _is_ the
same. I think it is foolish to have different load code dependemt on
whether a package was installed as a gem or manually. Imagine RPA
having this too. Then we'd have #require_rpa!
I think versioning is great, but maybe RubyGems went a little overboard
in separating itself from tradtional methodologies. For instance, was
it really neccessary to make binaries indirect loads? Why could Gems
have not installed libs to the standard location and just kept track of
what it put there? Versions could have been handled via directory
stucture and symlinks to the latest version. Then it would make sense
to have a #require_version method.
T.
gabriele renzi
completely agreed, we have warnings for this, and a non '1.0' version
means stuff can change slightly ;)
Tobias Luetke
> in separating itself from tradtional methodologies. For instance, was
> it really neccessary to make binaries indirect loads? Why could Gems
> have not installed libs to the standard location and just kept track of
> what it put there? Versions could have been handled via directory
> stucture and symlinks to the latest version. Then it would make sense
> to have a #require_version method.
No. This is just not how versions are used in reality. I'm absolutely
puzzled by the amount of negative press gem receives for this
immensely useful feature!
I use require_gem all over the place to tie applications to versions.
For example one production server is running 6 different rails
applications, 4 of which are tied to specific older releases of gems,
redcloth and others.
Versioned libraries aren't a neat feature, they are absolutely
required for everyone who is serious about ruby. Please don't talk
this feature down because it doesn't look nice in your cron
scripts....
--
Tobi
http://www.snowdevil.ca - Snowboards that don't suck
http://www.hieraki.org - Open source book authoring
http://blog.leetsoft.com - Technical weblog
Trans
Tobias Luetke wrote:
> > I think versioning is great, but maybe RubyGems went a little
overboard
> > in separating itself from tradtional methodologies. For instance,
was
> > it really neccessary to make binaries indirect loads? Why could
Gems
> > have not installed libs to the standard location and just kept
track of
> > what it put there? Versions could have been handled via directory
> > stucture and symlinks to the latest version. Then it would make
sense
> > to have a #require_version method.
>
> No. This is just not how versions are used in reality. I'm absolutely
> puzzled by the amount of negative press gem receives for this
> immensely useful feature!
>
> I use require_gem all over the place to tie applications to versions.
> For example one production server is running 6 different rails
> applications, 4 of which are tied to specific older releases of gems,
> redcloth and others.
>
> Versioned libraries aren't a neat feature, they are absolutely
> required for everyone who is serious about ruby. Please don't talk
> this feature down because it doesn't look nice in your cron
> scripts....
Tobias, you misunderstand me. I am all for versioning. Its the
implementation of it that I think has been problematic. Consider all
your scripts with #require_gem. Would they work in an enviroment where
the support packages were manually installed. No. You'd have to go back
and change them to #require; or have created a rescue clause to deal
with it to begin with; and thus more work to do in order to
redistribute you programs. Rather I think there should be a standard
method #require_version that Ruby supports out-of-the-box, and the libs
should be stored in the typical fashion --with links to the lastest
versions (examples of such excelent packaging systems include RubyX and
Gobo Linux). Implementing in this manner would have, indeed, still can,
thwart the issues with RUBYOPT.
T.
John Knight
app. It is based on rails. But the killer app for ruby is Heretix the follow
on to Rubyx.
itsme213
"Trans" <tran...@gmail.com> wrote in message
> Tobias, you misunderstand me. I am all for versioning. Its the
> implementation of it that I think has been problematic. Consider all
> your scripts with #require_gem. Would they work in an enviroment where
> the support packages were manually installed. No. You'd have to go back
> and change them to #require; or have created a rescue clause to deal
> with it to begin with; and thus more work to do in order to
> redistribute you programs. Rather I think there should be a standard
> method #require_version that Ruby supports out-of-the-box, and the libs
> should be stored in the typical fashion --with links to the lastest
> versions (examples of such excelent packaging systems include RubyX and
> Gobo Linux). Implementing in this manner would have, indeed, still can,
> thwart the issues with RUBYOPT.
This does sound like a very attractive alternative. Standard locations and
directory structure, plus one new directive for versioning.
Tanner Burson
That's a great idea, but relying on OS dependent functionality
(symlinks) would go against ruby's nature at this point. Coming up
with a platform independant way of handling the versions is key, its
easy to think in terms of a specific environment and come up with a
solution, but to have a solution that works on nearly all platforms is
far more complex.
Trans
While there is support in Windows for linking as of NTFS 5 (see
http://shell-shocked.org/article.php?id=284) it is not straighforward,
to say the least. Of course the solution is simply to have the latest
version in the standard place. (The linking is not absolutely
neccessary, but rather a convenience for managing the files.)
T.