5 ms·

After having worked with rails for coming on two years now, it's been a love-hate relationship. The short version: your first few apps will be pretty horrible b

After having worked with rails for coming on two years now, it's been a love-hate relationship. The short version: your first few apps will be pretty horrible but the more you know about the framework, the better they get. Admittedly, the same could be said about any framework. Also, don't be afraid of the black magic, read the source, its just plain old ruby down there.

swombat 16y ago
Agreed. "Magic" is just another word for "I don't understand how they did this". Whenever you meet "magic", you should dig into the code until you do understand "how they did this".
- nerfhammer 16y ago
  I think why magic looks like magic is because there is no obvious explanation for what it's doing, e.g. something in rails somewhere is using reflection to pick up something based only on a naming convention. You have to more or less know about the naming convention in advance in order to know where to look up more about what it's doing. I think some people feel like rails went a little overboard on things like this.
- xiongchiamiov 16y ago
  I think James Bennett's post on magic is interesting: http://www.b-list.org/weblog/2009/jul/23/magic/ http://www.b-list.org/weblog/2009/jul/23/magic/ In particular, there is a comment[0] that I think is particularly worth reading: There are two different definitions of magic in play here. 1. The use of advanced language features in a manner that might be confusing to a novice programmer. 2. The use of ANY language feature to automate some process that a programmer would not expect to be automated. I am of the belief that the second is the proper definition, which is something that is not usually solved by reading sourcecode, as the question is "Why?", rather than "What?" or "How?". [0]: http://www.b-list.org/weblog/2009/jul/23/magic/#c118751 http://www.b-list.org/weblog/2009/jul/23/magic/#c118751
  - Periodic 16y ago
    It's like the reason I advocate comments though I know a few people who believe the code's behavior should be self-evident. The real question for any interesting application is not the how or the what, but the why. You can't answer the why just by reading the code. You need to understand the problem and the trade-offs, and for that you need comments and documentation.
- enanoretozon 16y ago
  Almost every time I dig to find out how the magic works, much like the performance art, I end up disappointed, scared or both.
- snprbob86 16y ago
  Although true in this case, that was not my intended meaning. A few of the "magic" things I've encountered thus far in Rails can be easily demystified by looking at the code. However, like magic shows, knowing how the trick is done doesn't mean that I can't enjoy the spectacle of it. The execution of the trick is every bit as important as the mystery. I'd put forth this definition, which applies to both magical performances and magical code: Magic is taking something which is traditionally considered impossible and making it look effortless. Some magic tricks really are effortless. Others require painstaking setup and flawless execution. Same thing with code, but only the former is really valuable in production systems.

swombat 16y ago

Agreed. "Magic" is just another word for "I don't understand how they did this". Whenever you meet "magic", you should dig into the code until you do understand "how they did this".

nerfhammer 16y ago
I think why magic looks like magic is because there is no obvious explanation for what it's doing, e.g. something in rails somewhere is using reflection to pick up something based only on a naming convention. You have to more or less know about the naming convention in advance in order to know where to look up more about what it's doing. I think some people feel like rails went a little overboard on things like this.
xiongchiamiov 16y ago
I think James Bennett's post on magic is interesting: http://www.b-list.org/weblog/2009/jul/23/magic/ http://www.b-list.org/weblog/2009/jul/23/magic/ In particular, there is a comment[0] that I think is particularly worth reading: There are two different definitions of magic in play here. 1. The use of advanced language features in a manner that might be confusing to a novice programmer. 2. The use of ANY language feature to automate some process that a programmer would not expect to be automated. I am of the belief that the second is the proper definition, which is something that is not usually solved by reading sourcecode, as the question is "Why?", rather than "What?" or "How?". [0]: http://www.b-list.org/weblog/2009/jul/23/magic/#c118751 http://www.b-list.org/weblog/2009/jul/23/magic/#c118751
- Periodic 16y ago
  It's like the reason I advocate comments though I know a few people who believe the code's behavior should be self-evident. The real question for any interesting application is not the how or the what, but the why. You can't answer the why just by reading the code. You need to understand the problem and the trade-offs, and for that you need comments and documentation.
enanoretozon 16y ago
Almost every time I dig to find out how the magic works, much like the performance art, I end up disappointed, scared or both.
snprbob86 16y ago
Although true in this case, that was not my intended meaning. A few of the "magic" things I've encountered thus far in Rails can be easily demystified by looking at the code. However, like magic shows, knowing how the trick is done doesn't mean that I can't enjoy the spectacle of it. The execution of the trick is every bit as important as the mystery. I'd put forth this definition, which applies to both magical performances and magical code: Magic is taking something which is traditionally considered impossible and making it look effortless. Some magic tricks really are effortless. Others require painstaking setup and flawless execution. Same thing with code, but only the former is really valuable in production systems.