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
51–60 of 187 posts
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
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 remember using it on my Smalltalk days at the university in 1996.
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…
Does anyone know an effective way to do this in the browser, with JavaScript?
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?
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.
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.)
In this case, you would solve the error while typing it.
A simple dropdown with suggestion(s) would be great in Sublime Text.
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.
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.
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.
-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.
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.