Hacker News new | ask | show | jobs
by PaulJulius 4254 days ago
Obviously this is a useful tool, and all the power to the author for finding what looks to be an excellent solution, but this line bothers me:

>>> Sometimes I wasted hours and hours just because there is one character difference. I hate it.

This shouldn't happen. Ever. This should not be a problem anymore. These are the sort of errors that we can catch immediately and should be caught immediately. From looking at the author's GitHub profile, it looks like he uses Emacs, presumably without a plugin that would give him IDE like features. I'm not going to tell him to go use a regular IDE, but it frustrates me that's we can't have those sort of tools available everywhere. (As a vim user myself I have high hopes for the neovim project and look forward to the day when it can be embedded inside a general sort of IDE.)

5 comments

While you can catch some of these, for a language like Ruby, it's an incredibly hard problem to catch all of these errors immediately because the methods that can be called on a given named entity can not in the general case be known by statically inspecting the source, and you can not in general safely instantiate the application because even class definitions are executed and can have side effects, and the methods available can even vary based on environmental factors, such as whether or not you get a database connection, and what's in the database.

Consider that it is a common pattern for Ruby ORM's to either use method_missing or dynamically define methods to correspond to the current (at connection time) set of columns present in your database.

And "thanks" to the ability to monkey patch and redefining methods, even determining if something "obviously" safe like 42.to_s is not.

There's no way for your editor to handle that unless you stand up a version of your app with an instrumented language environment and lets the editor poke around. Now that is possible with tools like Pry, etc., but it takes a lot more work to do safely (because your editor can't know if it can safely start your app).

Yuki works at Pivotal Labs in NYC. I work there too.

We use whatever editor or IDE any given pair decides to use. In my day-to-day work I've used RubyMine (very popular in our west coast offices), Vim (popular in NYC), Emacs (popular with Mike Dalessio) and my own personal favourite, Sublime Text.

I don't think solutions have to be either/or. Yuki's approach is simple and will cover lots of cases.

You're invoking "IDE" features like it's a panacea. In reality IDEs have only a few limited ways to catch these kinds of errors. With a statically-typed language it can run static analysis at intervals and make sure that all the messages being passed are actually defined on the objects they're being passed to. You can do this precisely because that's what static types gives you.

In dynamic languages you can't do this because you don't know the type that any given identifier is pointing to. The type could be completely arbitrary, I.E. coming from external input. You might think, "oh, well you could just check against all possible methods", and you'd be right, except for Ruby. Ruby allows you to override what happens when you call an undefined method, (method_missing) letting you execute completely arbitrary code that lets undefined methods look just like methods. You could call car.start_and_drive_to_the_bank, and set up the Car type so that it can handle methods like that, (perhaps calling car.start, and then car.drive(bank)) along with .start_and_drive_to_the_mall and whatever. In practice that's bad Ruby, but you still have to be able to handle that, Bad Ruby is still Valid Ruby.

So there's just no way to tell in Ruby whether any given method call is correct or not.

I have an idea to conventionalize method_missing overrides so that they're easier to analyze. Maybe define a regular expression on the class so that the analyzer can sort out what's likely to work at runtime and which messages aren't. Not sure how well it would work until Matz manages to implement static typing as he wants to do in the future. Until you can tell whether any given identifier is likely to be of a type that overrides method_missing, you'd be running the method_missing analyzer for all types on all method calls.

On the other hand, this gives a consistent experience and does not force people to mess around with plugins for their editor (if needed)
A spelling error in http request can cost more hours if using IDE.