Tuesday, January 3rd, 2006

JavaScript: Marriage of Dynamic and Static a killer feature?

Category: Editorial

Jon Udell wrote an opinion piece titled ECMAScript: The Switzerland of development environments? in which he discusses the progress of JavaScript, er ECMAScript.

He puts together a bunch of threads from seeing Macromedia’s Flex 2, to hearing Charles Petzold talk questioning “Does Visual Studio Rot the Mind?”.

In the end he comes to a hypothesis that maybe, with new versions of ECMAScript that support optional static typing, we will see a blend of techniques, and we will work out patterns for when it is helpful to have one versus another.

For example, we make vendors put in more type info into core types so we can Ctrl-Space to get all methods, but we just glue together dynamically.

Or maybe tools will just catch up a lot of the way. A bunch of them have techniques for finding out methods calls in dynamic languages (hell SmallTalk did this a loooook time ago).

But is JS 2 dead anyway?

Posted by Dion Almaer at 11:29 am

3.3 rating from 8 votes


Comments feed TrackBack URI

I don’t think Smalltalk IDEs have every done completion like that. They have a bunch of other tools, but code completion isn’t one of them. For instance, if you ask for implementors of a method in Smalltalk, you get essentially a list of all the classes that include that method according to name. Or, if you ask for all users of a method, you get all code that uses that method name in any way (more structured than grep, but not type-aware). In contrast, with static types and interfaces you could get a list of classes that use the method according to its meaning (e.g., distinguish between shoot-as-in-kill and shoot-as-in-photograph).

I think Smalltalk shows you can create a good IDE without static typing, but it’s not a simulation of the kind of IDE that makes sense for a statically typed language.

Comment by Ian Bicking — January 3, 2006

I’m not sure that static typing is the right answer here. Why should we be doing the work of tools w/o benefit? If type suggestion were based on tests that also informed behavioral constraint, I’d be more interested. As syntax, however, I’m not interested.

That Macrodobe tried to perpetrate a one-off hack of a language and is now trying to pass off strong typing in JS as a “feature” smacks of opportunism and, well, just bad design.

If we need to annotate, fine, but lets not add it as syntax that is incompatible w/ JS 1.5. You can add introspectable information in comments or by convention. No need for syntax. MM might have the luxury of treating its users as language design guinea pigs since they can tightly tie runtime and authoring environments, but it’s neither palatable nor useful for what is essentially a tooling and testing problem on the broader web.


Comment by Alex Russell — January 3, 2006

Leave a comment

You must be logged in to post a comment.