Rails vs. Ruby Evolution

[dblack]

Hi --

No. I think he means if you are doing Rails, you should have a healthy
dose of Ruby with it.
Not necessarily the other way around.

You mean... you should have Ruby for Rails?


David

--
David A. Black ([email protected])
Ruby Power and Light, LLC (http://www.rubypowerandlight.com)

"Ruby for Rails" chapters now available
from Manning Early Access Program! http://www.manning.com/books/black

 

[Seth Rasmussen]

Hi stu,

In reply to seth;

well your quote


implies that one should know both in order to know Ruby...

No, it doesn't.

It implies that if one is worried about confusing Ruby for Rails or
vice versa, that simply knowing which is which will avoid that.

I have no doubt Rails is a good thing at all, but I dont think Rails
should drive the direction of a generic programming language.

I know not every piece of opinion begs comment, but it seems
interesting that you seem to be responding to things which have not
been stated or implied. This all started by somebody simply saying,
basically, "Hey Rails has a bunch of nice core extensions... maybe
some of them should be in the Ruby core?" That says nothing about
Rails driving anything but its own success and some other people
going, "hey, that's not too shabby."

I want to
see more adoption of Ruby and Rails is driving that, I just dont want
to see Rails dictate what goes into Ruby.

It's going to be okay... it's going to be okay...

How many rails programmers will expect 'to_json' to be standard Ruby
since its bound to Object? (i guess, I am making the gross assumption
that there are more Rails programmers than Ruby programmers, making the
disction between rails only programmers and those that do rails and
ruby)...

I dunno, who cares? Are you like those fools? No? Great. The world spins on=
..

 

[Henrik Martensson]

On Wed, 2006-03-22 at 21:38, stu wrote:

How many rails programmers will expect 'to_json' to be standard Ruby
since its bound to Object? (i guess, I am making the gross assumption
that there are more Rails programmers than Ruby programmers, making the
disction between rails only programmers and those that do rails and
ruby)...

<snip>

There will be a few. These mistakes will be made by the same kind of
people who believe ASP is a programming language, confuse Perl with CGI,
believe that compiled languages are inherently superior to interpreted
languages (or vice versa), and that writing a document in Word is
"programming the computer".

Still, I would not worry too much. The benefits of being able to extend
Ruby code without modifying it, the way the Rails developers do, far
outweighs the drawbacks. What you will see in the future are a few
really strange questions in the mailing lists, but beyond that I believe
you don't have to worry.

When Ruby becomes a blip on the radar of major IT companies, _then_ you
will have cause to worry. Enterprise Ruby Beans...


/Henrik

--
http://kallokain.blogspot.com/ - Blogging from the trenches of software
development
http://www.henrikmartensson.org/ - Reflections on software development
http://tocsim.rubyforge.com/ - Process simulation
http://testunitxml.rubyforge.org/ - XML test framework
http://declan.rubyforge.org/ - Declarative XML processing

 

[gabriele renzi]

Avdi Grimm ha scritto:

It would be nice if the Rails team would
collaborate with the Facets team, since the original intent of Facets,
as I understand it, was to provide a single source for all the handy
extensions people were coming up with.

+1

 

[Kev Jackson]

When Ruby becomes a blip on the radar of major IT companies, _then_ you
will have cause to worry. Enterprise Ruby Beans...

Ack the very thought! Indeed part of the fun I'm having learning ruby
is that the there are many many more informed posts on this list
compared to the average sludge on google groups for anything Java (and
especailly Hibernate) related. I often learn totally new things just by
browsing this lsit - that couldn't be said for java groups/mailing lists...

Compare the number of posts to the rails list that start of with "[Hi
I'm new, what IDE/debugger tool do I use for Rails? | I'm coming from
PHP, I can do this ${thing} in PHP how do I do it in Rails? | Hi I'm
(java|.net|vb|php) programmer, how do I get Rails to talk to my
(Microsoft|IBM|Bea) server?] style posts with the posts here. I know
that partly this is to do with the popularity of Rails as a framework
advertised/marketed to php/java programmers to replace their existing
frameworks, but I also think that this is simply a factor of popularity
- ie the more popular the list the more posts it attracts, regardless of
the value of the post for other people.

That's of course not to suggest that this post has any value.

I think my point is that, right now, ruby is in quite a nice place,
where there are many bright people invloved on the lists and there is
real value lurking and studying the code (Ruby Quiz is one of the finest
examples). In the future this may not be the case, as more 'enterprise
architects' and 'paper MCSE's' start to appear on the list and the truly
insightful posts get drowned out by the ocean of mediocrity. Or
something like that.

So I'm happy that ruby is (currently) a niche language, at least we
don't have people suggesting a 'standards committee' or 'certified
exams' etc (yet)

Kev

 

[Damphyr]

In reply to seth;

well your quote


implies that one should know both in order to know Ruby...

No, it implies that if one uses Rails, he/she should know Ruby.
You are worrying about people who come from Rails having a familiarity
with things not 'of the core'.
Well, I say let them have problems. It doesn't take more than a few
hours to sort through the differences and it's probably the best way to
solidify a good knowledge of Ruby which in turn will make for better
understanding of Rails.

I have no doubt Rails is a good thing at all, but I dont think Rails
should drive the direction of a generic programming language. I want to
see more adoption of Ruby and Rails is driving that, I just dont want
to see Rails dictate what goes into Ruby.

Me neither. Just like a previous post stated (I'm to lazy to quote
properly), Rails is domain specific, Ruby isn't.
I make my living coding Ruby and I have only read about Rails out of
personal interest. The thing is, the guys writing Rails know quite a bit
of Ruby and use the language in a very efficient way.
Ergo, I can learn (and have learned) quite a bit from Rails and the
solutions based on Rails.
Now if some of these solutions transcend the domain of Rails I would be
very happy to see them in core.
Until then, they remain in Rails and it's adjacent libraries, nice
little gems available to everyone. You only have to *know* Ruby to use
them properly.

How many rails programmers will expect 'to_json' to be standard Ruby
since its bound to Object? (i guess, I am making the gross assumption
that there are more Rails programmers than Ruby programmers, making the
disction between rails only programmers and those that do rails and
ruby)...

Well, I expect a "Rails programmer" to very quickly become a "Ruby
programmer", which is what one should be from the start. It isn't all
that difficult (part of the charm of the language) and it really
shouldn't be otherwise.

Cheers,
V.-

--
http://www.braveworld.net/riva

____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.

 

[Austin Ziegler]

T24gMy8yMi8wNiwgQmlsbCBLZWxseSA8YmlsbGtAY3RzLmNvbT4gd3JvdGU6Cj4gSSBsaWtlIHRo
ZSBhcHByb2FjaCB0YWtlbiBieSBOaXRybyAoIGh0dHA6Ly93d3cubml0cm9ocS5jb20vICkKPiB3
aGljaCBzZWVtcyB0byBiZSB3b3JraW5nIGluIGNsb3NlIGNvbGxhYm9yYXRpb24gd2l0aCB0aGUg
ZmFjZXRzCj4gKCBodHRwOi8vZmFjZXRzLnJ1Ynlmb3JnZS5vcmcvICkgbGlicmFyeS4gIEknbSBq
dXN0IGxlYXJuaW5nCj4gTml0cm8sIGJ1dCBmcm9tIHdoYXQgSSd2ZSByZWFkLCB0aGV5IHNlZW0g
dG8gYmUgY29uc2Npb3VzbHkKPiBmYWN0b3JpbmcgdGhlaXIgY29yZSBleHRlbnNpb25zIG91dCB0
byB0aGUgZmFjZXRzIGxpYnJhcnkgd2hlcmUKPiBhcHByb3ByaWF0ZSwgd2hpY2ggbWFrZXMgdGhv
c2UgZXh0ZW5zaW9ucyBhdmFpbGFibGUgZm9yIGFueW9uZQo+IHRvIHVzZSwgb24gYSBtZXRob2Qt
YnktbWV0aG9kIGdyYW51bGFyaXR5LiAgTmVhdC4gIDopCgouLi5JIGp1c3Qgd2lzaCB0aGF0IGZh
Y2V0cyBkaWRuJ3QgdHJ5IHRvIG11Y2sgd2l0aCBzb21lIG9mIHRoZSB0aGluZ3MKdGhhdCBpdCBt
dWNrcyB3aXRoIHVubmVjZXNzYXJpbHkuCgpUaGUgbnVtYmVyIG9uZSByZWFzb24gSSB3aWxsIG5v
dCB1c2UgTml0cm8gaXMgZmFjZXRzLgoKLWF1c3RpbgotLQpBdXN0aW4gWmllZ2xlciAqIGhhbG9z
dGF0dWVAZ21haWwuY29tCiAgICAgICAgICAgICAgICogQWx0ZXJuYXRlOiBhdXN0aW5AaGFsb3N0
YXR1ZS5jYQo=

 

[Justin Bailey]

------=_Part_665_26697361.1143130888902
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Care to elaborate? Not asking for a flame war or anything. I've used Rails
quite a bit and wanted to give Nitro a try on a toy project to see how I
like it, but I've also tried to use Facets before and found it to not be
well-documented, which irritated me. What is it about Facets you are
concerned with?

I would prefer that they didn't. The primary maintainer of Facets has
some odd notions on what should and should not be in Ruby, the language
that I think makes Facets nigh-unusable.

I would prefer to see something that does what Facets does, but does it
smarter and without trying to change the way that Ruby itself works.
This is unlikely to happen under the current maintainer of Facets.

-austin

------=_Part_665_26697361.1143130888902--

 

[James Britt]

Care to elaborate? Not asking for a flame war or anything. I've used Rails
quite a bit and wanted to give Nitro a try on a toy project to see how I
like it, but I've also tried to use Facets before and found it to not be
well-documented, which irritated me.

The lack of documentation is the bane of many projects. There are
efforts underway to improve this in Nitro and related libraries.

I've used Nitro for a number of projects, and not had any issues that
weren't simply from bugs (that have since been fixed) or my own misuse
due to lack of docs.

That a given library makes deep changes to core objects or behavior
should not be an issue if the nature and reasoning for those changes are
made clear.

I expect that when people build, say, a Rails application, that they are
fully aware that the framework adds or munges certain aspects of Ruby,
and that some of the things they are able to (or not) do differs from
general Ruby programming.

As for certain features finding their way into the core language,
general discussion of RCRs may be indicative. It seems that if some
feature is easily added though conventional means (a mixin, for example)
then there is little enthusiasm for bundling it into the language.

For example, the to_json method is quite nice in certain cases, and has
been available via a ruby-json gem for over a year now. There's no
compelling reason to make a part of Ruby itself, though. It's too easy
for developers to just add it when they want to.


--
James Britt

http://www.artima.com/rubycs/ - The Journal By & For Rubyists
http://www.rubystuff.com - The Ruby Store for Ruby Stuff
http://www.30secondrule.com - Building Better Tools

 

[gwtmp01]

That a given library makes deep changes to core objects or behavior
should not be an issue if the nature and reasoning for those
changes are made clear.

Until you need/want to use two such libraries.

Gary Wright

 

[Kashia Buch]

Hi,

Care to elaborate? Not asking for a flame war or anything. I've used =20
Rails
quite a bit and wanted to give Nitro a try on a toy project to see how = I
like it, but I've also tried to use Facets before and found it to not b= e
well-documented, which irritated me. What is it about Facets you are
concerned with?

The part of, "being not well-documented" applies to Nitro as well, sadly.

For Facets screwing around with core functions: Why should I care? If it
doesn't interfer with anything I do, so I really could care less what it
exactly does.

As for Nitro, for me it is the best web framework I ever used, despite
all it's shortcomings.

If you want to learn some stuff, first thing you should look at, are the
small examples by George himself.

Give Nitro a try, if you're not afraid of looking at code from Nitro
itself, otherwise stay away right now
Or use the paths that George flattened himself, they're _very_ smooth ;D

Kashia
--=20
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

 

[James Britt]

Until you need/want to use two such libraries.

Can you give an example?

 

[Hampton]

Kev-

Don't get me started on the Rails usenet group. Its a wasteland.

Every time I browse there I consider it Outreach work.

It makes me shudder to realize that only about 1% of Rails programmers
actually understand programming. That is, I can code in pure Ruby one
hour, then switch over and use the same patterns and style in a website
application. Its absolutely wonderful in that way.

But, alas, 90% of the user base is completely ignorant of actual
effective programming.

It makes me understand why DHH hangs out here in comp.lang.ruby and not
the rails group. It would depress me if my baby was being abused so.

-hampton.

 

[Trans]

The documentation problem is part of it. There have been attribution
problems in the past, but I think that those are mostly fixed, and the
licensing issue is still not 100% clear (the copyright and licence
granted are for the *collection* facets; individual facet
implementations may be under different licences). Mostly, I have issues
with the changes that facets makes -- or has made in the past --
#require and some of the schemes that the primary maintainer has come up
with. They're both ugly and unworkable.

I think that Gavin Sinclair's "extensions" is a much better approach --
group related code, don't separate things into individual files
unnecessarily.

Well, documentation of Facets, I think, is actually fairly good
compared to many projects. Understand that there are over 400 methods
and over 60 modules in there, so it's a lot to keep on top of. The fact
that the vast majority of this work does have documentation --a
explanation and an example or two, I'd say, is pretty good. Some of the
main docs have gotten out of sync with developement but that's b/c the
last fve months or so were a difficult time of working out an cleaner
organization for the two library sections. I've been trying to have a
single lib for both extensions and additions, but it hasn't been easy
and twice I've all but given up and gone back to two separate projects.
But as of yesterday actually, that has been resloved.

As for mucking with the underlying Ruby. You couldn't be more wrong.
Only a dozen or so methods do any mucking about and these are listed
in an "noauto" file so as not to be included in any multi-facet
require. You can use them if you know what you are doing, but you have
to ask for them specifically. And that's really the thing about Facets.
Since it is utilized by selecting the specific methods you want to use
and no more, actual efffects are minimized, which is the benefit of
it's atomicity. This is unlike ActiveSupport where everything is
preloaded.

problems with the changes that facets makes -- or has made in the past --
#require and some of the schemes that the primary maintainer has come up
with. They're both ugly and unworkable.

As for this, you are refering to a one time attemp of mine to use a
special method for loading the methods. Eg. 'String.use Facets,
:blank?' This method has advantages, but it wasn't popular simply
because it's not a common idiom for loading extenal code. I understand
that and so I got rid of it.

T.

 

[gwtmp01]

Can you give an example?

If you are asking for a specific example of a method redefinition
from two
current and popular frameworks that are mutually incompatible, no.

But here is a examples that make me wonder:
Rails redefines Module#const_missing to auto load Rails controllers.

It seems to me that playing around with const_missing by more than one
library would be problematic. I'm not saying that it can't be done but
that all implementations would have to respect some set of conventions.

Rails defines Hash#to_options (a alias for Hash#symbolize_keys). It
just
so happens that in framework I'm working on I defined a method
Array#to_options to help parse a variable argument list. Not a
direct clash
but pretty close.

Rails redefines the backtick method (Kernel#`) to hide the Errno::ENOENT
exception. The comment indicates that only Win32 systems raise the
exception
but the redefinition will catch and suppress that exception.

I'm not trying to say that frameworks should never redefine or extend
core
classes. I was just trying to see if other people were thinking
about this
and what conventions and/or language features might assist in avoiding
mutually incompatible changes/extensions to the core libraries.


Gary Wright

 

[Jim Weirich]

But here is a examples that make me wonder:
Rails redefines Module#const_missing to auto load Rails controllers.

It seems to me that playing around with const_missing by more than one
library would be problematic. I'm not saying that it can't be done but
that all implementations would have to respect some set of conventions.

An actual conflict with const_missing has already occurred. I added a
const_missing handler to Rake when I cleaned up the global namespace and
moved some constants into the Rake namespace. But I wanted people using
constants in the top level namespace to get a deprectated message with
instructions regarding what they had to change to work with the new Rake
command.

I carefully wrote the handler to complain only about the handful of
constants I moved, anything else would be forwarded to the previous
const_missing handler.

Well, that worked great until the new rake was used in a Rails project.
At the time, rails didn't forward chain const_missing requests, so
things got kinda messed up. IIRC, Jamis was one the problem as soon as
I mentioned something (or maybe he told me ... I don't remember), and a
fix was commited almost immediately.

Today, both Rake and Rails use a const_missing handler without
interfering with each other.

The moral of the story is: You need to be careful in creating libraries
that touch the "public" portions of Ruby. I've been meaning to write
down a few guidelines that I tend to follow, but haven't had time yet.
I think the time is ripe for someone to codify a "How to play together
nicely in Ruby" set of guidelines.

 

[gwtmp01]

Well, that worked great until the new rake was used in a Rails
project.

Interesting. When writing my post I grepped through some gems
for 'const_missing' and saw the hit in the Rake gem. I almost included
that as an example but didn't bother to look any deeper.

Gary Wright