Suggest.rb - tells you which method does the thing you want to do

I came across this project the other day and thought it was an interesting way to augment learning and using Ruby.

Suggest gives objects two extra methods; what_returns? and what_mutates?. Both methods take a result that you are interested in and return the methods you could call on the object to get that result.

For example:

require 'suggest'

[1,2,3].what_returns? 1
=> [:first, :min]

I can see this being useful when you're tooling about in irb and you're sure that there is a method that does the thing you want but you can't remember it. It could save a trip to search the docs and could even suggest better methods than the one you were thinking of.

Check it out on GitHub:

jbodah / suggest_rb

❓ tells you which method does the thing you want to do

Suggest

tells you which method does the thing you want to do

Disclaimer

I don't recommend you ship this in your Gemfile. Keep it in your system's gems (e.g. gem install) and load it as needed (e.g. irb -rsuggest, RUBY_OPT=-rsuggest irb, etc)

Installation

gem install suggest_rb

Usage

require 'suggest'
# Object#what_returns? tells you which method returns the value
[1,2,3].what_returns? 1
=> [:first, :min]

# You can also specify the args you want that method to take
[1,2,3].what_returns? [1], args: [1]
=> [:first, :take, :grep, :min]

# By default, it only returns methods that don't mutate the object
[1,2,3].what_returns? [1], args: [1], allow_mutation

…

View on GitHub

Comments

[Ariel Caplan]

I agree this isn't exactly production-ready, and honestly it probably never will be. But it might be useful in a dev environment (not production, not test) as a handy wait-is-there-a-Ruby-way-to-do-this tool.

It actually reminds me a lot of similar tools for Smalltalk (see Avdi Grimm's overview of the power of the Pharo Smalltalk IDE) and could be similarly integrated into Ruby IDEs as an autosuggest tool.

Rather than freaking out because it's not production-ready, maybe let's remember this is a toy project and a neat development tool, and it could be quite handy day-to-day even if you shouldn't include it in your production environment.

[Ariel Caplan]

I absolutely adore Enumerable, but I don't remember everything it can do all the time. I don't feel guilty or inferior because of that. There's too much information in the world to remember all of it.

I strongly suggest reading Don Norman's The Design of Everyday Things, specifically the chapter about knowledge in the head vs. knowledge in the world. The more we have to remember, the more mistakes we make. The more we need to rely on our memory to make tools available to us, the fewer tools we're likely to use in practice. This is how humans are.

I'd posit that the fewer details we have to remember in order to code, the more we can think about the bigger questions: What are the edge cases? What are the user needs, and is this code I'm writing actually fit for purpose? Will the next person editing this code be able to understand what I wrote, or should I break down the problem in a different way?

That's the kind of understanding and productivity I want in my team. I don't care whether my teammates know what Enumerable#grep_v does without looking it up in the docs. I do care whether they know how to read a requirements document and ask clarifying questions. I do care whether they notice that a method or class is getting too big and feel the need to split it up. I do care whether they know to prioritize shipping features as a team over finishing a personal task list. There are so many things I care about more than their proficiency in Ruby (or other language) trivia.

So... different strokes for different folks?

[Ariel Caplan]

Looks like the only difference between our approaches is I do care about my team knows the language they use on daily basis and you do not.

This is pretty harsh. I'd suggest that we both care that the team knows the language, but we define "knowing the language" differently. I think you can write clean, idiomatic, optimized Ruby without knowing all the details by heart, and in fact I believe you're more likely to do it through automated tooling than through memorization. You seem to disagree with some or all elements of that hypothesis. I hope your approach works for you.

[Phil Nash]

Good chat everyone, I think this came to a nice conclusion. I think I agree mostly with Ariel and that is one of the reasons I found this project interesting. Not having to keep a bunch of methods in your head is much more fun and productive than memorising standard libraries.

Also, the experimental nature of the library itself definitely means that it wouldn't be entering the production group of gems in any codebase I am working on. As a tool that you could include in your .irbrc or .pryrc and use when debugging/playing in the terminal, it could be useful.

[Raounak Sharma]

Ya, nice tool. But might not be useful when using a framework. Need to shift to IRB console and write the code there to see, will equally time consuming as searching on web.

But still I like the efforts

[Phil Nash]

You'd be surprised how many times I open the rails console during development to test and mess with things. I think this could be used alongside that.

[Raounak Sharma]

Ya, you are right.

[Ben Halpern]

I can see this being useful when you're tooling about in irb

I agree. Really helpful on the go. I just installed it.

[Ariel Caplan]

Many people benefit from RubyMine or from Ruby-aware plugins to IDEs like Vim or VSCode. This could be the beginning of great tools to help people figure out what code to write instead of getting stuck browsing Enumerable documentation. The less people have to remember to be productive, the better.

What's the negative value you perceive here?

[Phil Nash]

Thanks for jumping in Josh! It's interesting to hear the motivation behind the project as well as how you've found using it over time too. I regularly find you start projects for one reason and a completely different use case emerges.

[MetaDave 🇪🇺]

This is a really creative bit of functionality.