4 ms·

I feel this way sometimes about using Rails. It's not the same thing as visual studio but there is a nagging feeling of dependence that goes along with writing

I feel this way sometimes about using Rails. It's not the same thing as visual studio but there is a nagging feeling of dependence that goes along with writing a webapp without knowing how a server works, why all the generated code looks like it does, or even knowing what TCP/IP is. ( I know the IP stands for Internet Protocol).

silentbicycle 16y ago
The problem is when handling all those lower layers gets brushed off as "magic", rather than just recognized as a big pile of tedious details. Learn about servers. Writing a simple webserver really isn't hard, and it will teach you a lot about HTTP performance tuning.
1337p337 16y ago
And if you decide to delve into the details of Rails' implementation, you're often greeted with 100-line string evals and incomprehensible hacks. I doubt this effect was the intention, but it made me cargo-cult a lot when I was doing Rails full-time because I was afraid of finding out what was really going on. I was technically writing Ruby, but Rails never felt like Ruby to me.
- jpr 16y ago
  It seems that Rails is doing something horribly wrong. There should be no reason to use code-generating or evaluate strings in a dynamic language.
  - 1337p337 16y ago
    I (at the risk of getting horribly off-topic) attribute this to Rails' origins, namely a team that moved to Ruby from PHP, and brought too much PHP with them. Not to take a position on PHP itself, but it's a very different language, and what makes sense in PHP can be very ugly in Ruby. Huge, ugly string evals (just one of the horrors lurking in the Rails codebase; their copious abuse of BasicObject comes to mind) are bad enough, but the code-generating is responsible for most Rails applications, too. The inherent ugliness of generating application code from templates in Ruby is one thing, but it would be ugly in any object-oriented language: you use inheritance, and defer to the superclass (or, in languages that have mixins or prototypical inheritance, you add a class/exemplar to defer to). You don't take the behavior you expect these objects to exhibit, stuff it into a template, and write a script that fills in the blanks and dumps the result into a file. It's automated copy-paste, an optimized version of something that was a bad idea to begin with. (I've heard good things about Rails 3.0, but I've not looked. My heart has been broken too many times, and I don't see Yehuda Katz as substantially more insightful than DHH.)
    - davnola 16y ago
      > copious abuse of BasicObject Used a total of 4 times in the 2.3.10 codebase. As for code-generation, I think you misunderstand their role in Rails. Can I ask you, in your editor of choice do you have any kind of snippet/template functionality (e.g. yas for emacs)? Same deal.
      - 1337p337 16y ago
        > Used a total of 4 times in the 2.3.10 codebase. The number of times the string "BasicObject" or "BlankSlate" shows up in the codebase is not representative of the times an instance of a class that inherits from this class shows up in data I am passing around. And the number of times an instance shows up is not representative of the pain I have gone through with these misapplied patterns. Between these, HashWithIndifferentAccess, the liberal use of :nodoc: tags (to the non-Rubyist: these--distressingly--suppress the API documentation generator from generating documentation for a given piece of code), and other "quirks" of the framework, I have had a hell of a time debugging in Rails.[1] > I think you misunderstand their role in Rails. I seriously doubt that, but I'm more than willing to hear what they are if not essentially copypasta generated for developers to tweak. It's a case where inheritance and mixins would have done nicely and resulted in cleaner code. If you don't believe me, try taking one of these generated controllers, stuffing it into lib/, renaming it appropriately ("GenericController", for example), and having most of your controllers inherit from it instead of ActionController::Base directly. The result is a lot of mostly empty controllers where behavior that varies from the GenericController is easy to spot, because it's the only behavior that needs to be specified. > in your editor of choice do you have any kind of snippet/template functionality As bloated as my favorite editor is, I am sure there is some functionality like that, but I don't know where it is or how to use it. Not that I don't generate code ever; it's a fine technique for a dirty hack, a script that needs to just be done and cleanliness be damned. It is not how I would engineer an application that I expected to have to maintain, and it's undesirable for that to be the main pattern of development in a framework. 1. Please do not think that this is because I am new to Ruby or to Rails. I have been doing Ruby professionally since before Rails was released, and spent a few years doing Rails almost exclusively, starting before Mongrel came out and our choices were WEBrick or FastCGI. I still occasionally have to interact with Rails codebases, although I have been trying to avoid it for a long time.
- davnola 16y ago
  I don't recognise the current Rails codebase from this comment. There's certainly nothing incomprehensible about it if you grok common Ruby metaprogramming idioms. I wish the idea of "Ruby magic" would die in flames!
  - 1337p337 16y ago
    It's not that I don't understand "Ruby magic" or "metaprogramming"; it's that the Rails codebase is spaghetti. > I wish the idea of "Ruby magic" would die in flames! Me, too. I think Giles Bowkett had an article on this; it was the only article on his blog that I liked. Superstitions and fear about Ruby's higher-level features remind me of people that are afraid of macros in Lisp or function pointers in C.
    - epochwolf 16y ago
      I found this to be true years ago. Rails 1.2 had really gnarly stack traces. I have yet to see Rails 3 throw up in such creative ways. The current codebase is far from the spaghetti you claim. Active Record is probably the closest to it but it's been greatly changed internally from the original.

silentbicycle 16y ago

The problem is when handling all those lower layers gets brushed off as "magic", rather than just recognized as a big pile of tedious details. Learn about servers. Writing a simple webserver really isn't hard, and it will teach you a lot about HTTP performance tuning.

1337p337 16y ago

And if you decide to delve into the details of Rails' implementation, you're often greeted with 100-line string evals and incomprehensible hacks. I doubt this effect was the intention, but it made me cargo-cult a lot when I was doing Rails full-time because I was afraid of finding out what was really going on. I was technically writing Ruby, but Rails never felt like Ruby to me.

jpr 16y ago
It seems that Rails is doing something horribly wrong. There should be no reason to use code-generating or evaluate strings in a dynamic language.
- 1337p337 16y ago
  I (at the risk of getting horribly off-topic) attribute this to Rails' origins, namely a team that moved to Ruby from PHP, and brought too much PHP with them. Not to take a position on PHP itself, but it's a very different language, and what makes sense in PHP can be very ugly in Ruby. Huge, ugly string evals (just one of the horrors lurking in the Rails codebase; their copious abuse of BasicObject comes to mind) are bad enough, but the code-generating is responsible for most Rails applications, too. The inherent ugliness of generating application code from templates in Ruby is one thing, but it would be ugly in any object-oriented language: you use inheritance, and defer to the superclass (or, in languages that have mixins or prototypical inheritance, you add a class/exemplar to defer to). You don't take the behavior you expect these objects to exhibit, stuff it into a template, and write a script that fills in the blanks and dumps the result into a file. It's automated copy-paste, an optimized version of something that was a bad idea to begin with. (I've heard good things about Rails 3.0, but I've not looked. My heart has been broken too many times, and I don't see Yehuda Katz as substantially more insightful than DHH.)
  - davnola 16y ago
    > copious abuse of BasicObject Used a total of 4 times in the 2.3.10 codebase. As for code-generation, I think you misunderstand their role in Rails. Can I ask you, in your editor of choice do you have any kind of snippet/template functionality (e.g. yas for emacs)? Same deal.
    - 1337p337 16y ago
      > Used a total of 4 times in the 2.3.10 codebase. The number of times the string "BasicObject" or "BlankSlate" shows up in the codebase is not representative of the times an instance of a class that inherits from this class shows up in data I am passing around. And the number of times an instance shows up is not representative of the pain I have gone through with these misapplied patterns. Between these, HashWithIndifferentAccess, the liberal use of :nodoc: tags (to the non-Rubyist: these--distressingly--suppress the API documentation generator from generating documentation for a given piece of code), and other "quirks" of the framework, I have had a hell of a time debugging in Rails.[1] > I think you misunderstand their role in Rails. I seriously doubt that, but I'm more than willing to hear what they are if not essentially copypasta generated for developers to tweak. It's a case where inheritance and mixins would have done nicely and resulted in cleaner code. If you don't believe me, try taking one of these generated controllers, stuffing it into lib/, renaming it appropriately ("GenericController", for example), and having most of your controllers inherit from it instead of ActionController::Base directly. The result is a lot of mostly empty controllers where behavior that varies from the GenericController is easy to spot, because it's the only behavior that needs to be specified. > in your editor of choice do you have any kind of snippet/template functionality As bloated as my favorite editor is, I am sure there is some functionality like that, but I don't know where it is or how to use it. Not that I don't generate code ever; it's a fine technique for a dirty hack, a script that needs to just be done and cleanliness be damned. It is not how I would engineer an application that I expected to have to maintain, and it's undesirable for that to be the main pattern of development in a framework. 1. Please do not think that this is because I am new to Ruby or to Rails. I have been doing Ruby professionally since before Rails was released, and spent a few years doing Rails almost exclusively, starting before Mongrel came out and our choices were WEBrick or FastCGI. I still occasionally have to interact with Rails codebases, although I have been trying to avoid it for a long time.
davnola 16y ago
I don't recognise the current Rails codebase from this comment. There's certainly nothing incomprehensible about it if you grok common Ruby metaprogramming idioms. I wish the idea of "Ruby magic" would die in flames!
- 1337p337 16y ago
  It's not that I don't understand "Ruby magic" or "metaprogramming"; it's that the Rails codebase is spaghetti. > I wish the idea of "Ruby magic" would die in flames! Me, too. I think Giles Bowkett had an article on this; it was the only article on his blog that I liked. Superstitions and fear about Ruby's higher-level features remind me of people that are afraid of macros in Lisp or function pointers in C.
  - epochwolf 16y ago
    I found this to be true years ago. Rails 1.2 had really gnarly stack traces. I have yet to see Rails 3 throw up in such creative ways. The current codebase is far from the spaghetti you claim. Active Record is probably the closest to it but it's been greatly changed internally from the original.