IDE support?

[John J Barton]

Just to point out that Web Inspector in the Chrome browser has run
time dot completions (as does Firebug) and it has live JS and CSS
editing with save to file. I won't defend the user experience, that
needs work.

I tried and failed to convince one IDE team that starting from the
runtime tools was the short path to better Web dev.

jjb

On Tue, Sep 13, 2011 at 12:01 PM, Allen Wirfs-Brock
<allen at wirfs-brock.com> wrote:
> 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
>
> axel at rauschma.de
> twitter.com/rauschma
>
> home: rauschma.de
> blog: 2ality.com
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>