3 ms·

>There is no magic in Rails, it's just Ruby code In the context of dynamic languages, "magic" does not mean someone casting spells. Of course it is just ruby

>There is no magic in Rails, it's just Ruby code In the context of dynamic languages, "magic" does not mean someone casting spells. Of course it is just ruby code. It is magic ruby code. Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware. Pointing out that doing really bad things like this is bad is no more transparently self-serving that you claiming "oh rails is totally fine and doing stupid shit is cool because its not really magic". Yes, it is a systemic fundamental flaw in the framework. The entire framework is built from the ground up on the idea that doing this kind of nonsense is good.

adamors 14y ago
> Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up? Plus if you want to know exactly how everything is done, you can see it for yourself. As we all know Rails is open source and the code is perfectly readable for anyone that knows Ruby.
- tedunangst 14y ago
  I want my framework to do the boring stuff I don't want to do myself. That doesn't imply I want it running off and doing other things I don't even know about.
- papsosouid 14y ago
  No, that is not the point of a framework at all. I am absolutely shocked that you would present it as though the options are "blindly do stuff automagically" vs "write everything from scratch". A framework is more useful if I control it, not less useful. If you want to give me the ability to parse yaml from GET params, then give me a parse_yaml_from_get_params_with_a_really_long_rails_function_name() function to do it with. Don't just do it all the time in case I might want it. You don't need to automatically run a feature in order for the feature to exist, be used, and be useful.
- vidarh 14y ago
  First of all let me make it clear that I'm not against all "magic", but let me address this: > But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up? There is a vast difference between a framework that does stuff for you when you explicitly ask it to, and where what happens is fairly transparent, and a framework that does stuff for you because of code that without knowledge of the framework looks fairly "inert". E.g. calling methods to define attributes and attribute-accessors on a class that maps to a database is not magic (though depending on how extensive, you might argue parts of what a specific ORM does in that case is): The code makes it plain that something will happen, and unless the naming of the method is atrocious, a developer will have a good shot at guessing roughly what from the code itself. You can make a framework that does a lot for a developer while still being explicit like this. Automatically defining attributes pulled from the database based just on including a module, or inheritance, on the other hand, is well into "magic" territory: Not only might it not be clear it's going to be pulling stuff from the database and define lots of attributes for you, you don't know what it will define at all without looking at a schema that might not even be available together with the code, and that might change independent of the code. It's not an either-or, but a sliding scale, and what is magic to some will be plain and obvious to others (the Arthur C. Clarke quote springs to mind). E.g. "everyone" who knows Active Record will know at least the basics of what Active Record will do to your class, and so won't be surprised by most of the method that to another seemingly magically materialize on it. The trade-off is how far you go before the surprises to your target audience become too many.
- kyllo 14y ago
  >As we all know Rails is open source and the code is perfectly readable for anyone that knows Ruby. I beg to differ on the readability of the Rails source code. Even for someone with a strong command of Ruby, there are a lot of layers of abstraction, functions that call other functions that call other functions, and subclasses of subclasses of subclasses, spread across many different files in different places in the folder/project structure. It's quite difficult to figure out what is actually going on when you look under the hood of Rails, because it's complicated to the point where it's "indistinguishable from magic" until you have spend a lot of time with it.
  - alinajaf 14y ago
    Can you point me to a concrete example of this? Rails as a codebase is decoupled reasonably well. As long as I take it in chunks, I can understand control flow through it reasonably well, and I probably have less ruby experience than you do.

adamors 14y ago

> Code which is executing a whole bunch of stuff behind the scenes without the user of that code (the web developer) being aware But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up? Plus if you want to know exactly how everything is done, you can see it for yourself. As we all know Rails is open source and the code is perfectly readable for anyone that knows Ruby.

tedunangst 14y ago
I want my framework to do the boring stuff I don't want to do myself. That doesn't imply I want it running off and doing other things I don't even know about.
papsosouid 14y ago
No, that is not the point of a framework at all. I am absolutely shocked that you would present it as though the options are "blindly do stuff automagically" vs "write everything from scratch". A framework is more useful if I control it, not less useful. If you want to give me the ability to parse yaml from GET params, then give me a parse_yaml_from_get_params_with_a_really_long_rails_function_name() function to do it with. Don't just do it all the time in case I might want it. You don't need to automatically run a feature in order for the feature to exist, be used, and be useful.
vidarh 14y ago
First of all let me make it clear that I'm not against all "magic", but let me address this: > But isn't this the whole point of a framework? That stuff gets done for you so you don't have to write everything from the ground up? There is a vast difference between a framework that does stuff for you when you explicitly ask it to, and where what happens is fairly transparent, and a framework that does stuff for you because of code that without knowledge of the framework looks fairly "inert". E.g. calling methods to define attributes and attribute-accessors on a class that maps to a database is not magic (though depending on how extensive, you might argue parts of what a specific ORM does in that case is): The code makes it plain that something will happen, and unless the naming of the method is atrocious, a developer will have a good shot at guessing roughly what from the code itself. You can make a framework that does a lot for a developer while still being explicit like this. Automatically defining attributes pulled from the database based just on including a module, or inheritance, on the other hand, is well into "magic" territory: Not only might it not be clear it's going to be pulling stuff from the database and define lots of attributes for you, you don't know what it will define at all without looking at a schema that might not even be available together with the code, and that might change independent of the code. It's not an either-or, but a sliding scale, and what is magic to some will be plain and obvious to others (the Arthur C. Clarke quote springs to mind). E.g. "everyone" who knows Active Record will know at least the basics of what Active Record will do to your class, and so won't be surprised by most of the method that to another seemingly magically materialize on it. The trade-off is how far you go before the surprises to your target audience become too many.
kyllo 14y ago
>As we all know Rails is open source and the code is perfectly readable for anyone that knows Ruby. I beg to differ on the readability of the Rails source code. Even for someone with a strong command of Ruby, there are a lot of layers of abstraction, functions that call other functions that call other functions, and subclasses of subclasses of subclasses, spread across many different files in different places in the folder/project structure. It's quite difficult to figure out what is actually going on when you look under the hood of Rails, because it's complicated to the point where it's "indistinguishable from magic" until you have spend a lot of time with it.
- alinajaf 14y ago
  Can you point me to a concrete example of this? Rails as a codebase is decoupled reasonably well. As long as I take it in chunks, I can understand control flow through it reasonably well, and I probably have less ruby experience than you do.