4 ms·

Agree. Specifically on the point of "clear, documented and maintainable" I think this is where languages such as Ruby (and therefore Rails) shines. Since it wa

Agree. Specifically on the point of "clear, documented and maintainable" I think this is where languages such as Ruby (and therefore Rails) shines. Since it was "optimized for developer happiness" (https://news.learnenough.com/ruby-optimized-for-programmer-happiness https://news.learnenough.com/ruby-optimized-for-programmer-h...) it's more likely to be easier to understand, document and maintain.

hfourm 5y ago
Unfortunately in practice, there is so much ruby/rails magic going on that most Rails projects end up in terrible shape. It's kind of a catch-22, and tons of companies have overcome it, but rails by far has the "least long term maintainable" defaults. Good for quick prototypes/small teams but bad for large and scaling teams
- captaincaveman 5y ago
  This was my experience with rails (to be fair, some years ago). Each new version reinvented some huge chunk of the previous version with magic all the way down. Basically why I stopped using it despite having invested lots of time.
- falcolas 5y ago
  > there is so much ruby/rails magic going on that most Rails projects end up in terrible shape Should check out Java Spring (and for a bonus round, Lombak). So much magic pixie dust spewed around to get around not being able to monkey patch.
ravenstine 5y ago
This I think shows how "clear, documented, and maintainable" can mean different things to different people. I specifically left Rails and Ruby because I failed to see any production Rails code actually meet any of those criteria. All of the metaprogramming, OOP, inheritance, and DSLs just made the code more confusing than it needs to be. Ruby is a cult of "the code documents itself", but code can never document itself, because good documentation includes the how and the why and some examples. Code is a horrible at describing how it exists, and no, unit tests are often not sufficient examples. And then there's the issue of Rails apps taking way too long to boot up despite their only job being to serve webpages. Debugging serious issues is a pain when the Ruby code takes minutes to actually run, and having neither clear nor documented code doesn't help. It's always abstractions upon abstractions upon abstractions. But some people like Ruby because it's a beautiful language and Rails gives them an opinionated structure, and maybe that matters more to them. I'll take simple functions and primitive data structures with detailed comments any day over design patterns with a bunch of classes to describe abstract ideas that inherit from one another and fail to self-describe.

hfourm 5y ago

Unfortunately in practice, there is so much ruby/rails magic going on that most Rails projects end up in terrible shape. It's kind of a catch-22, and tons of companies have overcome it, but rails by far has the "least long term maintainable" defaults. Good for quick prototypes/small teams but bad for large and scaling teams

captaincaveman 5y ago
This was my experience with rails (to be fair, some years ago). Each new version reinvented some huge chunk of the previous version with magic all the way down. Basically why I stopped using it despite having invested lots of time.
falcolas 5y ago
> there is so much ruby/rails magic going on that most Rails projects end up in terrible shape Should check out Java Spring (and for a bonus round, Lombak). So much magic pixie dust spewed around to get around not being able to monkey patch.

ravenstine 5y ago

This I think shows how "clear, documented, and maintainable" can mean different things to different people. I specifically left Rails and Ruby because I failed to see any production Rails code actually meet any of those criteria. All of the metaprogramming, OOP, inheritance, and DSLs just made the code more confusing than it needs to be. Ruby is a cult of "the code documents itself", but code can never document itself, because good documentation includes the how and the why and some examples. Code is a horrible at describing how it exists, and no, unit tests are often not sufficient examples. And then there's the issue of Rails apps taking way too long to boot up despite their only job being to serve webpages. Debugging serious issues is a pain when the Ruby code takes minutes to actually run, and having neither clear nor documented code doesn't help. It's always abstractions upon abstractions upon abstractions. But some people like Ruby because it's a beautiful language and Rails gives them an opinionated structure, and maybe that matters more to them. I'll take simple functions and primitive data structures with detailed comments any day over design patterns with a bunch of classes to describe abstract ideas that inherit from one another and fail to self-describe.