3 ms·

I read this with a lot of head-nodding but also a great sense of sadness. I agree with pretty much every brickbat hurled at Rails in this article, except for o

I read this with a lot of head-nodding but also a great sense of sadness. I agree with pretty much every brickbat hurled at Rails in this article, except for one thing: > Both projects were ultimately killed by Rails as Merb was “merged” into Rails, what turned out to be a major Rails refactor for its 3.0 version. DataMapper lost its community attention and without much support, it never evolved as it could if Merb was not “merged” into Rails. DataMapper wasn't killed by Rails absorbing Merb. DataMapper was killed by "Things You Should Never Do, Part I": > "They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch." (http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html) DataMapper 2 was insanely ambitious, and true enough, it was never finished. A core subset was salvaged as ROM (Ruby Object Mapper), which has a certain artisan purity but is a long way from hitting the readable/understandable sweet spot that DataMapper originally had. But DataMapper 1 was abandoned by its developers. Pull requests languished and there weren't even any maintenance releases. I idled in the DataMapper IRC channel for a while and pretty much every query was answered with "don't bother, wait for DM 2". Unsurprisingly, people switched to ActiveRecord instead. I still use DataMapper. I use it in my own framework, which is plaintively simple compared to Rails and no doubt makes a load of mistakes, but they're the mistakes I've chosen to make (which, as per DHH, is "opinionated" software). I would love DataMapper to be, if not revived, at least slightly maintained. There is life outside Rails, but you have to want it.

twic 10y ago
It astounds me that people are still citing that Spolsky article when its central example of what not to do is the writing of Firefox, which turned out to be a huge success. Not that rewriting from scratch is always a good move. Evidently, DataMapper proves that!
- WillPostForFood 10y ago
  The Spolsky article is about Netscape 6. That rewrite took 3 years, during which time (1997-2000) they lost ~80% of their users to competing browsers? It may have been amazing software, but not a success. Firefox/Netscape 8 was 2005ish.
solnic 10y ago
I dare to disagree. My point about DM being killed by Merb/Rails merge was about what happened back in 2008 with its consequences through all the years. I'm talking about DM1 specifically, if Merb survived and DM could grow with it we would be in a different place now already. As far as our DM2 efforts go, this really didn't end so bad. rom-rb is growing very fast and we're already in the process of making it easy to use for typical CRUD stuff. Hanami integration will help here a lot too.
- Doctor_Fegg 10y ago
  Thanks: Hanami looks really promising, and could well provide the human-friendly syntax that ROM lacks.
ssmoot 10y ago
You nailed it. HABTM just never worked, and there was little interest in making it work. Since I handed out commit-access like candy, the majority of contributions were to endlessly refactor. Or do things like letting you treat a CSV file as a database. And HABTM still didn't work. I didn't know how to put the genie back in the bottle. I didn't have the same problems that prompted me to create DM in the first place anymore (and by that point, I wasn't sure that porting a large Java Pattern to Ruby was even a good idea considering what I'd learned in the process about method dispatch performance in Ruby) and I was burned out on maintenance. So I handed over the keys and the rest is history. I messed up. :-) Today I'm happily writing apps with akka-http and think O/R Mappers are a fundamentally flawed idea. It's like trying to build a truck to move a few yards of dirt 100 feet. It'll never pay off. And I think even "users" would probably find that the hours they put into learning and using the tool will never get ahead of the performance, simplicity and linear scaling of effort they'd have had with a simpler solution. So these days I'm much more likely to write this in Scala: val limit = 10.0 sql"SELECT name FROM coffees WHERE price < $limit".as[String] Than anything else. You will never find an O/RM that's faster, simpler or easier to write and maintain than that. Plus Contextual Validations in the O/RM is just a bad idea. Even if they do appear in the PoEAA. First-class-Form objects and deserialization/validation at the app boundaries may not be a new idea, but it's the right one. (IMO)
- solnic 10y ago
  Hey Sam, great to see you commenting on this :) I started contributing to DM when Dan was already in charge but I was a DM user when you were still working on it. Anyhow, you made really good points here. I've worked on ORMs for a couple of years before I concluded the same - NOT WORTH THE EFFORT. My approach with rom-rb is functional, as in this project works more like persistence libs in functional languages, rather than an O/R mapper. I removed the whole idea of mutable objects and managing their state using UoW etc. This simplified the stack a lot, and despite a complete lack of any performance-related tweaks rom-rb is already faster than ActiveRecord. I also agree with your opinion re validations. I removed this concept from rom-rb as well and built a standalone validation library instead. This works very well. Cheers!
  - 10y ago

twic 10y ago

It astounds me that people are still citing that Spolsky article when its central example of what not to do is the writing of Firefox, which turned out to be a huge success. Not that rewriting from scratch is always a good move. Evidently, DataMapper proves that!

WillPostForFood 10y ago
The Spolsky article is about Netscape 6. That rewrite took 3 years, during which time (1997-2000) they lost ~80% of their users to competing browsers? It may have been amazing software, but not a success. Firefox/Netscape 8 was 2005ish.

solnic 10y ago

I dare to disagree. My point about DM being killed by Merb/Rails merge was about what happened back in 2008 with its consequences through all the years. I'm talking about DM1 specifically, if Merb survived and DM could grow with it we would be in a different place now already. As far as our DM2 efforts go, this really didn't end so bad. rom-rb is growing very fast and we're already in the process of making it easy to use for typical CRUD stuff. Hanami integration will help here a lot too.

Doctor_Fegg 10y ago
Thanks: Hanami looks really promising, and could well provide the human-friendly syntax that ROM lacks.

ssmoot 10y ago

You nailed it. HABTM just never worked, and there was little interest in making it work. Since I handed out commit-access like candy, the majority of contributions were to endlessly refactor. Or do things like letting you treat a CSV file as a database. And HABTM still didn't work. I didn't know how to put the genie back in the bottle. I didn't have the same problems that prompted me to create DM in the first place anymore (and by that point, I wasn't sure that porting a large Java Pattern to Ruby was even a good idea considering what I'd learned in the process about method dispatch performance in Ruby) and I was burned out on maintenance. So I handed over the keys and the rest is history. I messed up. :-) Today I'm happily writing apps with akka-http and think O/R Mappers are a fundamentally flawed idea. It's like trying to build a truck to move a few yards of dirt 100 feet. It'll never pay off. And I think even "users" would probably find that the hours they put into learning and using the tool will never get ahead of the performance, simplicity and linear scaling of effort they'd have had with a simpler solution. So these days I'm much more likely to write this in Scala: val limit = 10.0 sql"SELECT name FROM coffees WHERE price < $limit".as[String] Than anything else. You will never find an O/RM that's faster, simpler or easier to write and maintain than that. Plus Contextual Validations in the O/RM is just a bad idea. Even if they do appear in the PoEAA. First-class-Form objects and deserialization/validation at the app boundaries may not be a new idea, but it's the right one. (IMO)

solnic 10y ago
Hey Sam, great to see you commenting on this :) I started contributing to DM when Dan was already in charge but I was a DM user when you were still working on it. Anyhow, you made really good points here. I've worked on ORMs for a couple of years before I concluded the same - NOT WORTH THE EFFORT. My approach with rom-rb is functional, as in this project works more like persistence libs in functional languages, rather than an O/R mapper. I removed the whole idea of mutable objects and managing their state using UoW etc. This simplified the stack a lot, and despite a complete lack of any performance-related tweaks rom-rb is already faster than ActiveRecord. I also agree with your opinion re validations. I removed this concept from rom-rb as well and built a standalone validation library instead. This works very well. Cheers!
- 10y ago