4 ms·

Abstraction layers are great... if you don't end up spending 90% of your time climbing the stairs that connect them! Take SQL, a nice DSL for working with rela

by nnq 14y ago

Abstraction layers are great... if you don't end up spending 90% of your time climbing the stairs that connect them! Take SQL, a nice DSL for working with relational databases. Yet people ended up writing ORMs (quite ugly creatures imho - something between an elevator connecting two layers, and as in real life elevators are a mess when too many people want to use them at the same time, and an intermediate pseudo-level, but they are useful) because the pain of climbing up and down the ladder connecting the "relational level" with the "OO layer". "Language layers" or DSLs are a powerful but dangerous abstraction because when they start using them people can't stop, they just make more and more layers like crazy! (The only other abstraction so powerful and so dangerous I can think of are objects - it's amazing how many got them completely wrong so many times in languages like C++ or Java... besides Ruby and Smalltalk I can't think of anything that got them "mostly right"... and Ruby seems to be the most DSL-able language in use too, though this is why I'd take Python over it any day - smart programmers tend to make everything like a freakin DSL in Ruby and and your mind ends up running up and down the ladders until you go insane when reading code).

mercurial 14y ago
The other problem with SQL is the "standard problem": you have so may of them to choose for that when you need to support several databases, the additional layer of complexity and black magic of an ORM can be worth it.
nahname 14y ago
I can't speak for everyone, but the reason I choose to use an ORM over writing all my SQL by hand is time and maintenance cost. I can write one SQL query to perform CRUD operations for a model almost as quickly as I could use a ORM. The problem is that it produces 10 times as much code to read and interprete. If I write the SQL code for another model, 90% of that new code is exactly the same as the last. I am bleeding duplication everywhere.
agentultra 14y ago
What is completely wrong about the way C++ does "objects?" I've recently been digging hard-core into C++ after making such disparaging comments for years and have been rather surprised to see that it's not as terrible as I once thought -- It's actually quite good. I agree however with your point about dangerous abstractions. DSLs when implemented with careful, thoughtful restraint are rather powerful. SQL being a really good example. There's nothing stopping anyone from writing their database queries by directly sifting through and filtering datums from the domain using the primitive functions and operations of their programming language of choice... but it's clear that SQL is much more powerful and lets us express such problems in a succinct way. But just like programming languages, once introduced, a DSL is likely to be misunderstood and abused. The problem I believe lies not with the technique but with the users. A double-edged sword is a fine tool but will likely maim an inexperienced user. Which will probably lead them to writing DoubleEdgeSwordWrapperMachineGun classes and then someone else to write a DSL on top of that...
ef4 14y ago
Your example is actually a pet peeve of mine. SQL is not at all a nice DSL for working with relational databases programmatically. When you think of it as an API, it exposes one method that takes one gigantic string parameter. API design doesn't get much worse than that. A sane relational database API would let you compose and extend arbitrary queries, which has profound implications for the way you can write your program and abstract away repeated patterns. [Arel](https://github.com/nkallen/arel https://github.com/nkallen/arel) has the right idea in terms of API, but a poor implementation (lots of things are not truly composable where they should be). [ScalaQuery](http://www.scalaquery.org/ http://www.scalaquery.org/) purports to have the right idea, but I haven't tried it, and it's very Scala-centric.

by nnq 14y ago

mercurial 14y ago

The other problem with SQL is the "standard problem": you have so may of them to choose for that when you need to support several databases, the additional layer of complexity and black magic of an ORM can be worth it.

nahname 14y ago

I can't speak for everyone, but the reason I choose to use an ORM over writing all my SQL by hand is time and maintenance cost. I can write one SQL query to perform CRUD operations for a model almost as quickly as I could use a ORM. The problem is that it produces 10 times as much code to read and interprete. If I write the SQL code for another model, 90% of that new code is exactly the same as the last. I am bleeding duplication everywhere.

agentultra 14y ago

What is completely wrong about the way C++ does "objects?" I've recently been digging hard-core into C++ after making such disparaging comments for years and have been rather surprised to see that it's not as terrible as I once thought -- It's actually quite good. I agree however with your point about dangerous abstractions. DSLs when implemented with careful, thoughtful restraint are rather powerful. SQL being a really good example. There's nothing stopping anyone from writing their database queries by directly sifting through and filtering datums from the domain using the primitive functions and operations of their programming language of choice... but it's clear that SQL is much more powerful and lets us express such problems in a succinct way. But just like programming languages, once introduced, a DSL is likely to be misunderstood and abused. The problem I believe lies not with the technique but with the users. A double-edged sword is a fine tool but will likely maim an inexperienced user. Which will probably lead them to writing DoubleEdgeSwordWrapperMachineGun classes and then someone else to write a DSL on top of that...

ef4 14y ago

Your example is actually a pet peeve of mine. SQL is not at all a nice DSL for working with relational databases programmatically. When you think of it as an API, it exposes one method that takes one gigantic string parameter. API design doesn't get much worse than that. A sane relational database API would let you compose and extend arbitrary queries, which has profound implications for the way you can write your program and abstract away repeated patterns. [Arel](https://github.com/nkallen/arel https://github.com/nkallen/arel) has the right idea in terms of API, but a poor implementation (lots of things are not truly composable where they should be). [ScalaQuery](http://www.scalaquery.org/ http://www.scalaquery.org/) purports to have the right idea, but I haven't tried it, and it's very Scala-centric.