4 ms·

"The reason why you cannot recreate a Rails clone is because Rails works basically by redefining everything at runtime, over and over again ... the whole Ruby l

by dan00 15y ago

"The reason why you cannot recreate a Rails clone is because Rails works basically by redefining everything at runtime, over and over again ... the whole Ruby language is built from the ground up on redefining classes (for the "class" construct, defining new classes in case they don't exist, that's just a side-effect)." I don't think that runtime overwritting and creating of classes is something good per se. It's just better than code generation tools in Java. Well, monkey patching is even worse. Why is this even needed? What is missing in the programming language to be able to describe these things without the need of dynamic code generation?

bad_user 15y ago
Well, monkey patching is even worse. That's why in my initial comment I talked about style. If you haven't worked with a given style, you're prone to harsh judgments and mentalities such as this one. Redefining classes/methods/interfaces at runtime works great for a lot of people ;) Why is this even needed? In case you're working in Java, you may not realize it, but the libraries you're using are probably doing it. The real difference is in these cases, say for example aspect-oriented programming or dependency injection or all the other buzzwords you had to learn for Java in the last 10 years -- which require big-ass, bloated, incomplete and extremely buggy libraries -- in Ruby/Python are as natural as "Hello World!". To put it simpler - dynamic languages allow you to treat code as data and to mutate it in however ways you like. Catching bugs at compile-times is not just about syntax-related errors or checking if some object responds to some method call. If you really want to catch errors at compile-time, you have to dig a whole lot deeper than that, which more evolved static languages are kind of doing (mostly by forcing you to model your data-structures in a certain way, such that the language can understand its purpose and mathematically prove stuff). But then again, Java is not a representative of static-languages, mostly because Java is a fucked-up hybrid, having all the disadvantages of static-types with none of the advantages. When talking about static types, you really should be talking about what Haskell can do. And even Haskell has limits that dynamic languages don't, that's why it comes with its own macro-language to alleviate that.
- dan00 15y ago
  Why do you think I'm advocating Java, because the word Java is contained in my post? I know C++, Python, Common Lisp and Haskell pretty good. I asked serious questions why problems are solved in the way they're solved, which language features are missing to solve it in another way. The current way might work for you, but considering bigger projects and human fallibility, I don't think it will scale that well. Restrictions aren't per se something bad. Considering your own limitations, they can empower you to handle even harder and more complex problems.
- smcj 15y ago
  "works great" doesn't necessarily exclude "it's a stupid thing to do". I wonder how things like concurrency are expected to work, if no single line of code can be sure that things it expects will exist at runtime. Or maybe exists every 5 seconds for 3 seconds. It is an optimization nightmare (proven by the abhorrent performance Ruby exhibits). Even the Ruby "developers" have understood that monkey-patching is bad and decided to do something against it.

by dan00 15y ago

bad_user 15y ago

Well, monkey patching is even worse. That's why in my initial comment I talked about style. If you haven't worked with a given style, you're prone to harsh judgments and mentalities such as this one. Redefining classes/methods/interfaces at runtime works great for a lot of people ;) Why is this even needed? In case you're working in Java, you may not realize it, but the libraries you're using are probably doing it. The real difference is in these cases, say for example aspect-oriented programming or dependency injection or all the other buzzwords you had to learn for Java in the last 10 years -- which require big-ass, bloated, incomplete and extremely buggy libraries -- in Ruby/Python are as natural as "Hello World!". To put it simpler - dynamic languages allow you to treat code as data and to mutate it in however ways you like. Catching bugs at compile-times is not just about syntax-related errors or checking if some object responds to some method call. If you really want to catch errors at compile-time, you have to dig a whole lot deeper than that, which more evolved static languages are kind of doing (mostly by forcing you to model your data-structures in a certain way, such that the language can understand its purpose and mathematically prove stuff). But then again, Java is not a representative of static-languages, mostly because Java is a fucked-up hybrid, having all the disadvantages of static-types with none of the advantages. When talking about static types, you really should be talking about what Haskell can do. And even Haskell has limits that dynamic languages don't, that's why it comes with its own macro-language to alleviate that.

dan00 15y ago
Why do you think I'm advocating Java, because the word Java is contained in my post? I know C++, Python, Common Lisp and Haskell pretty good. I asked serious questions why problems are solved in the way they're solved, which language features are missing to solve it in another way. The current way might work for you, but considering bigger projects and human fallibility, I don't think it will scale that well. Restrictions aren't per se something bad. Considering your own limitations, they can empower you to handle even harder and more complex problems.
smcj 15y ago
"works great" doesn't necessarily exclude "it's a stupid thing to do". I wonder how things like concurrency are expected to work, if no single line of code can be sure that things it expects will exist at runtime. Or maybe exists every 5 seconds for 3 seconds. It is an optimization nightmare (proven by the abhorrent performance Ruby exhibits). Even the Ruby "developers" have understood that monkey-patching is bad and decided to do something against it.