Live data from Hacker News

Ruby's exceptional creatures

exceptionalcreatures.com

51–60 of 133 posts

Re: Ruby's exceptional creatures

#51
post #7

Earlier quoted context omitted.

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

Do you mean the class << self pattern?

That's what I thought as well. If someone's opening metaclasses to define singleton methods they probably know all about the Ruby object model. I don't see how it could be done "without knowing you're doing so".

Re: Ruby's exceptional creatures

#52
post #41

Ruby is a good gateway to programming, better than C, C++, Java, Python,...

Better than Python? 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…

I never 'learned' python and ruby is the path I went with and still use for 90% of my own software.

However Python is a easy transition. I rarely struggle to do anything with it when I need it. Even Django wasn't to weird to grasp after years of rails.

IMO it's not to relevant which language you choose to learn in the beginning of your career. Whatever is more fun or works better for your interests.

Re: Ruby's exceptional creatures

#54
post #41

Ruby is a good gateway to programming, better than C, C++, Java, Python,...

Better than Python? 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…

Antoine de Saint Exupéry once said,

    'If you want to build a ship, don't drum up people to collect wood or assign them tasks and work. Instead, teach them to long for the endless immensity of the sea.' 
This resonates with how I feel about programming languages. Python might be more practical, but does it ignite a passion for coding like Ruby has historically done? I remember dabbling in Python, Perl, and JavaScript (ES5) back in high school, but it wasn't until I rediscovered programming through Ruby that I truly began to enjoy it.

Nowadays, I might not default to Ruby for new projects, having moved on to OCaml and Elixir, among others. Yet, there's something about Ruby's community (its charm and gentleness,) that's missing in many others. This nurturing environment is invaluable for beginners. It's noteworthy how members of the Ruby community, like José Valim with Elixir, Yehuda Katz with Ember.js and Rust, and Chris McCord with Phoenix, have carried this spirit of playfulness and a deep care for developer experience into other communities they've joined.

Re: Ruby's exceptional creatures

#55

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 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.

Re: Ruby's exceptional creatures

#56
post #42

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 fu…

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

Why so? This is in my book the best form of advertising. It provides anyway something useful for the interested reader, while exposing the (alleged, at least) usefulness of their services. Much better this that a banner or a pop-up in some random website that tracked you down as a Ruby developer.

Re: Ruby's exceptional creatures

#57
post #12

Earlier quoted context omitted.

Reading your comment one would think Ruby is the only programming language with exceptions. In fact, lots of programming languages have them, even PHP. https://www.php.net/manual/en/language.exceptions.php

Exceptions are not the issue, Ruby's inherent "cleverness" is. Whatever problems the original commenter has with exceptions likely stems from this.

I agree that too much cleverness is unclever. Just don't use clever features and enjoy the rest of the language. Examples:

In some other comments somebody wrote about method_missing and ActiveRecord callbacks. Days ago we had a post about a state machine gem.

Leave method_missing to the inner workings of gems. Do not use it in your code. Even in gems, hide them well. Rails used to have auto-generated find_by_field1_and_field2 methods, by method_missing if I remember well. They eventually moved to where(field1: value1, field2: value2) and we are fine with that.

ActiveRecord before and after filters are just callbacks like many libraries have, in any language. They need discipline because of the obvious problems we can run into if we add a ton of code to the callback system, possibly with side effects and multiple definitions of the same callbacks in classes derived from a common model. That's actually a very bad code smell (and a broken architecture?) and something that we could be tempted to do but we learn not to do. I use them very sparingly. The whole validation system is a particular case of before save callbacks. I think that every ORM for every language has got a validation system.

Another case of callbacks are the ones for the state changes of finite state machines. We can define them with function pointers in C structs or with symbol names in Ruby, they are the same thing. The triggers for state changes: same thing.

If I can choose I go with the more explicit alternative because... Finally I confess that I lose time when reading some new code bases to understand if some object.something is an attribute, a method, a state machine callback or something else auto-generated by some other gem. I think that LSP servers have a very bad time following those methods and probably none of them do. Maybe heuristic in IDEs can do something about it.

If I feel that I would be in trouble there, I add a short comment explaining the origin of the method: "this is from gem XYZ", then the docs will explain how and why to the next developers. Maybe they will thank me.

Re: Ruby's exceptional creatures

#58
post #41

Earlier quoted context omitted.

Better than Python? 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…

The biggest difference between both is mainly their machine learning story but if you don't intend to go in it (this is a very specific career choice), I'd say both are equally good options. I'd say both are pretty bad at performance critical tasks or UI stuff where usually you would use neither of those.

Python is so much bigger than Ruby. It's not just machine learning. There's also numpy and Jupyter for the scientific community, which are huge. There's arcade for making 2D games. There's Micropython for microcontrollers. There are async database drivers and web frameworks. There's interop for many other programming languages, and it's really easy to make a distributable package with Python runtime included.

And that's just what I can recall of the top of my head as someone whose primary language is not Python.

Re: Ruby's exceptional creatures

#59
post #41

Earlier quoted context omitted.

Better than Python? 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…

Antoine de Saint Exupéry once said, 'If you want to build a ship, don't drum up people to collect wood or assign them tasks and work. Instead, teach them to long for the endless immensity of the sea.' This resonates with how I feel about programming languages. Python might be more practical, but does it ignite a passion for coding like Ruby has historically done? I remember dabbling in Python, Perl, and JavaScript (E…

This is more or less personal preference though. When you say that Ruby ignites a passion for coding for you then that might not happen for other people. For example I only feel a headache when I look at Ruby code.

For context: I worked with C, C#, some Python and now mostly work in Go.

Re: Ruby's exceptional creatures

#60

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 fun…

The docs are just explaining how method resolution order works in ruby (i.e. explaining method_missing but not saying you should rush out and use it).

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.

Post reply on HN