Subj : Re: Future of JS?
To   : netscape.public.mozilla.jseng
From : Shanti Rao
Date : Mon Oct 18 2004 10:56 am

Thanks, Brendan! A few comments...

1. A JS-based server application might want to use a context pool, with some 
modules pre-loaded. The risk is that nefarious client-generated code might 
modify the pre-loaded modules. Formal interfaces? Read-only object trees? 
Tainting with principals?

2. Could namespaces be treated as JS objects? JS1.5 can do this:

myName = load('module','version')
myObj = new myName.Class('blah');

3. While coroutines are really nifty (get yourself a RabbitCore), generators 
are very easy to screw up. (I like this explanation: 
http://www-106.ibm.com/developerworks/library/l-pycon.html). Iostreams might 
be a suitable simplification?

function generator(outStream)
{
  for (i=0; i<100; i++)
  {
   outStream.send({value: i});
  }
}

function consumer(inStream)
{
  while (inStream.peek())
   print(inStream.read().value);
}

For cooperative multitasking, the algorithm is fairly simple: when the 
consumer asks for data, run the creator until it spits something out. For 
preemptive multitasking, you also need a cache and blocking send() and read() 
calls.

Overloading is a way to selectively remove strong typing. But JS doesn't have 
strong typing.

Shanti


> Shanti Rao wrote:
> 
>> Brendan,
>>
>> Can you tell us your long-term vision for the JavaScript language? 
>> What sort of problems is it intended to solve?
> 
> 
> 
> JS was always intended to be easy to use -- although the C heritage 
> implied by the Java- prefix, imposed by Netscape management edict when I 
> created "Mocha", dictates braces and semicolons, which are not all that 
> easy to use for novices (but, I added automatic semicolon insertion 
> right away, to the consternation of purists ;-).
> 
> JS has always been about writing, or copying and hacking up, little 
> snippets of code within "documents" (broadly construed), where these 
> scripts deal with objects, strings, numbers, booleans (with loose 
> conversion rules), and a few special "bottom" values.
> 
> The onclick event handler model, based directly on HyperCard, and the 
> instance-tree of the DOM reflected from the nesting of HTML tags, are 
> closely tied to JS's object model and type system.
> 
> So much in JS, although not the punctuator and bracketing syntax, and 
> not many names and naming conventions that imitate Java, is geared 
> toward economy of expression -- those "little snippets".
> 
> The trouble is Parkinson's Law.  Little snippets grow into big ones. The 
> language can't be as loose or type-simplistic as awk or TCL, say -- it 
> has to support some amount of programming in the large, or at least in 
> the medium scale, without requiring you to write a page of boilerplate 
> just to do the simplest thing.
> 
> Of particular importance are namespaces and versioning, so that 
> different scripts or modules (scripts loaded into document containers) 
> can present abstraction barriers bearing explicit type information and 
> qualified names, which form contracts that can be maintained across 
> multiple concurrent implementations, and of course across serial 
> re-implementation.
> 
> It's clear to me not only from web apps and DHTML libraries, but 
> especially from Mozilla's XUL apps, that classes and full-strength 
> "classical O-O" are less important than modularity (namespaces, 
> versioning, stronger -- but not necessarily only static -- typing, and 
> information hiding).  For instance-wise modularity, JS could evolve 
> classes, but one could imagine extending the current prototype system to 
> support information hiding, namespaces, versions, and even multiple 
> prototypes.
> 
> Operator overloading, method overloading, and generics of some sort may 
> be important for ease of use and clarity of expression in some domains. 
>  These too do not strictly imply classical O-O.
> 
> Optimizability may matter more than it does now.  It should be possible 
> to write JS2 that can run as fast as truly equivalent native code, or 
> within epsilon.  Such optimizability should come from careful language 
> design with an eye on existing virtual execution sytems such as Java and 
> Mono, if possible.  There should not be a need to invent a new runtime 
> just for JS, although such runtimes exist now and may continue to find 
> markets in the future, for various reasons.
> 
> Experience tells me that for too many of JS's problem spaces, IEEE-754 
> double precision is often the wrong number type.  A rational or decimal 
> numeric type extension, with sensible conversion and operator dispatch 
> rules, would be a huge help for many users.
> 
> Another extension that would help many practical coders: continuations, 
> a la stackless Python's generators.  Too much JS code must be written in 
> a series of callbacks orchestrated via explicit state machines, with the 
> callback functions having to store and recover state manually.  Such 
> control-block continuation-style programming is ugly, error-prone, and 
> hard to debug.  Why not let a special form of functions return a value 
> without unwinding, and be resumable to return more values, indefinitely?
> 
> Yet another missing feature, implemented partially in SpiderMonkey via 
> __noSuchMethod__: the ability of an object to handle get, set, or call 
> on an arbitrary undefined name.
> 
> Block scope, or perhaps some more clever way of unifying closures and 
> compound statements, would help certain classes of users.  The default 
> creation of a global variable when assigning to a name not bound in the 
> scope chain is one of the botches I knew I'd regret, but (for want of 
> similarity to Java) I could not convince myself in 1995 to require the 
> alternative (a TCL-like global statement to import outer names into 
> functions).  So some new mode for variables seems appropriate, with the 
> right compatibility defaults.
> 
>  From much of the above, it should be clear that I don't believe JS2 
> must compete with C# (or with Java, with which C# clearly competes). Why 
> have yet another such language?  JS's strengths are dynamism (both via 
> eval and using run-time types, which enable many functions to be 
> generic), Scheme-like closures, rapid prototyping from small to medium 
> scale, property get and set handlers, prototype-based delegation, and 
> some (sometimes unfortunately misleading) familiarity for Java and C 
> hackers, whether expert or novice.
> 
> /be
>

.