Comment by gcv | Hacker News Reader

Comment by gcv | Hacker News Reader

The author's second and third points are either disingenuousness or ignorance.

* The omission of variable declarations has nothing to do with dynamic typing. Some dynamically-typed languages certainly do this (Ruby and Python). Some dynamically-typed languages make variable declarations optional or optionally-required (JavaScript and Perl). Some dynamically-typed languages require variable declarations (the Lisp family), and so do not suffer from the identifier misspelling problem.

* In my experience, Eclipse and other IDEs are not completely reliable when it comes to refactoring and variable renaming. Yes, they are good at it, but at the same time, they all offer preview modes and encourage the user to double-check the IDE's changes. I have seen Eclipse fail in renaming identifiers in Java code. For Lisps, I have found http://brian.mastenbrook.net/display/26 to be just about as effective as Eclispe's Java renaming.

As for the first point, the misuse of the word "macro" makes the entire argument rather difficult to address. It seems to boil down to taste.

> In my experience, Eclipse and other IDEs are not completely reliable when it comes to refactoring and variable renaming. Yes, they are good at it, but at the same time, they all offer preview modes and encourage the user to double-check the IDE's changes. I have seen Eclipse fail in renaming identifiers in Java code.

True, but an IDE will refactor accurately much, much more often on a statically type language than a dynamically one. Refactoring dynamically typed languages is pretty much impossible to do automatically when you don't have type information:

http://beust.com/weblog/2006/10/01/dynamic-language-refactor...

At work we have a Java backend and a very heavy/complicated JavaScript frontend. The frontend was born more recently while the Java backend has been around for years. Due to this situation, IntelliJ is the company-wide recommended development environment and most often used. IntelliJ is largely considered to be a quality IDE. And when using it for Java, it is. When using it for JavaScript, it's not only borderline useless but often downright counterproductive. We also have quite a bit of tooling written in Ruby, and most also use IntelliJ for that as well. Again IntelliJ falls on its face with Ruby too.

IntelliJ's ability to refactor Ruby and JavaScript is a joke and really just amounts to global searches and replaces, and wildly inaccurate results. I typically get out a plain text editor and ditch IntelliJ altogether.

I use IntelliJ's Ruby editor every day, and I think you're being too harsh. It definitely is much weaker than it is in Java, but it does a good job with simpler refactorings local renames, variable extraction and inlining, and method extraction and inlining.

> IntelliJ's ability to refactor Ruby and JavaScript is a joke and really just amounts to global searches and replaces, and wildly inaccurate results. I typically get out a plain text editor and ditch IntelliJ altogether.

Like I said in my comment above, this has nothing to do with IDEA: dynamically typed languages are just technically impossible to refactor automatically without the developer's supervision.

> dynamically typed languages are just technically impossible to refactor automatically without the developer's supervision

For sake of argument, let's say that's true and then ask - How much does that actually matter in practice? We have unit tests don't we?

Here's an example -

A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.

Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.

A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.

A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.

Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.

If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.

The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36.

from “Transformation of an application data layer” Will Loew-Blosser OOPSLA 2002

That's my point though. I'm not ragging on IDEA. I'm just using it as an example because I see the reality of dynamic versus static languages every day.

However, I do feel though that IDEA made some poor choices and tried to get refactoring and autocomplete capabilities in JavaScript when they probably should have backed off, and IntelliJ's performance suffers (sometimes greatly) because of it. As a simple example: if you use ExtJS and have it loaded in your IntelliJ solution, try to rename a local variable named ownerct. IntelliJ will completely lock up for about 15 minutes. Why? Because ExtJs uses the variable "ownerct" throughout, and IntelliJ is mindlessly sucking in all those references in. Of course you can set up your IntelliJ to avoid this situation, it's just an example.

If dynamic refactoring so easy they were doing it 30 years ago, but one of the best IDE makers in the world can't generalize it for the masses today, doesn't that tell you something?

"The omission of variable declarations has nothing to do with dynamic typing."

I was inclined to say this as well when I was critiquing the first point (http://news.ycombinator.com/item?id=3633351). But on further thought, just about the only dynamic language that flags assignment to a typo'd variable name is scheme[1]. So it seems like a significant correlation.

[1] Not common lisp. Does clojure?

JavaScript with "use strict"--which is basically the modern version of JavaScript, but has to be enabled explicitly because of backwards compatibility--also warns you about assigning a variable that hasn't been declared. Just shows that JavaScript really was influenced by Scheme :).

Ditto for Perl. And with modern Perl(s) this can be switched on with new language features using...

  use 5.010;  # or 5.012 or 5.014 and soon 5.016

Ah, thanks both.

In both languages, the use of a variable is almost always preceded by a binding of that variable to a symbol or var using the "let" form. This accounts for most uses of variables, and attempting to access a misspelled variable will flag an error at compile-time.

With regard to destructive assignment, most Common Lisp compilers warn on setf calls when executed against unbound symbols. Clojure doesn't have even have assignment in the sense discussed here (refs are bound before use, and the compiler enforces this).

Reply on news.ycombinator.com