[flagged]
[flagged]
[flagged]
Ruby's exceptional creatures
31–40 of 133 posts
Re: Ruby's exceptional creatures
#32It's painful to see method_missing called out as a first class solution in the first creature https://www.exceptionalcreatures.com/bestiary/NoMethodError.... . "Practical Ruby" has three chapters dedicated to method_missing. "define_method" is more common these days and also painful to see. Ruby gets a lot of criticism for embracing magic and indirection ("Ruby, the bad parts of Perl"). It has some good parts (no fun…
Respectfully mostly disagree. Ruby is full of sharp knives. Other languages have dull knives. Writing code without thinking will cut you either way. Things like method missing are exactly the right solution for a certain set of problems. If used thoughtfully, they’re amazing. If used thoughtlessly, bloody mess. But this is true in every language.
Calling method_missing a sharp knife is like calling GOTO a sharp knife
Re: Ruby's exceptional creatures
#33It's painful to see method_missing called out as a first class solution in the first creature https://www.exceptionalcreatures.com/bestiary/NoMethodError.... . "Practical Ruby" has three chapters dedicated to method_missing. "define_method" is more common these days and also painful to see. Ruby gets a lot of criticism for embracing magic and indirection ("Ruby, the bad parts of Perl"). It has some good parts (no fun…
One rule I try to go by, and I feel like this should be a pretty moderate take but isn't actually that commonly stated: If we're talking about Rails at least, then meta-programming/magic/indirection, all that should be very rare in application code. It makes sense sometimes in more abstract libraries, where you have to handle flexible problems, but in application code it's really worthwhile to just be straightforward…
Every Rails app I’ve ever been introduced to had layers upon layers of “before_filter” and “after_filter”, deeply nested into 6+ subclasses of stuff. Whether or not this “should” or “should not” be in application code is beside the reality that it absolutely is all over application code. Makes it a fucking nightmare to debug.
Re: Ruby's exceptional creatures
#34As a non-ruby developer I see things like this and get jealous of ruby developers.
Re: Ruby's exceptional creatures
#35Re: Ruby's exceptional creatures
#36[flagged]
[deleted]
Re: Ruby's exceptional creatures
#37It's painful to see method_missing called out as a first class solution in the first creature https://www.exceptionalcreatures.com/bestiary/NoMethodError.... . "Practical Ruby" has three chapters dedicated to method_missing. "define_method" is more common these days and also painful to see. Ruby gets a lot of criticism for embracing magic and indirection ("Ruby, the bad parts of Perl"). It has some good parts (no fun…
Respectfully mostly disagree. Ruby is full of sharp knives. Other languages have dull knives. Writing code without thinking will cut you either way. Things like method missing are exactly the right solution for a certain set of problems. If used thoughtfully, they’re amazing. If used thoughtlessly, bloody mess. But this is true in every language.
But we’ve learned over the decades that footguns should usually be avoided and discouraged rather than made easy to use like Ruby does. There’s a reason we aren’t writing GOTOs anymore, GC is a thing in all but the most performance-critical situations, and static typing is gradually winning.
Re: Ruby's exceptional creatures
#38Ruby is a good gateway to programming, better than C, C++, Java, Python,...
Re: Ruby's exceptional creatures
#39Earlier quoted context omitted.
One rule I try to go by, and I feel like this should be a pretty moderate take but isn't actually that commonly stated: If we're talking about Rails at least, then meta-programming/magic/indirection, all that should be very rare in application code. It makes sense sometimes in more abstract libraries, where you have to handle flexible problems, but in application code it's really worthwhile to just be straightforward…
Every Rails app I’ve ever been introduced to had layers upon layers of “before_filter” and “after_filter”, deeply nested into 6+ subclasses of stuff. Whether or not this “should” or “should not” be in application code is beside the reality that it absolutely is all over application code. Makes it a fucking nightmare to debug.
Oh yeah, I guess it's better to limit the use of that. But I actually don't count using those as metaprogramming. It's just part of the framework, and you have to know about those features. Rails has a lot of magic and I think a lot of it is annoying and unnecessary. Using those features is one thing, but defining your own is too far imo, unless you're making a library.
Re: Ruby's exceptional creatures
#40Earlier quoted context omitted.
Respectfully mostly disagree. Ruby is full of sharp knives. Other languages have dull knives. Writing code without thinking will cut you either way. Things like method missing are exactly the right solution for a certain set of problems. If used thoughtfully, they’re amazing. If used thoughtlessly, bloody mess. But this is true in every language.
Where other languages have footguns, I've often described Ruby as offering footchainsaws, while tempting you to juggle them for fun. Far more damaging if you aim it at the wrong thing, but also far better at cutting down things that stand in your way. I think it's the most enjoyable language I've used. With care and feeding it's amazing. I would absolutely not want to use it in a large company, that would be a walkin…
Yes, I want to highlight what you say about large companies. ruby really shines, I think, if you are a solo dev or a small team, where everybody is on the same page and the codebase is completely understood. It is also good for libraries with a clear focus. For larger projects, it might work too, but you would need some good culture of "keep it simple" around it. A few ego-trips of supposedly smart devs and things can get hard to understand and hard to work with fast.