ActiveRecord, OpenID, and Everything Not Rails...

[Kit Plummer-3]

Wow.  I started to get a "real" sense for the state of Rails and the  
surrounding Ruby-based frameworks on Friday morning.  You know what  
they say about making promises...

Needless to say I don't have a working geo-client.  I did chase about  
every possible rabbit.  There were some promising options including  
Merb with a generic session captured in DataMapper.  Ironically the  
simplest solution is the Ramaze one.  Way unfortunate that they aren't  
pushing the OpenID capability.  I think if I had the time, I'd debug  
their OpenID-mongrel problem.  But, I still believe we should get the  
geo-client over to Rails for the sake of continuity across our code/
project-base.

The real irony here is that everyone has seemed to go the custom  
OpenID solution based on the  openid-ruby gem.  Not necessarily  
surprised just wondering way the people that put effort into a plugin  
for Rail 1.x/OpenID 1.x are putting the same effort in to maintaining  
them for Rail and OpenID version 2s.  Strange.  This is one of the  
problems that I think the Java world with its more Darwinian approach  
to projects.  But, due to the Rails defacto documentation being blog  
posts the old (weak) stuff seems to live off for ever...and not get  
maintained in the same way as Java-ish projects - it really is self-
centered.  I supposed this is somewhat due to RubyForge, and the  
general lack of a true "foundation" to house Ruby projects ala Apache  
or Eclipse.  I wonder why that is.  No, not really I know why.  It is  
because of shops like 37Signals...not "getting" the greater good part  
of Open Source.  Don't get me wrong I'm not necessarily fault them -  
just saying that they are definitely partly responsible for the state  
of things Ruby and Ruby on Rails.

ActiveRecord is a terd.  I appreciate most of what it brings to the  
table...but, I'm really struggling with it - and any intuitive  
understanding.  I'll take the blame for most of it - not all of it.  
For example, why does this work:

@openid = UserOpenids.find(:first, :conditions => ["user_id = ?",  
@user.id])

And not this:

@openid = UserOpenids.find_by_user_id(:first, @user.id)

It took me at least 4 hours to figure this effer out...and I still  
don't understand.
_______________________________________________
users mailing list
users@...
http://lists.rvooz.org/listinfo.cgi/users-rvooz.org

[Brad Cox-3]

That's the thing I don't like about Rails. Invoke a magic incantation and
magic happens. Wonderful when you get what you want, else you're simply
hosed. And "blogs for documentation" or "generate it from sources" really is
lazy, self-centered and useless, as you said.

On 04/7/08 10:05 AM, "Kit Plummer" <kit@...> wrote:

> Wow.  I started to get a "real" sense for the state of Rails and the
> surrounding Ruby-based frameworks on Friday morning.  You know what
> they say about making promises...
...



This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.  If you have received it in error, please notify the sender immediately and delete the original.  Any other use of the email by you is prohibited.
_______________________________________________
users mailing list
users@...
http://lists.rvooz.org/listinfo.cgi/users-rvooz.org

[Brad Cox-3]

http://glyphobet.net/blog/essay/228

The best tool for the job is Python & Pylons. While Rails and Pylons are
similar, shortcomings in Ruby compared to Python make Python & Pylons the
clear choice. I make three basic arguments against using Ruby:

The language and its implementation are incomplete and immature. Immature
implementations breed performance issues. A project loses time when it must
implement missing or incomplete functionality.
The language is inconsistent and needlessly complex. Inconsistency and
complexity confuses people and confusion breeds bugs.
The documentation is incomplete. Incomplete documentation breeds bugs as you
might misuse a feature. And a project slows down while you read the language
or library source code, or ask the community for help with undocumented
features.
I believe Ruby would fare poorly against other languages, not just Python,
on these angles as well.



On 04/7/08 10:42 AM, "Brad Cox" <brad.cox@...> wrote:

> That's the thing I don't like about Rails. Invoke a magic incantation and
> magic happens. Wonderful when you get what you want, else you're simply
> hosed. And "blogs for documentation" or "generate it from sources" really is
> lazy, self-centered and useless, as you said.
>
> On 04/7/08 10:05 AM, "Kit Plummer" <kit@...> wrote:
>
>> Wow.  I started to get a "real" sense for the state of Rails and the
>> surrounding Ruby-based frameworks on Friday morning.  You know what
>> they say about making promises...
> ...
>
>
>
> This message is for the designated recipient only and may contain privileged,
> proprietary, or otherwise private information.  If you have received it in
> error, please notify the sender immediately and delete the original.  Any
> other use of the email by you is prohibited.
> _______________________________________________
> users mailing list
> users@...
> http://lists.rvooz.org/listinfo.cgi/users-rvooz.org
>

This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information.  If you have received it in error, please notify the sender immediately and delete the original.  Any other use of the email by you is prohibited.
_______________________________________________
users mailing list
users@...
http://lists.rvooz.org/listinfo.cgi/users-rvooz.org

[Kit Plummer-3]

Yeh, I saw that yesterday.  Made me think a bit.  The best counter to  
that post is that the statement needs to get finished.  Not ready for  
what?  I mean I could come out and say that Ruby is not ready for  
realtime autopilot control.  But, I could say that for every language  
except C...which would be stupid.

The other problem with essays like this, that are well thought out and  
documented often miss the real benefits of the "part" they are  
discussing.  Unfortunately, it kind of happens here.

There's no doubt that all of the issues with Ruby do exist, and I  
believe - even though he states they are fixable - the community is so  
weak that it isn't likely.  I really do like Ruby however.  And having  
spent some time writing Python on a previous project I'll take Ruby  
anyday.  I hated Python...talk about debugging nightmares.  Who in  
their right mind would build a language based on whitespace?  Anyway...

Not that Python has one either, but Ruby is suffering from a lack of  
organizational leadership.  Matz, the original developer, is no Linus  
Torvalds.  Indeed it is quite the contrary as his stand is that it is  
still his personal language and that he is just happy other people are  
using it.  If Ruby had the structure that the Linux kernel does we'd  
not be having this discussion right now.

The work in the VM space is where all the real technical stuff is  
happening for Ruby.  I do believe with Sun's help via JRuby that the  
language side will evolve eventually, with many of the points made in  
the Glyphobet post covered.  The reality right now is that people are  
still just "hacking" with Ruby.

Glad you dropped that here Brad.  It showed up in my Google Reader,  
and I shared it - just not sure how far that gets.

Kit

On Apr 8, 2008, at 5:51 AM, Brad Cox wrote:

> http://glyphobet.net/blog/essay/228
>
> The best tool for the job is Python & Pylons. While Rails and Pylons  
> are
> similar, shortcomings in Ruby compared to Python make Python &  
> Pylons the
> clear choice. I make three basic arguments against using Ruby:
>
> The language and its implementation are incomplete and immature.  
> Immature
> implementations breed performance issues. A project loses time when  
> it must
> implement missing or incomplete functionality.
> The language is inconsistent and needlessly complex. Inconsistency and
> complexity confuses people and confusion breeds bugs.
> The documentation is incomplete. Incomplete documentation breeds  
> bugs as you
> might misuse a feature. And a project slows down while you read the  
> language
> or library source code, or ask the community for help with  
> undocumented
> features.
> I believe Ruby would fare poorly against other languages, not just  
> Python,
> on these angles as well.
>
>
>
> On 04/7/08 10:42 AM, "Brad Cox" <brad.cox@...> wrote:
>
>> That's the thing I don't like about Rails. Invoke a magic  
>> incantation and
>> magic happens. Wonderful when you get what you want, else you're  
>> simply
>> hosed. And "blogs for documentation" or "generate it from sources"  
>> really is
>> lazy, self-centered and useless, as you said.
>>
>> On 04/7/08 10:05 AM, "Kit Plummer" <kit@...> wrote:
>>
>>> Wow.  I started to get a "real" sense for the state of Rails and the
>>> surrounding Ruby-based frameworks on Friday morning.  You know what
>>> they say about making promises...
>> ...
>>
>>
>>
>> This message is for the designated recipient only and may contain  
>> privileged,
>> proprietary, or otherwise private information.  If you have  
>> received it in
>> error, please notify the sender immediately and delete the  
>> original.  Any
>> other use of the email by you is prohibited.
>> _______________________________________________
>> users mailing list
>> users@...
>> http://lists.rvooz.org/listinfo.cgi/users-rvooz.org
>>
>
>
>
> This message is for the designated recipient only and may contain  
> privileged, proprietary, or otherwise private information.  If you  
> have received it in error, please notify the sender immediately and  
> delete the original.  Any other use of the email by you is prohibited.
> _______________________________________________
> users mailing list
> users@...
> http://lists.rvooz.org/listinfo.cgi/users-rvooz.org

_______________________________________________
users mailing list
users@...
http://lists.rvooz.org/listinfo.cgi/users-rvooz.org