IDE support?

[François REMY]

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

  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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110913/a5e77c22/attachment-0001.html>