[Dbix-class] how to persuade my colleges to use DBIx::Class

[Jose Fonseca]

On Tue, Mar 4, 2008 at 1:15 PM, Stuart Jansen <sjansen at gurulabs.com> wrote:

> On Tue, 2008-03-04 at 12:00 -0300, Jose Fonseca wrote:
> > Isn't SQL dreadful enough to convince them!!!
>
> SQL is actually beautiful. In fact, sometimes I get annoyed that DBIC
> makes some things harder than SQL.



"Beautiful" in terms languages, in my opinion, is whatever solves a problem
with elegance and simplicity. SQL was a great invention for its time and
still solves 99% of our problems. But I really can't go as far as say it is
beautiful, because SQL is not elegant at all. SQL is a glue language that
solves a specific problem. It's a decent hammer to nail some hard wood. But
maybe you shouldn't be making it of wood in the first place, in which case
the hammer should not be used.

I don't want to start a language war but every day, every minute, you and I
work with linked or self-referencing structures in SQL. And then  when you
have to iterate over and over to get something done you realise that
recursion is what makes something a real language. Recursive data
structures, when translated to SQL, are one heck of a pain in the @55 to
work with. DBIC solves that and I can forget about SQL.

Maybe it isn't DBIC that makes some things harder, maybe it's mixing OO with
SQL that makes it SEEM more difficult. You shouldn't mix the approaches
unless you really know what you're doing and you grasp both concepts fully.
Object Orientation naturally adds an abstraction layer that SQL simply
cannot handle and the back and forth translation between the two worlds is a
difficult mission. You need to choose one way of seeing the problem and
stick with it. While working with DBIC the mere fact you are comparing the
difficulty with SQL means you have not entirely switched to an OO mindset
yet. Because if you had, then SQL has absolutely no meaning in OO(it lacks
the very basic concepts of OO).



> The dreadful thing is not SQL, it is moving stuff in and out of data
> structures. That's why I love DBIC, because it makes my data structures
> smarter, allowing me to focus on the interesting problems.


Yes, absolutely agree.  Which is what I argue above - but why are you still
thinking about SQL and about filling data structures? There is nothing wrong
in what you said but is like comparing Intel Assembler to Perl, they are 2
different tools and they just happen to coexist, nothing more.

And "Smarter data structures" are just objects, unless I'm missing
something. It isn't about DBIC, it's about the mismatch between the
relational world and the OO world. DBIC is our babel fish, doing wonders to
keep you speaking and hearing in OO land without having to listen to the
dialect spoken underneath.

I would focus on the advantage of DBIC as a central point to enforce
> rules that can't be easily enforced by SQL. For example, I've recently
> become annoyed with the way my app handles whitespace for certain
> fields. Instead of scouring the entire app adding normalization rules, I
> can just add a DBIC component and the entire app is fixed painlessly.


Great example there. DRY! Never duplicate information, Don't Repeat
Yourself. And the people who formalized that stuff, the so-called
"Pragmatic" Programmers, are object oriented people and the name of that,
Singletons or whatever, comes from the OO world.

There is nothing wrong with what you said, but I see some mixing of old and
new that can lead to the kind of difficulty you found with DBIC. And in the
end it has nothing to do with DBIC, Hibernate has the same issues because
the legacy technology in RDMS is naturally  incompatible with OO in many
aspects (inheritance, recursion, etc).

Regards,
Ze
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/dbix-class/attachments/20080306/b3b=
1a438/attachment.htm