Aside from being cute, and maybe harking back to why’s guide; I like how this feels like it aids in understanding. Each illustration provides character that helps aid in memorizing or creating a mental landscape of the exceptions.
Theres probably a lot of documentation that could be aided by illustrations like this along the lines of analogy and metaphor. Aside from making the process of reading documentation more fun, it probably helps differentiate long and complex documentation that otherwise might blur together.
I don't appreciate how it seems like an elaborate ad though: Every error has a link to the paid service they're selling , with the error/exception "Enemies" list as their product
15 years ago I would have agreed. Today, Python is a "gateway" to programming that is also the real thing.
It's like one of those old languages designed for beginners to learn coding... and then you can continue to use the same language for your entire professional career as a software engineer, to build just about any production-ready application.
Ruby is a beautiful language, but unless you are going to be working with Rails, it's not a very practical language to build something in. And I don't think telling a beginner "just learn Ruby for now, but once you're actually ready to write your first useful program, you're probably going to have to learn another language" is very motivating.
I don't know what it is about Ruby that turns every HN thread that mentions it into a flame war about how it's not the perfect language. People don't do this with other languages. What gives?
I think python is the only language where the inevitable flamewar isn't about the language itself (it is instead about static vs dynamic typing). Java might be in this list too (usually the war is about OOP in general, but there's plenty of criticism levied at Java itself).
Discussions about C devolve into a religious war about simplicity and portability vs safety and an inadequate standard library.
Discussions about C++ devolve into a religious war about memory safety, bloat, developer competency, UB, and more.
Discussions about Haskell devolve into a religious war about powerful type systems and language constructs vs performance concerns, development complexity, and "endofunctors, lol."
Discussions about JS devolve into a religious war about npm, web dev in general, "== vs === lol" and more.
Discussions about Rust... oh boy.
In my experience, most discussions of specific components of languages inevitably spill into these broad and neverending religious wars.
I think any language with big fans will inspire equally motivated critics. Especially if the critics believe the accolades are undeserved.
You can see that in Go. It was a hugely hyped language, backed by Google, but without a lot of wishlist items that C++/Java/Python/Ruby/etc developers would have liked.
You can see that with Rust. There is the “rewrite everything in rust” crowd, which inspires anti-rust people to speak up.
I find it crazy how much criticism Rust, Go, Ruby, etc receive when Python has such glaring flaws. From the 2-to-3 migration, to package management. The consensus seems to be that’s just the cost of doing business.
By the way, I’m a Python developer. I don’t hate Ruby. But it seems like most Ruby fans love the elegance and consistency of its design, whereas that never resonated with me. E.g calling obj.length rather then len(obj) is surely more elegant. I never really cared though?
I guess I just find it interesting how some languages cons are excused while others aren’t. And how people can be drawn to some languages while others hate them.
There is a significant anti-Ruby sentiment in the tech industry right now, especially in certain fields like InfoSec, that is being pushed by a very vocal subset of the community. Whenever they see Ruby come up, they will try pushing the meme that Ruby is dead/dying/irrelevant and cite TIOBE; despite Ruby developers continuing to release new libraries, frameworks, and tooling. Or they will claim no popular websites use Ruby; apparently GitHub, LinkedIn, and AirBnB are not popular enough? Or claim MetaSploit is the only security tool written in Ruby; off the top of my head I can think of BeFF, CeWL, Evil-WinRM, and Ronin. Or claim no company uses or supports Ruby; GitHub, Shopify, Stripe all use and support Ruby. Or they will derail any positive discussion about Ruby into some intractable debate about Static vs Dynamic Typing, GC, interpretive languages, etc; even though many of the arguments against Ruby can equally be applied to Python, and yet there's no similar criticism of Python. It's really annoying and inconsistent.
It'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 function colors, for example), but the ecosystem is the biggest problem by promoting magic. method_missing is not a good part of Ruby, it's a very bad part that you should only use if you know it's bad _and_ you know you still have to use it. I wish all tutorials would say this. "You can do this with Ruby, but don't, because your coworkers debugging an outage for an hour will hate you once they find out the bug is caused by method_missing".
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.
I definitely prefer Clojure/Elixir-style macros to Ruby’s meta-programming features.
They’re still better than nothing, though. Method-mossing and friends played a critical role in making a framework like Rails possible in Ruby. In contrast, languages like Python and JavaScript just aren’t quite expressive enough to do it. A lot of energy went into attempts over the years, too! At best, something like Sails could get 2/3 off the way there and offer significant advantages on another axis, like making websockets first class.
The page you linked to discusses NoMethodError, which is raised when a method is not found. Among other things it shows how method_missing is involved in searching for a method. Nowhere in the text is it promoted.
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 and verbose.
"but the ecosystem is the biggest problem by promoting magic."
This argument isn't entirely true anymore. The Ruby ecosystem has mostly moved away from meta-programming, and embraced classical OOP. Rubyists now tend to avoid `method_missing` and `const_missing` when possible, and abandoned the craze of making everything a DSL. The most meta-programming that Rubyists still use on a regular basis is defining `self.included` on modules in order to inject other modules. Also, Rubyists have embraced API documentation, such as YARD, in order to document and communicate any "magic" that might exist or occur.
It's not really any different to, say, lisp (which is lauded for its intuitive support of macros) and smalltalk (which is what ruby was directly influenced by).
As a dynamic language, Ruby gives you a lot of tools to create fully expressive code. This is just one aspect of it that you can, but don't have to, use.
method_missing is a tiny offense compared to what was getting popular at one point - creating classes by forking metaclass and injecting methods into... without knowing you're doing so (something IIRC got lost between people there...)
Result was objects that shared no structure, no field
In every language without method_missing or equivalent, people end up writing custom dispatch based on message values sooner or later, sometimes re-implementing full method dispatch, and occasionally a full inheritance mechanism in the process.
If the set of messages you need to handle dynamically is to only ever be small, define_method() is the better choice, but when it is not, I'll take careful use of method_missing over some monstrosity that ends up emulating the same machinery with lots of extra code any day.
If you struggle with debugging due to method_missing, consider reviewing how you debug code, as it wouldn't even make my top ten of debugging challenges in the Ruby code I've worked on in the last 17 years of daily Ruby use.
These days (years) I work mostly in Java and would love to have method_missing or define_method. Of course I can do everything I want without them, but it's not fun.
You keep saying method_missing is "bad" but what exactly is so bad about it?
The main complaint about method_missing has always been the inefficiency. The class hierarchy is walked every single time and only then is method_missing called. The use of define_method is a pretty neat solution to that problem. The method that wasn't found gets defined and it doesn't rely on method_missing again. Like a cache.
If you have incorrect code and are happy programming, you fix your code.
If you have correct code, but are unhappy programming, you do not fix your code.
There is no correct code and Ruby prioritizes your happiness, so you get fixed code and happy programmers, instead of permanently broken code and unhappy programmers.
Reading your comment one would think Ruby is the only programming language with exceptions. In fact, lots of programming languages have them, even PHP.
[+] [-] iammiles|2 years ago|reply
[+] [-] booleandilemma|2 years ago|reply
[+] [-] crazydoggers|2 years ago|reply
Theres probably a lot of documentation that could be aided by illustrations like this along the lines of analogy and metaphor. Aside from making the process of reading documentation more fun, it probably helps differentiate long and complex documentation that otherwise might blur together.
[+] [-] oh_sigh|2 years ago|reply
[+] [-] cHaOs667|2 years ago|reply
[+] [-] revskill|2 years ago|reply
[+] [-] p-e-w|2 years ago|reply
15 years ago I would have agreed. Today, Python is a "gateway" to programming that is also the real thing.
It's like one of those old languages designed for beginners to learn coding... and then you can continue to use the same language for your entire professional career as a software engineer, to build just about any production-ready application.
Ruby is a beautiful language, but unless you are going to be working with Rails, it's not a very practical language to build something in. And I don't think telling a beginner "just learn Ruby for now, but once you're actually ready to write your first useful program, you're probably going to have to learn another language" is very motivating.
[+] [-] wscourge|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] 03b8|2 years ago|reply
[+] [-] typeofnandev|2 years ago|reply
[+] [-] aksh7i|2 years ago|reply
[deleted]
[+] [-] a_gnostic|2 years ago|reply
[+] [-] CatchSwitch|2 years ago|reply
[+] [-] UncleMeat|2 years ago|reply
Discussions about C devolve into a religious war about simplicity and portability vs safety and an inadequate standard library.
Discussions about C++ devolve into a religious war about memory safety, bloat, developer competency, UB, and more.
Discussions about Haskell devolve into a religious war about powerful type systems and language constructs vs performance concerns, development complexity, and "endofunctors, lol."
Discussions about JS devolve into a religious war about npm, web dev in general, "== vs === lol" and more.
Discussions about Rust... oh boy.
In my experience, most discussions of specific components of languages inevitably spill into these broad and neverending religious wars.
[+] [-] materielle|2 years ago|reply
You can see that in Go. It was a hugely hyped language, backed by Google, but without a lot of wishlist items that C++/Java/Python/Ruby/etc developers would have liked.
You can see that with Rust. There is the “rewrite everything in rust” crowd, which inspires anti-rust people to speak up.
I find it crazy how much criticism Rust, Go, Ruby, etc receive when Python has such glaring flaws. From the 2-to-3 migration, to package management. The consensus seems to be that’s just the cost of doing business.
By the way, I’m a Python developer. I don’t hate Ruby. But it seems like most Ruby fans love the elegance and consistency of its design, whereas that never resonated with me. E.g calling obj.length rather then len(obj) is surely more elegant. I never really cared though?
I guess I just find it interesting how some languages cons are excused while others aren’t. And how people can be drawn to some languages while others hate them.
[+] [-] postmodern_mod3|2 years ago|reply
[+] [-] Joker_vD|2 years ago|reply
[+] [-] lupire|2 years ago|reply
[+] [-] pvg|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] PH95VuimJjqBqy|2 years ago|reply
[+] [-] stevebmark|2 years ago|reply
Ruby gets a lot of criticism for embracing magic and indirection ("Ruby, the bad parts of Perl"). It has some good parts (no function colors, for example), but the ecosystem is the biggest problem by promoting magic. method_missing is not a good part of Ruby, it's a very bad part that you should only use if you know it's bad _and_ you know you still have to use it. I wish all tutorials would say this. "You can do this with Ruby, but don't, because your coworkers debugging an outage for an hour will hate you once they find out the bug is caused by method_missing".
[+] [-] RangerScience|2 years ago|reply
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.
[+] [-] AlchemistCamp|2 years ago|reply
They’re still better than nothing, though. Method-mossing and friends played a critical role in making a framework like Rails possible in Ruby. In contrast, languages like Python and JavaScript just aren’t quite expressive enough to do it. A lot of energy went into attempts over the years, too! At best, something like Sails could get 2/3 off the way there and offer significant advantages on another axis, like making websockets first class.
[+] [-] nf3|2 years ago|reply
[+] [-] nomilk|2 years ago|reply
Personally, I've never used method_missing. Might have missed opportunities to write clever code, but I'm super happy being boring and explicit.
Tangentially, I've only used meta programming twice. Both where the alternative was cumbersome, and it was unlikely to cause confusion.
Ruby gives some exotic tools but doesn't force you to use them if you prefer not to.
[+] [-] groggo|2 years ago|reply
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 and verbose.
[+] [-] postmodern_mod3|2 years ago|reply
This argument isn't entirely true anymore. The Ruby ecosystem has mostly moved away from meta-programming, and embraced classical OOP. Rubyists now tend to avoid `method_missing` and `const_missing` when possible, and abandoned the craze of making everything a DSL. The most meta-programming that Rubyists still use on a regular basis is defining `self.included` on modules in order to inject other modules. Also, Rubyists have embraced API documentation, such as YARD, in order to document and communicate any "magic" that might exist or occur.
[+] [-] ljm|2 years ago|reply
As a dynamic language, Ruby gives you a lot of tools to create fully expressive code. This is just one aspect of it that you can, but don't have to, use.
[+] [-] p_l|2 years ago|reply
Result was objects that shared no structure, no field
[+] [-] vidarh|2 years ago|reply
If the set of messages you need to handle dynamically is to only ever be small, define_method() is the better choice, but when it is not, I'll take careful use of method_missing over some monstrosity that ends up emulating the same machinery with lots of extra code any day.
If you struggle with debugging due to method_missing, consider reviewing how you debug code, as it wouldn't even make my top ten of debugging challenges in the Ruby code I've worked on in the last 17 years of daily Ruby use.
[+] [-] tpm|2 years ago|reply
[+] [-] matheusmoreira|2 years ago|reply
The main complaint about method_missing has always been the inefficiency. The class hierarchy is walked every single time and only then is method_missing called. The use of define_method is a pretty neat solution to that problem. The method that wasn't found gets defined and it doesn't rely on method_missing again. Like a cache.
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] crystaln|2 years ago|reply
[deleted]
[+] [-] postmodern_mod3|2 years ago|reply
[+] [-] thih9|2 years ago|reply
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] TobyTheDog123|2 years ago|reply
[deleted]
[+] [-] unknown|2 years ago|reply
[deleted]
[+] [-] crazydoggers|2 years ago|reply
[deleted]
[+] [-] 2024throwaway|2 years ago|reply
[deleted]
[+] [-] BalinKing|2 years ago|reply
> Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
[+] [-] RangerScience|2 years ago|reply
If you have incorrect code and are happy programming, you fix your code.
If you have correct code, but are unhappy programming, you do not fix your code.
There is no correct code and Ruby prioritizes your happiness, so you get fixed code and happy programmers, instead of permanently broken code and unhappy programmers.
[+] [-] verelo|2 years ago|reply
[+] [-] timeimp|2 years ago|reply
[+] [-] nf3|2 years ago|reply
https://www.php.net/manual/en/language.exceptions.php
[+] [-] unknown|2 years ago|reply
[deleted]