allen at wirfs-brock.com
Tue Sep 13 12:01:25 PDT 2011
There are key points in Breton's post below that should not be lost in a debate on whether or not dynamic JS performance can or can not asymptotically approach that of a hypothetical class-based statically typed language (something that you might call simply "J").
Success with a dynamic language languages requires understanding that they are different beasts than statically typed languages. Great performance and great development tools for them is not achieved by trying to treat them like a poorly designed or ill behaved statically typed language. The recently successful JS "engine" implementors already knew or ultimately learned this and we have really turned the corner on JS performance (now if they can just get their acts together WRT garbage collection...).
We need to do the same thing with our JS tools. All of the great dynamic language IDEs (that, BTW, preceded and largely inspired the modern static language IDEs) were "live" environments. They didn't just provide a live debugging experience, it was a live authoring experience. You developed code as a dynamic running program. They truly support incremental, interactive development. Developers operate in a continuous write a little/run a little cycle. The tools use information obtained from an actual running program to provide a great developer experience. Regarding Axel's case of "dot completion". In a real live development experience you would probably be writing that code within the context of a a function call that is suspended because the function doesn't actually exist yet or its body has not been filled in. As you write that code the tools have visibility of the actual arguments that were passed to the suspended call as one of the sources of information for suggesting dot completions.
It is probably also worth noting that the language "engines" the successful live dynamic language environments were built upon were engineered all the way down to their lowest levels to support the dynamic program modification capabilities needed to support their live developer experience. In many cases it makes sense to algorithms around immutable immutable objects but such objects sill need to be mutable by the tools of a live development environment.
Another difference is that static language IDEs generally try to provide perfect information. If one provides a dot completion list then the expectation is that the list is contextually exhaustive and accurate. These and only these names can be used after this dot. A dynamic language tools would offer an advisory list. Here are some names that based upon the tools current understanding of the program are likely to be meaningful after this dot. Static tools operate under the illusion that programs are a fixed and closed world that can be perfectly understood. Some people would say that such programs tend to be "fragile" in the face of change. Dynamic language tools work in a world where programs are malleable and continually evolving. Which is a closer reflection of the actual web?
To do great things with a language you have to love the language. The great JS development experiences of the future will be built by a new generation of JS lovers who aren't constrained by static language notions of how development tools need to work.
On Sep 13, 2011, at 4:49 AM, Axel Rauschmayer wrote:
> For features such as expansion help (e.g. when you type a dot after a parameter name inside a function), you still need static analysis.
> But your point stands: JS IDEs can and should go beyond “edit-compile-debug” (which has become so mainstream that many people forget about languages such as Common Lisp and Smalltalk).
> On Sep 13, 2011, at 6:44 , Breton Slivka wrote:
>> Forgive me if this has already been talked about, but is it possible
>> wrong tree? I think a better approach is to write your IDE in
>> running JS environment. Think about the precedents set by Smalltalk
>> and Self, and even Forth, with hints of this happening in the modern
>> browser "debugger" environments which now have some rudimentary code
>> completion features.
>> A JS IDE should be a running environment that can reflect on changes
>> to the environment dynamically and "save" them back out to your source
>> files, via some diff like protocol which can be rather
>> straightforwardly implemented with proxies, akin to how a self program
>> was essentially an in memory image core dump.
>> Having your IDE hooked up to a running JS context gets around a lot of
>> your problems with static analysis, including even dealing with
>> dynamic property access, dynamically constructed objects, prototype
>> chains and inheritences, and function name aliases.
> Dr. Axel Rauschmayer
> axel at rauschma.de
> home: rauschma.de
> blog: 2ality.com
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss