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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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_vdoes 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?
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.
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
.irbrcor.pryrcand use when debugging/playing in the terminal, it could be useful.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
You'd be surprised how many times I open the
rails consoleduring development to test and mess with things. I think this could be used alongside that.Ya, you are right.
I agree. Really helpful on the go. I just installed it.
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?
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.
This is a really creative bit of functionality.