Just to respond to this, JavaScript is one of my favorite language. I like it.
I like the fact I’ve a freedom hardly comparable to anything else. But it’s not
because we’ll have the possibility to use static types where it’s really useful
we’ll lose the hability to continue our work as we do today.
It’s just one more tool in your toolbox. Not a complete language change.
From: Allen Wirfs-Brock
Sent: Tuesday, September 13, 2011 9:01 PM
To: Axel Rauschmayer
Cc: es-discuss ; Breton Slivka
Subject: Re: IDE support?
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.
Allen
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
that trying to improve static analysis of javascript is barking up the
wrong tree? I think a better approach is to write your IDE in
javascript and have it running inside a context that has access to the
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
[email protected]
twitter.com/rauschma
home: rauschma.de
blog: 2ality.com
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
--------------------------------------------------------------------------------
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
