4 ms·

Interesting example indeed. I'd say they are a perfect illustration of a feature that, in the words of the article author, "[tries] to abstract out some behavio

by mtts 18y ago

Interesting example indeed. I'd say they are a perfect illustration of a feature that, in the words of the article author, "[tries] to abstract out some behavior that is not that hard to deal with anyway".

gnaritas 18y ago
Worse, pluralization in Rails is a feature that fixes something that isn't even a problem. For a framework based on 1 to 1 table mapping, there's absolutely no reason the tables names shouldn't directly map to the class names with no translation at all. Customer class equals Customer table. Pluralizing them is pointless, and creates minor problems that didn't exist prior. This article however, is extremely bad and its arguments simply don't make sense. Magic isn't bad, leaky abstractions + developers who don't understand it are bad. If he think ORM's don't solve a problem then he hasn't written enough SQL to tire of the insanity of doing it manually when CRUD should clearly be automated because it's so god damn repetitive. Repetition + boredom should always be a signal to automate.
- jasonkester 18y ago
  Ah, but you make the mistake of assuming that automated SQL generation == ORM. That's not the case, at least for us. I touch a bit on the framework we use at Expat here: http://www.expatsoftware.com/articles/2007/03/examplecode-productioncode.html http://www.expatsoftware.com/articles/2007/03/examplecode-pr... Basically, you can think of it as an early-bound Rails. We use CodeSmith to generate a bunch of classes, stored procedures and unit tests based on the existing database schema whenever we make a change to it. Those classes, along with generated wrappers for all our hand-built stored procedures get compiled into the project. This saves us from ever having to guess what SQL we'll get for a given operation, and allows us to pause at any point and be looking at readable code that does real, undestandable work and that can be debugged through. That may seem like a minor distinction, but then I bet you've tried debugging thru ActiveRecord once or twice and I doubt it was any fun. This way, we keep the same fast development pace that a traditional ORM might give us, without sacrificing the debugability and maintainability side (or relying on Magic happening behind the scenes.)
  - gnaritas 18y ago
    Nope, been there, done that, doesn't change my point at all. Automation is automation whether it's at build time or run time, it's still better than doing it by hand. Having been down the path of code generation, I'll take runtime reflection every time, or better yet, switch to a language that doesn't prevent abstraction. The need for tools like CodeSmith just screams how bad .Net languages are, and I know, I'm a full time .Net programmer. I've managed to rewrite one of our main products in Smalltalk where the language just works and you never run into the need to generate masses of code.

by mtts 18y ago

gnaritas 18y ago

Worse, pluralization in Rails is a feature that fixes something that isn't even a problem. For a framework based on 1 to 1 table mapping, there's absolutely no reason the tables names shouldn't directly map to the class names with no translation at all. Customer class equals Customer table. Pluralizing them is pointless, and creates minor problems that didn't exist prior. This article however, is extremely bad and its arguments simply don't make sense. Magic isn't bad, leaky abstractions + developers who don't understand it are bad. If he think ORM's don't solve a problem then he hasn't written enough SQL to tire of the insanity of doing it manually when CRUD should clearly be automated because it's so god damn repetitive. Repetition + boredom should always be a signal to automate.

jasonkester 18y ago
Ah, but you make the mistake of assuming that automated SQL generation == ORM. That's not the case, at least for us. I touch a bit on the framework we use at Expat here: http://www.expatsoftware.com/articles/2007/03/examplecode-productioncode.html http://www.expatsoftware.com/articles/2007/03/examplecode-pr... Basically, you can think of it as an early-bound Rails. We use CodeSmith to generate a bunch of classes, stored procedures and unit tests based on the existing database schema whenever we make a change to it. Those classes, along with generated wrappers for all our hand-built stored procedures get compiled into the project. This saves us from ever having to guess what SQL we'll get for a given operation, and allows us to pause at any point and be looking at readable code that does real, undestandable work and that can be debugged through. That may seem like a minor distinction, but then I bet you've tried debugging thru ActiveRecord once or twice and I doubt it was any fun. This way, we keep the same fast development pace that a traditional ORM might give us, without sacrificing the debugability and maintainability side (or relying on Magic happening behind the scenes.)
- gnaritas 18y ago
  Nope, been there, done that, doesn't change my point at all. Automation is automation whether it's at build time or run time, it's still better than doing it by hand. Having been down the path of code generation, I'll take runtime reflection every time, or better yet, switch to a language that doesn't prevent abstraction. The need for tools like CodeSmith just screams how bad .Net languages are, and I know, I'm a full time .Net programmer. I've managed to rewrite one of our main products in Smalltalk where the language just works and you never run into the need to generate masses of code.