Re: Ruby on Rails?

On 28 Oct 2005, at 12:32, Andreas Korth wrote:

> On 28. Oct 2005, at 11:57 Uhr, Paul Lynch wrote:
>
>> The biggest downside of RoR is the virtual impossibility of  
>> installing Rails on MacOS X.  That makes it way too flakey for  
>> production use.  Yes, I am aware that some people seem to get it  
>> installed eventually (I did once, too).
>
> It's actually no problem to install an run RoR on OS X. Your  
> options range from a fully automatic installer to building it from  
> source.
>
> http://www.rubygarden.org/ruby?RubyOnMacintosh
> http://wiki.rubyonrails.com/rails/pages/HowtoInstallOnOSXTiger

Which I have used and don't work for me (one machine was a pain to  
install, the other it wouldn't install on at all).  When the patching  
and installers work for everyone, that will be a big improvement.   
The first link is for Ruby only, not Rails - Ruby isn't a problem.

> I don't actually see the NeXT/Cocoa background of Ruby. Not  
> everything that's cool must necessarily come from NeXT or Apple.

Then it's about time that you became aware of it.  As for your second  
statement, most things that came from NeXT are very cool.

>> For mid size and small projects, it isn't at all bad.  Rails has a  
>> lot of quite rigid conventions about names (pluralised table  
>> names, id for key, etc), which help a lot if you adopt them, but  
>> annoy if you can't.
>
> These naming conventions are not cast in stone. They support a  
> logical an pragmatic way of developing your app and tremendously  
> reduce the amount of configuration code you need to write. If you  
> like to depart from these conventions, feel free to do so, but be  
> prepared that you'll have to write more configuration code. I  
> wouldn't call that annoying.

I would.  I don't like having field name conventions when adapting to  
legacy databases, which is a necessary part of life.  For small apps,  
it isn't a big deal, except that I really hate plural table names.

>> Rails embeds code in html.  This is evil.
>
> As long as this code is completely view-related (such as formatting  
> a date, for example) it is perfectly well placed in a template. If  
> there's controller or model related code in the template, it's the  
> developer who is evil. Not the framework.

No, it's the framework.  Some things are appropriate to embed, as you  
say.  But having a system that allows you to embed random code in  
views is not good.  The same argument you use is the one that is  
always given by advocates of flawed templating systems (like asp/jsp).

>> Rails has the assumption that you are developing a CRUD app (the  
>> same as the basic WO model), which is only rarely the case for  
>> commercial web apps...
>
> Have you actually seen anything of RoR besides the intro video?  
> Your remarks are completely unfounded and misleading. Just in  
> short: Rails does not assume a CRUD app, it doesn't generate any  
> code if not explicitly asked to and you don't have to ignore any  
> generated code for that matter.

The scaffold templates assume CRUD.  That's what they are there for.   
I pointed out (in the part of my quote that I trimmed) that Rails is  
capable of more than just this.  The scaffold code is good and easy  
to adapt - as such it is kind of a halfway house to the complexity of  
D2.

> If you take the effort to give RoR a little more attention and  
> perhaps build a real application, you might be inclined to change  
> your definition of productivity. I might have to reconsider my  
> definition of conservative if it means to stick with what you know  
> and easily dismiss what you haven't really looked at.

If your only approach to supporting your pet environment is to insult  
people you don't agree with, then I doubt that many people will agree  
with you.  Having GUI apps (WOBuilder and EOModeller) to handle the  
otherwise annoying configuration files is better than not having any.

If you have any constructive comments, feel free to make them - I  
won't bother to respond again if the temperature rises.

Paul