Ruby ORM

Ruby
61

On 3 December 2010 22:13, Ryan D. [email protected] wrote:

On Dec 3, 2010, at 00:49 , Mike S. wrote:

I was thinking about this last night and it’s part of a belief I have
that you reuse powerful facilities available to you rather than imitate
them or bodge them into Ruby.

What does this have to do with the “ORM’s Don’t Do It” thread?

Bogus arguments by MS devs were used to support the “ORMs Don’t Do It” ?

… but everything is connected.

Thanks

Michal

62

On Sat, Dec 04, 2010 at 07:25:14AM +0900, Mike S. wrote:

The alternate view is to say an application should use a set of
different languages each optimal for the task at hand.

A DSL is a different language. That’s sorta the point.

If anything, it’s people who insist that SQL, and only SQL, should be
used for DB access that have a hang-up about using different languages
for different tasks. A database ORM provides a DSL that specifically
deals with a particular set of conditions at the point where Ruby and
SQL
intersect. It is, in short, an attempt to make a “best tool for the
job”
rather than rely on trying to get two different tools, each specific to
opposite ends of a spectrum, to mix together without making your life
suck.

63

I propose not to wait until you get enough cash to buy different goods!
You should get the personal
loans or consolidation loans and feel yourself free

64

Ryan D. wrote in post #966039:

What does this have to do with the “ORM’s Don’t Do It” thread?

Don’t thread hijack. Man up and hit “new message”.

This is to do with a current trend - domain specific languages.

You can try and write applications in a single language. ORMs try and
make relational databases look like Ruby.

The alternate view is to say an application should use a set of
different languages each optimal for the task at hand.

So for database tasks, which include manipulation of large sets, sharing
of data, replication etc, you should be happy to use SQL or other
database languages and not try and shoe horn them into Ruby, at least
without some very clear justification.

Typically Ruby applications accept regular expressions, HTML, CSS, Rails
and number of other DSLs -why have a hang up about SQL?

I am extending that principle to say other applications are just as
valid candidates for you to use in your solutions.

If a problem looks like a spreadsheet ie has one or a series of two
dimensional
arrays with positional significance, you should consider whether a
spreadsheet application might more naturally express your algoritm.