Live data from Hacker News

“Did you mean?” Experience in Ruby

yukinishijima.net

51–60 of 187 posts

Re: “Did you mean?” Experience in Ruby

#51
Wow. Talk about the wrong approach. When you're having to play trial-and-error to get the right method, you definitely have a problem with your tools - not the language!

I don't know about other editors, but vim has great autocomplete support for ruby built right in. Because of this I don't often even type methods out in full anymore.

And there's a great plugin for doco too: https://github.com/danchoi/ri.vim

Re: “Did you mean?” Experience in Ruby

#53
post #40

A lot of people are recommending IDE-like tooling--but in truly dynamic language (one with a "living image" with path-dependent monkey-patched behavior that can't be replicated during static analysis, like Smalltalk--or, sometimes, Ruby) there's a more idiomatic way. In a dynamic language, if you're at all unsure of what code you need to write, then you don't write it in your editor in the first place. Instead, you b…

Funny that you mention Smalltalk, because of its image model, completion usually works quite well.

I remember using it on my Smalltalk days at the university in 1996.

Re: “Did you mean?” Experience in Ruby

#54
post #40

A lot of people are recommending IDE-like tooling--but in truly dynamic language (one with a "living image" with path-dependent monkey-patched behavior that can't be replicated during static analysis, like Smalltalk--or, sometimes, Ruby) there's a more idiomatic way. In a dynamic language, if you're at all unsure of what code you need to write, then you don't write it in your editor in the first place. Instead, you b…

I like this approach, and I think that we're not doing it enough.

Does anyone know an effective way to do this in the browser, with JavaScript?

Re: “Did you mean?” Experience in Ruby

#55
post #35

Earlier quoted context omitted.

Context sensitive auto-complete is a godsend.

Seriously. Is there a good list of tools that provide it? In Python, the only one I've managed to love is PyDev. Supposedly Atom does it with the "script" package?

Netbeans JavaScript support is quite good, and was originally based on JRuby support.

Re: “Did you mean?” Experience in Ruby

#56
post #40

A lot of people are recommending IDE-like tooling--but in truly dynamic language (one with a "living image" with path-dependent monkey-patched behavior that can't be replicated during static analysis, like Smalltalk--or, sometimes, Ruby) there's a more idiomatic way. In a dynamic language, if you're at all unsure of what code you need to write, then you don't write it in your editor in the first place. Instead, you b…

"something that manages your expression experiments and the context harnesses they need" This is the exact purpose of tests.

No: tests don't change, especially iteratively. If you're editing and re-running your tests in a loop (rather than editing and re-running the code in a loop against the tests), then your tests aren't doing anything related to "testing", because you're changing their pass/fail criteria with each edit. To do so is just to abuse a test suite+test runner as a REPL.

On the other hand, once you know what you're doing, the expectation can be codified into a test (dead code) to assert that the live code maintains an equivalent property with no regressions. A "finished" IPython notebook can indeed be replaced with a regression test to ensure the behavior remains the way you previously determined it to be via experiment. (Though note that this is subtly different from functional testing: you're not asserting any preconceived notion of how an API "should" respond; you're just asserting that the API seems to hold to a certain contract—the one you discovered from your experimentation—and that it's a regression if it then goes against any of the parts of the discovered contract that you had come to rely upon.)

Re: “Did you mean?” Experience in Ruby

#58
post #53
post #40

A lot of people are recommending IDE-like tooling--but in truly dynamic language (one with a "living image" with path-dependent monkey-patched behavior that can't be replicated during static analysis, like Smalltalk--or, sometimes, Ruby) there's a more idiomatic way. In a dynamic language, if you're at all unsure of what code you need to write, then you don't write it in your editor in the first place. Instead, you b…

Funny that you mention Smalltalk, because of its image model, completion usually works quite well. I remember using it on my Smalltalk days at the university in 1996.

It works great if either A. The IDE lives inside the same live image the project being developed is loaded in; or B. there exists some sort of network/RPC-exposed "code server" running within the live image, which you can ask to do these sorts of completions.

Of non-Smalltalk languages, the only one I can think of with anything like that is Erlang. You could easily enough build a code server in Ruby, but you'd have to explicitly include the library that implements it in your project, and start up a server thread to expose it to an IDE that wanted to talk to it, etc. And because of that, it wouldn't be "part of the language" to the point where tooling (like IDEs) would be built to expect it.

The real problem, though, is that people are coding in dynamic languages with no live image connected to the editing session at all: instead, the code is just dead text until they want to test it, at which point it gets injected into a fresh session, run once, and then the session is immediately discarded (creating what is possibly a completely different path-dependent monkey-patch execution sequence than would happen in production, or in a REPL, or...).

For some languages this happens out of necessity, but for most, it's just an artifact of the batch-processing mentality. All e.g. Light Table gives you, when you think about it, is a text editor with a connection to a live Clojure or Python image; and yet to many it seems to be a completely foreign interaction paradigm for programming.

Re: “Did you mean?” Experience in Ruby

#59
post #43
post #32

Earlier quoted context omitted.

It's kind of silly, the major benefit of using Ruby (or JavaScript nowadays) is to iterate quickly. But then, some of their users spend months turning a text editor into an IDE just to waste precious hours on spelling errors.

Most text editors have naive autocomplete (using a words list and words they see), which catches 99% of these errors.

I have experienced some problems with this kind of autocomplete in a JS project.

-Two methods shouldn't have a similar name, so you try to avoid it, possibly leaving you with a worse abstraction.

-You usually need to have all files open or at the same location, so modularization is discouraged.

-Libraries are usually not picked up by it.

-If you make a spelling error on the first usage you now have this spelling error everywhere.

Naive autocomplete is much better than none, but it's still not in the same league as context sensitive autocomplete.

Re: “Did you mean?” Experience in Ruby

#60

I've been pairing with ruby / rails developers since 2010 and coming from statically typed languages, it's unbelievable how much time gets spent playing "guess the method name". Even in rich IDEs like RubyMine, the utter lack of context in any given file in rails leaves programmers typing their best guess of a method name, running the tests, rinse, repeat. This solution, while creative and laudable, solves a problem…

It's not a problem that can be solved for a language like ruby without adding type hinting (and probably interfaces) to the language. FWIW php actually does support this.

[deleted]
Post reply on HN