On Tue, Mar 4, 2008 at 1:15 PM, Stuart Jansen <[EMAIL PROTECTED]> 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
_______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[EMAIL PROTECTED]
