3 ms·
> The majority of my job consists of maintaining about a dozen legacy Rails 2 / Ruby 1.8.7 applications, written between 2008-2010, [...] I would be sick of th
by bhaak 9y ago
> The majority of my job consists of maintaining about a dozen legacy Rails 2 / Ruby 1.8.7 applications, written between 2008-2010, [...]
I would be sick of that, too.
I'm also sick of criticism on Ruby when you actually want to criticize Rails. There is a significant overlap in the two communities of course, but both have a distinct profile and you can't just lump them together.
In this case, it's also not helping that they have to stay on an ancient Rails version. With Rails, it's a much smoother experience if you can follow the major releases but especially the upgrade to Rails 3 was a painful one.
Edit: I don't want to imply that you shouldn't criticize Ruby but if you do, don't confuse issues of Rails with those of Ruby. Rails and Ruby code do have quite a different feel to them. It goes this far that when I write a clever little Ruby snippet in a Rails app, I almost feel dirty as it doesn't belong in there.
- mercer 9y agoI learned Ruby before I learned Rails, and the books/tutorials I followed were pretty heavy on the metaprogramming and OO usage (inheritance, etc.). What I find fascinating is that when I read more recent articles/books, the approach is much more functional in nature, with the OO part sometimes seeming little more than namespacing (Sandy Metz, for example). I do think Rails, for all the good stuff it did, promotes 'bad' use of Ruby. But even 'idiomatic Ruby', based on the books-you-should-read suffers from similar problems. It's all fun and exciting to write Ruby code, but if I hadn't been subjected to the 'avoid too much inheritance' and 'write your OO code in a hybrid OO-and-functional way', my output would've suffered from the same issues Rails code does. That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me as a good thing that maintainable Ruby code means avoiding a lot of the cool stuff.
- bhaak 9y ago> That's not to say that I dislike Ruby. I love Ruby. But it doesn't strike me as a good thing that maintainable Ruby code means avoiding a lot of the cool stuff. Ruby is in that regard a lot like C or Perl. It gives you lots of power and options to solve a problem your way but that doesn't mean you should always do so. Rails has used those options extensively and that explains a lot of the criticism you hear about it. This also means Ruby is not for everybody but what language is? IMO you can write unmaintainable code in any language and there is none that makes that hard enough, so I'm firmly in the camp that I'd rather have the full power at my fingertips when I need it than being restricted. Although with the renaissance of functional programming, I would also love to discover a functional language that felt as fresh, powerful, and elegant as Ruby was for OO programming.
- hesarenu 9y agoAlthough with the renaissance of functional programming, I would also love to discover a functional language that felt as fresh, powerful, and elegant as Ruby was for OO programming. Elixir?
- bhaak 9y agoElixir is a possible candidate, yes. I had 2 coworkers that were fanboying over it, so I already got some opinions but I haven't had time to look into it seriously.
- vidarh 9y agoWriting maintainable code in most languages involves knowing exactly when to apply the "cool stuff". Ruby meta-programming can be incredibly powerful - e.g. I'm working on a project at the moment where we dynamically build a very large, complex REST API by introspecting the ORM models augmented with data about access control etc. The entire web API is maybe a tenth of the code it'd have been if we wrote all the code manually, and that proportion is steadily dropping as we add more models. But the key there is that the meta-programming involved is very, very limited for a very high payback. As it is, it raises the barrier for new hires, and we want to make sure not to raise it higher. And most of the rest of the code is taking an increasingly functional approach. I tend to think there is "too much magic" in a lot of Ruby projects, so I try to be very careful and limit it to places were it so drastically cuts down on the amount of code that we can justify quite a lot of explanation and still come out far ahead. But when everything lines up, the benefits can be dramatic.
- LanceH 9y agoHow would he feel maintaining js apps from 2008-2010? Sure there have been changes in both Ruby and Rails since then, but nothing like maintaining javascript.