4 ms·

> that dynamism is precisely why I use Ruby Could you elaborate? I've never felt like I really needed a dynamic language but that might be because among dynami

by rifung 10y ago

> that dynamism is precisely why I use Ruby Could you elaborate? I've never felt like I really needed a dynamic language but that might be because among dynamic languages I only know Python and a little Javascript. I still use them, but I don't feel like I really take advantage of the fact they are dynamic.

eropple 10y ago
I don't need a dynamic language. But for many tasks, I want one. For others, I have languages that are, to be honest, more expressive than Crystal--C++ or C# or Kotlin or Scala. I would not attack Ruby problems in those languages, nor would I in Crystal. Don't get me wrong: it's more expressive than Go, so that crowd should totally pile on Crystal and make it better 'cause I'd rather have to deal with Crystal, which while I think it's not really anything special I don't think it's bad, and to me that's a big step up. But they won't, so, whatever. Anyway, moving on. `include`, `extend`, and `prepend` are used a lot in Ruby because the very mutable nature of class definitions allows for powerful metaprogramming without having to do a lot of work--and all are, and can't not be, runtime-evaluated. I regularly build objects in Ruby out of dynamically generated mixins reliant on runtime behavior. As do most people. Consider ActiveRecord (which I don't care for, but it's a good example). You create a class that inherits from ActiveRecord::Base--and, at runtime, it queries the database and builds a set of methods for the class based on the schema of its table. Or something like dry-struct, which evaluates, at runtime, a set of attribute specifications and dynamically creates the API for accessing it (as well as validators, etc., which can be programmatically devised). And that's not even taking into account a plugin architecture that is functionally "require this file" and being able to interpret it at runtime; Exor, linked above, is a lot of pretty finicky work to simulate a worse version of that in C#. Or the general usefulness and value of monkey-patching in a lot of contexts. Oh, and I can drop `binding.pry` into any spot in my code and have a REPL in which I can define methods on existing classes, inline, and build functionality that I can then dump out into my editor. Compiled languages that do that are, er, rare. (JRebel and hot reloading isn't as nice as just doing it.) Ruby isn't the perfect tool. But when I want to write a little code to do a lot and don't have many other concerns, that's why I go to it. That's why something like Chef uses it instead of the programming mistake of 2014-2016 (using YAML for everything). Because nothing code-related expresses intent better than code itself, and Ruby is built around making that easy for me when I can think about classes and modules as things that exist rather than immutable blueprints off in the ether.

by rifung 10y ago

eropple 10y ago

I don't need a dynamic language. But for many tasks, I want one. For others, I have languages that are, to be honest, more expressive than Crystal--C++ or C# or Kotlin or Scala. I would not attack Ruby problems in those languages, nor would I in Crystal. Don't get me wrong: it's more expressive than Go, so that crowd should totally pile on Crystal and make it better 'cause I'd rather have to deal with Crystal, which while I think it's not really anything special I don't think it's bad, and to me that's a big step up. But they won't, so, whatever. Anyway, moving on. `include`, `extend`, and `prepend` are used a lot in Ruby because the very mutable nature of class definitions allows for powerful metaprogramming without having to do a lot of work--and all are, and can't not be, runtime-evaluated. I regularly build objects in Ruby out of dynamically generated mixins reliant on runtime behavior. As do most people. Consider ActiveRecord (which I don't care for, but it's a good example). You create a class that inherits from ActiveRecord::Base--and, at runtime, it queries the database and builds a set of methods for the class based on the schema of its table. Or something like dry-struct, which evaluates, at runtime, a set of attribute specifications and dynamically creates the API for accessing it (as well as validators, etc., which can be programmatically devised). And that's not even taking into account a plugin architecture that is functionally "require this file" and being able to interpret it at runtime; Exor, linked above, is a lot of pretty finicky work to simulate a worse version of that in C#. Or the general usefulness and value of monkey-patching in a lot of contexts. Oh, and I can drop `binding.pry` into any spot in my code and have a REPL in which I can define methods on existing classes, inline, and build functionality that I can then dump out into my editor. Compiled languages that do that are, er, rare. (JRebel and hot reloading isn't as nice as just doing it.) Ruby isn't the perfect tool. But when I want to write a little code to do a lot and don't have many other concerns, that's why I go to it. That's why something like Chef uses it instead of the programming mistake of 2014-2016 (using YAML for everything). Because nothing code-related expresses intent better than code itself, and Ruby is built around making that easy for me when I can think about classes and modules as things that exist rather than immutable blueprints off in the ether.