RoR, Judge Judy, and little old ladies

[Robby]

> So... First, I've got to ask:
> 
> - What application domain is RoR really supposed to be superior for?
> - Has it proved itself to be superior in 'real-world' large-scale 
> development of new software (against new as opposed to well established 
> databases)?
Both of these questions come across as "is this thing enterprise" (plus 
whatever press release idiom). All I can say is glance over the RoR site 
and look at the sites running it, there's some small, some big, a lot of 
  in the middle.
> - Are RoR code generation facilities often left behind as the app. dev. 
> process proceeds from prototype to final product?
There's a concept in RoR called scaffolding, where the views are 
generated at runtime, but this is for rapid prototyping. But it depends 
on what you're talking about, the runtime active record generation is 
there through the entire cycle, and obviously the rest you're going to 
change as you develop
> - How does RoR differ from the aforementioned Code Generators?
because it's the whole package, it's not just a database layer.
> - Are there any well defined studies suggesting that RoR developed apps. 
> are cheaper than, say, apps. developed with PHP, using a traditional 
> development approach?
More enterprise speak?
> - Is RoR here to stay?
I'd say the adoption and the momentum is going to keep it in swing for 
quite a while, how long? no clue.. I mean, back in the day Struts was 
the thing (bleh), and it's slowly becoming defunct. Can you be 
productive in RoR, sure, can you improve it? Sure, it's all about 
tastes.. but if you want something in the terms of an independent report 
on how great it is, I can't help. I've used it, it's worked for me on a 
quite large intranet application, but nothing is the be all end all.

> 
> Then I've got to ask: How could D possibly improve on RoR enough to get 
> people to move away from RoR to DeRailed?
> 
It shouldn't be able moving people from, to d's implementation, it's 
about providing a strong stack of development tools to allow people who 
want to code in d on the client, on the server and indirectly, for the web.
> In the context of language design, Ruby may have garnered a reputation 
> from RoR, but by the time a comparable D lib. is developed, how likely 
> is it that RoR will still be a "hot" technology?
> 
I'd stay it will grow as long as its members continue to take the 
complexity out of a development stack for the web and simplify it.
> (*) The code generators I'm speaking of generate the read/write stored 
> procs. from DB metadata (the 'catalog' or INFORMATION_SCHEMA), and then 
> generate the .NET wrapper classes/containers for those. Some of them go 
> so far as to incorporate change control tools to compare the current 
> version with a new version generated after a schema change, etc. to 
> protect against over-writing customized DB code, which in itself defeats 
> the purpose of automatic code generation.
> 
> In my current little enclave of the IT world, code generators would most 
> often not be worth the trouble, because DB metadata changes quite a lot 
> from prototype to finished product, and quite a bit of business logic is 
> best done within application specific stored procs, functions, 
> constraints, etc. Heck it's hard to even keep Erwin up to date with the 
> pace with which some of this metadata changes.
> 
There are tools out there for deployment, and RoR has some ability to 
adapt to schema changes, it's not flawless, but it's avail.
> As a classic example, code generators will generate code based on a 
> primary key or perhaps indexes; perhaps a select by proc for each column 
> in the PK and/or Indexes, and one for the whole table. If you want to 
> select a range, i.e.: Males in a certain ZIP CODE from the EMPLOYEES 
> table w/o developing a custom stored proc., using inline SQL or adding 
> GENDER and ZIP CODE to the primary key or separate/composite indexes 
> (which would often be madness with low cardinality data like that), 
> you'd have to haul all of the data from that table into a .NET 
> collection and filter from there, instead of doing it where it makes the 
> most sense: in a SQL statement WHERE clause. Now consider all of the 
> different queries any large scale application would likely do and it 
> becomes apparent why code generation can actually be a hindrance to 
> application development in this context.
> 
> Thanks,
> 
> - Dave