4 ms·

If there's only one thing I've learnt from trying different languages out: the less magic, the better.

by RyanZAG 13y ago

tptacek 13y ago
This is an easy and thus superficial bit of insight to add. A more reliable truism would be that "unnecessary magic is bad", but that brings us no closer to evaluating Rails. Ultimately, you have to be able to point to specific magical behaviors and make a case for what makes them gratuitous.
- ExpiredLink 13y ago
  What is necessary magic?
  - tptacek 13y ago
    Compilers, to start. What's unnecessary magic?
    - btilly 13y ago
      Serialization/deserialization logic that automatically will instantiate objects that require dynamic initialization, without making it clear to the programmers that this happened. That's both unnecessary, and extremely pertinent in the case of Rails this year.
      - tptacek 13y ago
        I agree, but would also point out that the pertinent cases you're referring to weren't a part of the mainstream Rails API.
- majormajor 13y ago
  Without turning this into a debate about particular bits of magic, my general conclusion from using Rails (especially when projects are in maintenance mode) is that it frequently makes it overly complicated to do things differently than how the framework wants you to, making you resort to monkey patching and other magical strategies of your own. It's wonderful for prototyping but I'm becoming increasingly wary of it for production systems that are going to have a long life (at which point the whole perf/scaling thing comes into play too). Which is all a very roundabout way of saying "use the right tool for the right job," I suppose.
  - matthewmacleod 13y ago
    > my general conclusion from using Rails is that it frequently makes it overly complicated to do things differently than how the framework wants you to I can't agree with this at all. Rails has default and reasonably sensible idioms for expressing common concepts. They work in most cases, but there are of course situations where you want to implement something in a way that results in an impedance mismatch with the framework. In these cases, it's embarrassingly easy to compose different behaviours, or indeed to write entirely custom ones, in order to achieve the functionality you require. At the end of the day, it's Ruby with some helper libraries, and developers are free to use as much or as little of these as is required. If there's a problem in this vein with Rails, it's that the magic makes it almost too tempting to twist apps into the "Rails way", even when it's not appropriate. Good developers will be aware of this, and use the correct approach.
  - Legion 13y ago
    I think this observations was much more true of Rails 2.x and before than Rails 3 forward. People forget that "Rails 3" was actually Rails merging with Merb. A lot of hard-coded inflexibility of Rails 2 had to be extracted out, and the framework became much more malleable as a result. When I hear people talk about being stuck to a certain path with Rails, I wonder what they are talking about. Then I think back to Rails 2 and think, "oh, right....". Rails still encourages a certain path by convention, but it is much easier to deconstruct than before.
  - grey-area 13y ago
    It's wonderful for prototyping but I'm becoming increasingly wary of it for production systems that are going to have a long life (at which point the whole perf/scaling thing comes into play too). It's interesting because I've had exactly the opposite experience with Rails in production environments. I prefer to prototype with something simpler, but have found Rails pretty solid for delivering full websites with a complex back-end and tens of thousands of daily users (hardly web-scale, but not insignificant either - probably most sites fall in this bracket). Not that it's the only solution in that space, there are lots of other suitable frameworks, but I'd say it's not bad. It will use more resources than some other solutions, so it's definitely not the most efficient in machine time, but it makes up for that IMHO in being efficient to work with. We're running some relatively busy sites with Rails and have seen no issues with maintenance or performance (due to caching), and I don't foresee any problems simply because for most web applications you can get acceptable performance up to very high scale by caching selectively. The support for russian-doll style caching and automatic expiration on db changes is pretty good, they're not bad about getting rid of cruft, and over several years I haven't run into any significant maintenance issues. My biggest worry with Rails is security, but that has improved, and is probably better than roll-your-own frameworks anyway. Having come from Rails 1 and quite a few other web frameworks/CMS solutions, I don't really see Rails as having a lot of magic nowadays, though it does have lots of little shortcuts like scopes, and lots of helpers for everyday tasks like mailing, querying, dates, rendering templates etc. So I've found it a help rather than a hindrance and one of the few frameworks which stays out of your way enough to be worth the trade-off. In particular I like that the conventions mean that when you come back to a project after a few months the decisions on naming and placing functionality will all make sense, if you've followed those conventions. It would be interesting to know which specific areas you've seen problems on, if only as a warning for others using Rails. I can imagine for example if you didn't want to accept the database naming conventions, or the file naming conventions it'd be a pain to work with and constantly tripping you up.
james_madison 13y ago
how about Ruby with less magic? http://rubyluwak.com/ http://rubyluwak.com/
rdouble 13y ago
I vastly prefer magic, so long as it works.
jshen 13y ago
Define magic.
- klibertp 13y ago
  Well, sufficiently advanced technology, wasn't it?
fuzzix 13y ago
Indeed - the KISS principle was once commonly cited in this industry.
nicholassmith 13y ago
Magic is great, it's hugely entertaining and can be used for great effect. However, knowing how to deconstruct the magic is also very useful so you know how the sleight of hand has taken place.

If there's only one thing I've learnt from trying different languages out: the less magic, the better.

by RyanZAG 13y ago

If there's only one thing I've learnt from trying different languages out: the less magic, the better.

This is an easy and thus superficial bit of insight to add. A more reliable truism would be that "unnecessary magic is bad", but that brings us no closer to evaluating Rails. Ultimately, you have to be able to point to specific magical behaviors and make a case for what makes them gratuitous.

ExpiredLink 13y ago
What is necessary magic?
- tptacek 13y ago
  Compilers, to start. What's unnecessary magic?
  - btilly 13y ago
    Serialization/deserialization logic that automatically will instantiate objects that require dynamic initialization, without making it clear to the programmers that this happened. That's both unnecessary, and extremely pertinent in the case of Rails this year.
    - tptacek 13y ago
      I agree, but would also point out that the pertinent cases you're referring to weren't a part of the mainstream Rails API.
majormajor 13y ago
Without turning this into a debate about particular bits of magic, my general conclusion from using Rails (especially when projects are in maintenance mode) is that it frequently makes it overly complicated to do things differently than how the framework wants you to, making you resort to monkey patching and other magical strategies of your own. It's wonderful for prototyping but I'm becoming increasingly wary of it for production systems that are going to have a long life (at which point the whole perf/scaling thing comes into play too). Which is all a very roundabout way of saying "use the right tool for the right job," I suppose.
- matthewmacleod 13y ago
  > my general conclusion from using Rails is that it frequently makes it overly complicated to do things differently than how the framework wants you to I can't agree with this at all. Rails has default and reasonably sensible idioms for expressing common concepts. They work in most cases, but there are of course situations where you want to implement something in a way that results in an impedance mismatch with the framework. In these cases, it's embarrassingly easy to compose different behaviours, or indeed to write entirely custom ones, in order to achieve the functionality you require. At the end of the day, it's Ruby with some helper libraries, and developers are free to use as much or as little of these as is required. If there's a problem in this vein with Rails, it's that the magic makes it almost too tempting to twist apps into the "Rails way", even when it's not appropriate. Good developers will be aware of this, and use the correct approach.
- Legion 13y ago
  I think this observations was much more true of Rails 2.x and before than Rails 3 forward. People forget that "Rails 3" was actually Rails merging with Merb. A lot of hard-coded inflexibility of Rails 2 had to be extracted out, and the framework became much more malleable as a result. When I hear people talk about being stuck to a certain path with Rails, I wonder what they are talking about. Then I think back to Rails 2 and think, "oh, right....". Rails still encourages a certain path by convention, but it is much easier to deconstruct than before.
- grey-area 13y ago
  It's wonderful for prototyping but I'm becoming increasingly wary of it for production systems that are going to have a long life (at which point the whole perf/scaling thing comes into play too). It's interesting because I've had exactly the opposite experience with Rails in production environments. I prefer to prototype with something simpler, but have found Rails pretty solid for delivering full websites with a complex back-end and tens of thousands of daily users (hardly web-scale, but not insignificant either - probably most sites fall in this bracket). Not that it's the only solution in that space, there are lots of other suitable frameworks, but I'd say it's not bad. It will use more resources than some other solutions, so it's definitely not the most efficient in machine time, but it makes up for that IMHO in being efficient to work with. We're running some relatively busy sites with Rails and have seen no issues with maintenance or performance (due to caching), and I don't foresee any problems simply because for most web applications you can get acceptable performance up to very high scale by caching selectively. The support for russian-doll style caching and automatic expiration on db changes is pretty good, they're not bad about getting rid of cruft, and over several years I haven't run into any significant maintenance issues. My biggest worry with Rails is security, but that has improved, and is probably better than roll-your-own frameworks anyway. Having come from Rails 1 and quite a few other web frameworks/CMS solutions, I don't really see Rails as having a lot of magic nowadays, though it does have lots of little shortcuts like scopes, and lots of helpers for everyday tasks like mailing, querying, dates, rendering templates etc. So I've found it a help rather than a hindrance and one of the few frameworks which stays out of your way enough to be worth the trade-off. In particular I like that the conventions mean that when you come back to a project after a few months the decisions on naming and placing functionality will all make sense, if you've followed those conventions. It would be interesting to know which specific areas you've seen problems on, if only as a warning for others using Rails. I can imagine for example if you didn't want to accept the database naming conventions, or the file naming conventions it'd be a pain to work with and constantly tripping you up.

james_madison 13y ago

how about Ruby with less magic? http://rubyluwak.com/ http://rubyluwak.com/

rdouble 13y ago

I vastly prefer magic, so long as it works.

jshen 13y ago

Define magic.

klibertp 13y ago
Well, sufficiently advanced technology, wasn't it?

fuzzix 13y ago

Indeed - the KISS principle was once commonly cited in this industry.

nicholassmith 13y ago

Magic is great, it's hugely entertaining and can be used for great effect. However, knowing how to deconstruct the magic is also very useful so you know how the sleight of hand has taken place.