re: Suggest.rb - tells you which method does the thing you want to do VIEW POST

FULL DISCUSSION
 

OMG. It

Maybe more in another exposed method I did not bother to check. I would triple-think before using this gem and I would definitely reject it in our code base.

 

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.

 

could be similarly integrated into Ruby IDEs as an autosuggest tool

I don’t know what Ruby IDE stands for and why autosuggest could be ever considered to be a helpful feature.

I am not freaking out because it’s not production-ready. I am freaking out because I see the negative value of using this kind of tools.

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?

I find intellisense / autosuggest tools making people press Tab + Enter without real understanding what’s going on there under the hood.

Also, I disagree with “The less people have to remember to be productive, the better” completely. I don’t need this kind of productivity in my team. I need a deep understanding, including, but not limited to memorizing things.

I do remember all methods of Enumerable despite I do not do Ruby for more than one year and I doubt I understand what could be the issue with doing the same.

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?

There are so many things I care about more than their proficiency in Ruby (or other language) trivia.

Which is fine. All these things are very important and I care about all of those as well. Maybe even also more than proficiency in Ruby. 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. Which is also fine.

different strokes for different folks?

Sure. This maxim is applicable literally everywhere.

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.

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.

I believe you do confuse cause with effect.

I am not advocating the necessity to memorize anything. I am saying that if someone needs [1,2,3].what_returns? 1 that’s the clear sign the skills in this language are on the very basic level.

As a contrived example, I do not need to memorize my home address, I always can google for it (well, check my address book in my phone,) but guess what?—I do remember it.

code of conduct - report abuse