7 ms·

I'm assuming you are not familiar with solnic's work. Because he is not just idling complaining. His rom project, and the ecosystem of supporting gems which h

by jonahx 10y ago

I'm assuming you are not familiar with solnic's work. Because he is not just idling complaining. His rom project, and the ecosystem of supporting gems which have grown from it over years of work, are the exact opposite of "implemented again, by you, badly." It's more like "implemented for the first time, correctly, by someone who actually understands what good design is."

vinceguidry 10y ago
That's valid, and you're right, I wasn't familiar with his work. But that doesn't diminish any of my points. So he did reimplement ActiveRecord. I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. It's not going to play nice with your design because frameworks by their very nature impose the design on you. With a framework, "works for me" is a perfectly valid reason to keep using it and to dismiss criticisms with. That's the whole point, to get you up and running with as little fuss as possible. I personally hate CSS frameworks, I'd rather retain more control over the markup and selector semantics. That's a choice I make, and I'm aware of the tradeoffs. I would not make the same choice with web dev, because choosing the other side of that tradeoff involves way too much work. But I'm a working coder, I'm not trying to make my mark on the world. I just want to get shit done and move on. Solnic obviously wants to make something bigger than just a website. He's looking for a bluer ocean to tame. Which is cool, we need all kinds of coders. What this is really about is that Rails isn't for him. I can accept that. But his rationale is all wrong, it expects Rails to be something it isn't and never could be. Rails is absolutely the best at what it does for the kinds of coders it's intended to do it for. It tracks the state of the art of web development and boils down most of the complexity with user-friendly abstractions. It's not terribly flexible, but Rails doesn't want to be flexible. It wants to be productive. He wants to go help build the next Rails. Godspeed. I hope he succeeds so that I can go use his framework when it's finally ready in 10 years or so.
- xuejie 10y ago
  I'm sorry but I just don't get this, in your previous comment, you mentioned: You are more than free to re-implement anything Rails does yourself and release it as a gem. Modularity and flexibility are built right in. And right here, you also mentioned: I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. It's not going to play nice with your design because frameworks by their very nature impose the design on you. So which one is correct here?
  - vinceguidry 10y ago
    Flexibility is available in Rails. But is not a top priority. I would say that Rails gets most of its flexibility from Ruby. You have Rails Metal, which is intended to provide a modular way to extend Rails. If you know Ruby well, you can take advantage. Solnic had the capability to do so, and did, but eventually chose to leave the ecosystem. I'm fine with that. I don't expect the techs i use and love to be all things to all people. I just wish he hasn't chosen to shit on the tech that sustained him for so long.
    - dragonwriter 10y ago
      I don't think the honest explanation of the reason he chose to leave the Results ecosystem is shitting on it; and I think that description is itself a sign of the kind of the kind of tribalism in technical communities that obstructs fruitful discussions of technical subjects.
    - patates 10y ago
      > I just wish he hasn't chosen to shit on the tech that sustained him for so long. Oh please stop treating your favorite tech like a religion.
    - askyourmother 10y ago
      Rails is not a religion, it a tech tool (a pretty poor one at that), discussing it's many flaws is not shitting on it.
- coldtea 10y ago
  >But that doesn't diminish any of my points. So he did reimplement ActiveRecord. I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. Who said that? Who carved that in stone? There are absolutely frameworks built to be perfectly OK to have all of their constituent parts used like libraries. This is just repeating "this is how it always used to be" as an argument. >It's not terribly flexible, but Rails doesn't want to be flexible. That's his whole point.
  - vinceguidry 10y ago
    > There are absolutely frameworks built to be perfectly OK to have all of their constituent parts used like libraries. You certainly can use each individual part of Rails without having to bring in the rest of Rails. I bring in ActiveSupport all the time on non-Rails projects. For ORM I prefer Sequel, curious why solnik didn't mention Sequel, the creator of DataMapper even said that Sequel was everything he wanted DataMapper to be and I can't help but think that played a big role in the decision to not continue developing it. You can use Sequel in Rails, I personally prefer ActiveRecord as I'm not aware of a Form Helper gem that works with Sequel, though to be honest I never really looked. Way more people use AR than Sequel, so Stack Overflow debugging goes much smoother. I'm not saying he's wrong for leaving the Ruby / Rails ecosystem. I'm saying his stated reasons are inconsistent with his course of action. I'm fine with his real reasons, I just wish he wouldn't frame it as a slight to Rails.
    - glass_of_water 10y ago
      > ... curious why solnik didn't mention Sequel ... From the article: > It would be unfair not to mention that Sequel showed up already around the same time and till this day it’s being used way less than ActiveRecord despite being a superior solution.
    - ssmoot 10y ago
      I lost interest in DM mostly because of my open-commit-access policy. I mismanaged the project horribly. Just because something was called "Session" (ala Hibernate) instead of "Unit of Work", people would claim it wasn't "pure". The only real compromises for purity were for performance. You saw the same thing play out with ActiveRelation. Ruby is (or was at least) just too slow for complex patterns unless you wanted to pay a huge performance penalty. The kind of slow that materializing 10,000 models in an O/R Mapper would bring your app to it's knees and use hundreds if not gigabytes of RAM. And since a large reason for writing DM in the first place was AR's miserable performance at the time, it needed to be fast. Most of the community wasn't that interested in closing open issues. Not that I blame them. It's not fun. But I was burnt out. During the end, ActiveRelation started development, making many of the same mistakes early DM did in the quest for purity. By that point I just wasn't feeling it anymore. I'd spent orders of magnitude more effort on writing an O/R Mapper than I'd ever hope to recover, and I felt like some of the ideas were fundamentally flawed. So I moved on. If I were still doing Ruby, I'd be using Sequel though.
- ivan_gammel 10y ago
  Frameworks do not necessarily impose the complete design of the application. Spring Framework in Java, for example, is great, but the only essential part of it is DI container: you may not use persistence, presentation or security layer provided by it, if it does not fully fit your architecture. Good modularity defines quality of the framework and Rails is apparently not best on that criteria.
  - oafitupa 10y ago
    Another example is Symfony2, which is completely decoupled (not just loosely coupled). Oh but php programmers are bad, am I right HN?
    - vesak 10y ago
      No. PHP programmers aren't "bad", PHP is.
    - proyb2 10y ago
      Magento and Shopify backend are awfully slow, it's the language, not the programmers.
      - andruby 10y ago
        Shopify is built on Rails, you know that right?
        spdionis 10y ago
        And Magento is slow for a whole lot of reasons, nine of which are related to symfony.
        AMHOL 10y ago
        Magento is slow because it uses EAV
        oafitupa 10y ago
- lgierth 10y ago
  Nitpicking here, solnic didn't reimplement ActiveRecord (he did, but that's long ago) -- ROM implements the DataMapper pattern.
  - vinceguidry 10y ago
    I can nitpick too! :) I never said he reimplemented active record, I said he reimplemented ActiveRecord. Though I suppose the better verb to use would have been 're-engineered'. Reimplementing seems to imply an algorithm or design pattern, where I meant to re-do the functionality.
    - spraak 10y ago
      >I never said he reimplemented active record, I said he reimplemented ActiveRecord You didn't yet you did? You've said the same thing twice here
      - vinceguidry 10y ago
        ActiveRecord is an implementation of the active record pattern. DataMapper is an implementation of the data mapper pattern. https://en.wikipedia.org/wiki/Data_mapper_pattern https://en.wikipedia.org/wiki/Data_mapper_pattern https://en.wikipedia.org/wiki/Active_record_pattern https://en.wikipedia.org/wiki/Active_record_pattern
        lgierth 10y ago
        The ruby lib DataMapper is actually an implementation of the active record pattern too ;) That's one reason to why ROM exists.
  - ssmoot 10y ago
    The idea that DM wasn't a DataMapper is misguided. Check out: https://github.com/datamapper/dm-core/blob/0.9.0.1/lib/data_mapper/repository.rb#L72 https://github.com/datamapper/dm-core/blob/0.9.0.1/lib/data_... The convenience methods were just wrappers. Earlier versions were even more true to the PoEAA version of a DataMapper with a Unit of Work in the Session class. Turned out this was a bad idea if your primary motivation is performance. The fact that it didn't bother to abstract away DataObjects was by design. Nobody would claim NHibernate (of the time, 2.x) wasn't a Data Mapper implementation just because it didn't have an adapter for treating an XML file as a database. That's a parlor trick. The real effort is in making it work and making it fast. Porting Java designs to Ruby just didn't scale in the Ruby implementations of the time and conscious decisions were made to ensure DM would actually solve the problems it was developed to address (#1 being performance as I had a large set of data to migrate that initial experiments with AR projected to take a month(!)). The primary concern turned out to be Ruby method dispatch performance. The shorter you could make the stack, the better. Since loading 1,000 objects might be operating on a 10,000 row set, and another order of magnitude more fields, the materialization pipeline had to be streamlined as much as possible. (AR implemented a nasty abomination of a hack for this by round-tripping to the database multiple times). When it's faster to round-trip to the database multiple times than it is to iterate a large object in memory, you've got a real problem. The lazy loading, explicit fields, dirty tracking in the Unit of Work, (which at the time were all fairly controversial ideas in rails-core) etc were all an effort to address performance. The PoEAA was an inspiration for sure, but it turned out to be a prescription for poor performance on Ruby 1.8.x.
- mattmcknight 10y ago
  I think this is more about Active Record the design pattern, than ActiveRecord the Rails component. Active Record is a really easy to use pattern and ActiveRecord is a very humane implementation. Data Mapper (the pattern) is more complex. Trying to get a Data Mapper implementation to do all of the things the ActiveRecord implementation in Rails does is really hard- it's always going to be harder when you need the object model structure to significantly deviate from the database structure.
rhefan_ney 10y ago
Jonah so good

by jonahx 10y ago

vinceguidry 10y ago

That's valid, and you're right, I wasn't familiar with his work. But that doesn't diminish any of my points. So he did reimplement ActiveRecord. I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. It's not going to play nice with your design because frameworks by their very nature impose the design on you. With a framework, "works for me" is a perfectly valid reason to keep using it and to dismiss criticisms with. That's the whole point, to get you up and running with as little fuss as possible. I personally hate CSS frameworks, I'd rather retain more control over the markup and selector semantics. That's a choice I make, and I'm aware of the tradeoffs. I would not make the same choice with web dev, because choosing the other side of that tradeoff involves way too much work. But I'm a working coder, I'm not trying to make my mark on the world. I just want to get shit done and move on. Solnic obviously wants to make something bigger than just a website. He's looking for a bluer ocean to tame. Which is cool, we need all kinds of coders. What this is really about is that Rails isn't for him. I can accept that. But his rationale is all wrong, it expects Rails to be something it isn't and never could be. Rails is absolutely the best at what it does for the kinds of coders it's intended to do it for. It tracks the state of the art of web development and boils down most of the complexity with user-friendly abstractions. It's not terribly flexible, but Rails doesn't want to be flexible. It wants to be productive. He wants to go help build the next Rails. Godspeed. I hope he succeeds so that I can go use his framework when it's finally ready in 10 years or so.

xuejie 10y ago
I'm sorry but I just don't get this, in your previous comment, you mentioned: You are more than free to re-implement anything Rails does yourself and release it as a gem. Modularity and flexibility are built right in. And right here, you also mentioned: I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. It's not going to play nice with your design because frameworks by their very nature impose the design on you. So which one is correct here?
- vinceguidry 10y ago
  Flexibility is available in Rails. But is not a top priority. I would say that Rails gets most of its flexibility from Ruby. You have Rails Metal, which is intended to provide a modular way to extend Rails. If you know Ruby well, you can take advantage. Solnic had the capability to do so, and did, but eventually chose to leave the ecosystem. I'm fine with that. I don't expect the techs i use and love to be all things to all people. I just wish he hasn't chosen to shit on the tech that sustained him for so long.
  - dragonwriter 10y ago
    I don't think the honest explanation of the reason he chose to leave the Results ecosystem is shitting on it; and I think that description is itself a sign of the kind of the kind of tribalism in technical communities that obstructs fruitful discussions of technical subjects.
  - patates 10y ago
    > I just wish he hasn't chosen to shit on the tech that sustained him for so long. Oh please stop treating your favorite tech like a religion.
  - askyourmother 10y ago
    Rails is not a religion, it a tech tool (a pretty poor one at that), discussing it's many flaws is not shitting on it.
coldtea 10y ago
>But that doesn't diminish any of my points. So he did reimplement ActiveRecord. I'm not surprised he found it difficult to actually integrate into Rails. Rails is a framework. You don't treat a framework like a library. Who said that? Who carved that in stone? There are absolutely frameworks built to be perfectly OK to have all of their constituent parts used like libraries. This is just repeating "this is how it always used to be" as an argument. >It's not terribly flexible, but Rails doesn't want to be flexible. That's his whole point.
- vinceguidry 10y ago
  > There are absolutely frameworks built to be perfectly OK to have all of their constituent parts used like libraries. You certainly can use each individual part of Rails without having to bring in the rest of Rails. I bring in ActiveSupport all the time on non-Rails projects. For ORM I prefer Sequel, curious why solnik didn't mention Sequel, the creator of DataMapper even said that Sequel was everything he wanted DataMapper to be and I can't help but think that played a big role in the decision to not continue developing it. You can use Sequel in Rails, I personally prefer ActiveRecord as I'm not aware of a Form Helper gem that works with Sequel, though to be honest I never really looked. Way more people use AR than Sequel, so Stack Overflow debugging goes much smoother. I'm not saying he's wrong for leaving the Ruby / Rails ecosystem. I'm saying his stated reasons are inconsistent with his course of action. I'm fine with his real reasons, I just wish he wouldn't frame it as a slight to Rails.
  - glass_of_water 10y ago
    > ... curious why solnik didn't mention Sequel ... From the article: > It would be unfair not to mention that Sequel showed up already around the same time and till this day it’s being used way less than ActiveRecord despite being a superior solution.
  - ssmoot 10y ago
    I lost interest in DM mostly because of my open-commit-access policy. I mismanaged the project horribly. Just because something was called "Session" (ala Hibernate) instead of "Unit of Work", people would claim it wasn't "pure". The only real compromises for purity were for performance. You saw the same thing play out with ActiveRelation. Ruby is (or was at least) just too slow for complex patterns unless you wanted to pay a huge performance penalty. The kind of slow that materializing 10,000 models in an O/R Mapper would bring your app to it's knees and use hundreds if not gigabytes of RAM. And since a large reason for writing DM in the first place was AR's miserable performance at the time, it needed to be fast. Most of the community wasn't that interested in closing open issues. Not that I blame them. It's not fun. But I was burnt out. During the end, ActiveRelation started development, making many of the same mistakes early DM did in the quest for purity. By that point I just wasn't feeling it anymore. I'd spent orders of magnitude more effort on writing an O/R Mapper than I'd ever hope to recover, and I felt like some of the ideas were fundamentally flawed. So I moved on. If I were still doing Ruby, I'd be using Sequel though.
ivan_gammel 10y ago
Frameworks do not necessarily impose the complete design of the application. Spring Framework in Java, for example, is great, but the only essential part of it is DI container: you may not use persistence, presentation or security layer provided by it, if it does not fully fit your architecture. Good modularity defines quality of the framework and Rails is apparently not best on that criteria.
- oafitupa 10y ago
  Another example is Symfony2, which is completely decoupled (not just loosely coupled). Oh but php programmers are bad, am I right HN?
  - vesak 10y ago
    No. PHP programmers aren't "bad", PHP is.
  - proyb2 10y ago
    Magento and Shopify backend are awfully slow, it's the language, not the programmers.
    - andruby 10y ago
      Shopify is built on Rails, you know that right?
      - spdionis 10y ago
        And Magento is slow for a whole lot of reasons, nine of which are related to symfony.
        AMHOL 10y ago
        Magento is slow because it uses EAV
        oafitupa 10y ago
lgierth 10y ago
Nitpicking here, solnic didn't reimplement ActiveRecord (he did, but that's long ago) -- ROM implements the DataMapper pattern.
- vinceguidry 10y ago
  I can nitpick too! :) I never said he reimplemented active record, I said he reimplemented ActiveRecord. Though I suppose the better verb to use would have been 're-engineered'. Reimplementing seems to imply an algorithm or design pattern, where I meant to re-do the functionality.
  - spraak 10y ago
    >I never said he reimplemented active record, I said he reimplemented ActiveRecord You didn't yet you did? You've said the same thing twice here
    - vinceguidry 10y ago
      ActiveRecord is an implementation of the active record pattern. DataMapper is an implementation of the data mapper pattern. https://en.wikipedia.org/wiki/Data_mapper_pattern https://en.wikipedia.org/wiki/Data_mapper_pattern https://en.wikipedia.org/wiki/Active_record_pattern https://en.wikipedia.org/wiki/Active_record_pattern
      - lgierth 10y ago
        The ruby lib DataMapper is actually an implementation of the active record pattern too ;) That's one reason to why ROM exists.
- ssmoot 10y ago
  The idea that DM wasn't a DataMapper is misguided. Check out: https://github.com/datamapper/dm-core/blob/0.9.0.1/lib/data_mapper/repository.rb#L72 https://github.com/datamapper/dm-core/blob/0.9.0.1/lib/data_... The convenience methods were just wrappers. Earlier versions were even more true to the PoEAA version of a DataMapper with a Unit of Work in the Session class. Turned out this was a bad idea if your primary motivation is performance. The fact that it didn't bother to abstract away DataObjects was by design. Nobody would claim NHibernate (of the time, 2.x) wasn't a Data Mapper implementation just because it didn't have an adapter for treating an XML file as a database. That's a parlor trick. The real effort is in making it work and making it fast. Porting Java designs to Ruby just didn't scale in the Ruby implementations of the time and conscious decisions were made to ensure DM would actually solve the problems it was developed to address (#1 being performance as I had a large set of data to migrate that initial experiments with AR projected to take a month(!)). The primary concern turned out to be Ruby method dispatch performance. The shorter you could make the stack, the better. Since loading 1,000 objects might be operating on a 10,000 row set, and another order of magnitude more fields, the materialization pipeline had to be streamlined as much as possible. (AR implemented a nasty abomination of a hack for this by round-tripping to the database multiple times). When it's faster to round-trip to the database multiple times than it is to iterate a large object in memory, you've got a real problem. The lazy loading, explicit fields, dirty tracking in the Unit of Work, (which at the time were all fairly controversial ideas in rails-core) etc were all an effort to address performance. The PoEAA was an inspiration for sure, but it turned out to be a prescription for poor performance on Ruby 1.8.x.
mattmcknight 10y ago
I think this is more about Active Record the design pattern, than ActiveRecord the Rails component. Active Record is a really easy to use pattern and ActiveRecord is a very humane implementation. Data Mapper (the pattern) is more complex. Trying to get a Data Mapper implementation to do all of the things the ActiveRecord implementation in Rails does is really hard- it's always going to be harder when you need the object model structure to significantly deviate from the database structure.

rhefan_ney 10y ago

Jonah so good