Strange. As an ruby programmer, I never had such a need.
“Did you mean?” Experience in Ruby
111–120 of 187 posts
Re: “Did you mean?” Experience in Ruby
#112I hope somebody forks this and creates a version that automatically corrects the method for you at runtime. Why even show an error or throw an exception? Bonus if the corrections are cached for performance.
This has already been done before:
http://decomplecting.org/blog/2013/03/01/code-typos-got-you-...
Re: “Did you mean?” Experience in Ruby
#113Earlier quoted context omitted.
I also work that way. I use the autoreload feature of ipython so that any code I change in my editor is instantly replicated in my ipython objects. I've really never been more productive in development in my life. Contrast with some Java I was doing recently (granted, without a Java IDE) and I found the whole cycle painfully slow. Even things the compiler picked up were a magnitude slower to find than when I was in i…
"without a Java IDE" This was your problem. Programming Java without an IDE that recompiles your changes on the fly is just so arcane and really slows you down as you noticed.
Also for J2EE you need jrebel.
Re: “Did you mean?” Experience in Ruby
#114Earlier quoted context omitted.
It's a hard problem to solve. In general inferring which methods are valid on any given variable or expression is undecidable. So you have to make an approximation, which is hard and the end results usually still disappointing. Here's a little test case: def foo(x): return x a = foo("hello") b = foo(34) To infer the methods that you can call on `a` and `b` you have to trace through the `foo` function. You can't just…
> In general inferring which methods are valid on any given variable or expression is undecidable. And yet, Hindley-Milner can do it. In general. I've been working with dynamic and nontyped and weak typed and duck typed languages for over half of my life and you know what, it's getting ridiculous. They were never meant to support the team and project sizes we're forcing them into now.
Hindley-Milner and other type systems do it by restricting the class of programs you are allowed to write. Essentially what they do is if they can't infer the type of a variable they terminate with an error. The class of programs that you are allowed to write is still reasonably big and Turing complete, but as research to make the type system more expressive shows, people want to go beyond that (higher kinds, GADTs, dependent types, polymorphic variants / structural records, subtyping, etc.). Type inference for a dynamically typed language can't terminate with an error if it can't infer the type, it has to be conservative in the other direction: if it can't infer the type of a variable it must assume that it can be anything.
Re: “Did you mean?” Experience in Ruby
#115It's almost like... statically typed languages!
Re: “Did you mean?” Experience in Ruby
#116Earlier quoted context omitted.
It's a hard problem to solve. In general inferring which methods are valid on any given variable or expression is undecidable. So you have to make an approximation, which is hard and the end results usually still disappointing. Here's a little test case: def foo(x): return x a = foo("hello") b = foo(34) To infer the methods that you can call on `a` and `b` you have to trace through the `foo` function. You can't just…
> In general inferring which methods are valid on any given variable or expression is undecidable. And yet, Hindley-Milner can do it. In general. I've been working with dynamic and nontyped and weak typed and duck typed languages for over half of my life and you know what, it's getting ridiculous. They were never meant to support the team and project sizes we're forcing them into now.
Of course you understand this, but for the benefit of the audience:
HM can do this because it dramatically restricts the allowable complexity of every single name in the program. This is rarely a problem, though, as typically you, as a programmer, only ever intend for names in the program to be so complex. The result is that HM simply ensures that your program is one which makes enough sense all of the time.
Which is sometimes painful for people when they first start.
Re: “Did you mean?” Experience in Ruby
#117I'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…
I have exactly this frustration as a person coming from static languages (mostly C++) to web dev. Anybody can recommend something more comfortable? I like the concept of Vaadin, but I'd prefer something non-Java.
Dart has great autocomplete.
Re: “Did you mean?” Experience in Ruby
#118Earlier quoted context omitted.
> In general inferring which methods are valid on any given variable or expression is undecidable. And yet, Hindley-Milner can do it. In general. I've been working with dynamic and nontyped and weak typed and duck typed languages for over half of my life and you know what, it's getting ridiculous. They were never meant to support the team and project sizes we're forcing them into now.
Hindley-Milner and other type systems do it by restricting the class of programs you are allowed to write. Essentially what they do is if they can't infer the type of a variable they terminate with an error. The class of programs that you are allowed to write is still reasonably big and Turing complete, but as research to make the type system more expressive shows, people want to go beyond that (higher kinds, GADTs,…
This was helpful! Now I have a bunch of new things to research and learn. Thanks!
Re: “Did you mean?” Experience in Ruby
#119Earlier quoted context omitted.
Aren't Java and C++ statically-typed as well?
> Aren't Java and C++ statically-typed as well? Yeah, but not so you'd notice, coming from an ML or Haskell background. /sarcasm More seriously, Java and C++ (and C and Algol before them) fell into the trap of defining "data size specifications" as types: The discontinuity between "long long int" and "int" is one, as is the discontinuity between "float" and "double". The real type difference is between things which a…
It is not a "trap". In "C" it is required to generate fast machine code. It's a trade-off, not a "trap".
Re: “Did you mean?” Experience in Ruby
#120Could I also highly recommend making your project Rubocop-clean, and using pronto to run Rubocop on your CI server and make comments on your commits in Github. Rubocop warns against any methods you define that are not used at least once.