Compatibility vs. Performance

Performance web » Archive du blog » Un mode “fast” ?

Performance web » Archive du blog » Un mode “fast” ? — Thu, 01 May 2008 17:11:12 GMT

PingBack from http://performance.survol.fr/2008/05/un-mode-fast/

re: Compatibility vs. Performance

Eric Lippert — Tue, 24 Jan 2006 03:22:10 GMT

Peter was the program manager for JScript .NET.

I would personally love to see JS.NET in IE7 but I know of no plans to make it happen. Feel free to post any ideas you might have and I'll pass them on to the people who presently own script.

re: Compatibility vs. Performance

tbink — Tue, 24 Jan 2006 03:18:09 GMT

This is somewhat off the point of this thread but generally related. I do considerable programming in Javascript/Jscript in the form of DHTML applications using .HTAs. I won't go into detail about why but having application like functionality while maintaining script compatibility with IE is one good reason. In other forums (www.dotnet247.com) someone was talking about the possibility (likelihood?) that Jscript.NET might be made clientside. I refer to this message [Hi, There are no concrete plans for this at the moment but that could change. We are looking for customer feedback on this (there is very little so far).
Embedding JScript .NET inside the browser is definitely a "cool" thing to do, but unless customers come back and say "Hey, this would really make my life easy!" or "This enables a whole bunch of new scenarios for me" it's
probably not going to happen. -- Peter Torr ]
Peter speaks as if he works for Microsoft. My question... Might you embed Jscript.NET in IE7? If you need scenarios as to why this would be worthwhile I can supply a few concrete ones. In general I'd like to stimulate conversation on this topic, perhaps on its own thread.

Thomas Giebink

RE: Compatibility vs. Performance

Jay Hugard — Thu, 30 Oct 2003 00:39:00 GMT

Eric: I'd be interested in hearing about the rest of your points too. One of the reasons I like JavaScript is its "prototype" programming paradigm based on some ideas pioneered in the "Self" language/system. IMHO, it appears that JScript.NET is moving (has moved) away from those roots. Personally, I would have enjoyed seeing more "Self-isms"... perhaps allowing one to provide runtime prototyping in a live system, rather than a move to static compilation and static type checking. On the other hand, this would likely be at odds with generating efficient .NET code... the JIT compiler for Self was/is a lot more sophisticated than the one (I am sure) the .NET VM has.

RE: Compatibility vs. Performance

Eric Lippert — Sun, 26 Oct 2003 02:14:00 GMT

> So, in fast mode, am I allowed to write: Absolutely, yes. > Also, can I use a function reference (object) as a delegate? JScript .NET can coerce a function reference to an existing CLR delegate type, but provides no syntax for declaring new CLR delegate types. Unfortunately we did not have time to get that feature in. The rest of your points I'll follow up on privately.

RE: Compatibility vs. Performance

Dan Shappir — Sun, 26 Oct 2003 01:08:00 GMT

Let me try to clarify my point. .NET was design as a multi-language platform, that is one of its stated advantages over Java and the JVM. At the same time, C# is the language of choice for this platform. Thus any other language created or ported to .NET must somehow justify it existence by providing an incentive to select it over C#. I can think of several reasons for a programming language to become a viable alternative to C# : 1. A legacy programming language - easier migration and code porting. 2. Different target audience, e.g. power sacrificed for ease of use. 3. Represents a different programming paradigm, e.g. functional, logic, goal-oriented. 4. Targets a different set of problems or problem domains (a DSL perhaps). On the face of it JScript.NET falls in to the first category, yet I don't think this is the case. JavaScript has not been commonly used AFAIK for application development. The vast majority of JavaScript "programs" out there are web pages, and this is simply not .NET. Some ASP was done in JScript, but I think the changes required to port to ASP.NET, and take real advantage of that platform, are such that code reuse is not such an issue. Even if this category is valid for JScript.NET, it is the worst of the 4 to be in. The old code will be ported, but from that point on all new code will be done in C#. After all, .NET makes it easy for different programming languages to talk to each other. As for target audience - I don't think JScript.NET makes it that much easier to develop than C#. I believe that very quickly the developer will find herself writing code that is directly translatable to C# - classes, interfaces, the lot. I also don't see JScript.NET as being targeted at a substantially different set of problems than C#. It is certainly not a DSL. So what's left: the different paradigm. And herein lies my complaint. JavaScript does represent a significantly different programming paradigm than most other OO languages such as C++, Java and C#: everything is an object, objects are extensible, duck-typing all the way. JScript.NET, particularly in fast mode, lets most of this go. Thus no different paradigm - no reason for being. I may be off on all of this, and if so I’d be very happy. I am, as I professed, as JavaScript aficionado, and I would like to see this language prosper. I'm glad to hear that closures and anonymous functions are still in. Closures are what I miss most when working in C++ or Java, and just having them might make all the difference. So, in fast mode, am I allowed to write: var foo = function() { return 1; }; foo = function() { return 2; }; Also, can I use a function reference (object) as a delegate? And if so, is the closure preserved? Having closures seems to mean that you are not using stack frames in the same way as C# or VB.NET, is this the case?

RE: Compatibility vs. Performance

Eric Lippert — Sat, 25 Oct 2003 04:28:00 GMT

Jay: Unfortunately, that breaks pretty much every ASP.NET scenario and makes static analysis very difficult. I'll discuss that more later. Dan: (2) I think you're misunderstanding me. The ability to redefine a function does not make functional programming possible, and no, we did not get rid of closures or anonymous functions in JS.NET. What we got rid of was that this is not legal: function foo() {return 1;} function foo(){return 2;} That's legal in JScript classic -- it just means "discard the lexically earlier function declaration". It's also not legal to redeclare the same variable over and over again in JScript.NET but it is in JScript Classic. The reason why its legal in Classic is because the compilation model is different. Maybe I should blog a bit about that. 3) As I mentioned above, being able to modify built-ins screws up very common ASP scenarios. Also, you seem to think that we've removed prototype inheritance. We didn't remove hardly anything, we just added a whole lot of stuff. 5) The caller property was broken already -- ever tried it with recursion on the stack? It doesn't work because it was badly designed from the start. A caller isn't a function, its an activation context, but activation contexts are not first class. I'll expand on these points next week.

RE: Compatibility vs. Performance

Dan Shappir — Sat, 25 Oct 2003 01:49:00 GMT

Disclaimer: I'm very much of a JavaScript/ECMAScript aficionado. If you want to see the extent, check out http://w3future.com/html/beyondJS/ to see the BeyondJS library developed by Sjoerd Visscher and myself. When I first heard of JScript.NET I was ecstatic - here was the chance for JavaScript to make it into the big-leagues. Becoming a full-blown member of the .NET environment would allow JavaScript to go beyond browser scripting into the field of real, main-stream application development. After playing a bit with JScript.NET I have to admit I became disappointed. It seems to me that in order to play in the .NET field and provide an acceptable level of performance, JScript.NET abandons many of the features that make JavaScript such a cool and unique language. Instead it becomes something of a C# clone. Put another way: given that C# is the main language of .NET, I can't see any major reasons to pick JScript.NET over C# (and apparently I'm not the only one: http://blogs.gotdotnet.com/EricLi/commentview.aspx/cd88c241-27f4-410c-b3a4-716cae1b63db why did they choose C# and not JScript.NET?) With regards to Eric's points specifically: 1. I wholeheartedly approve of enforced var use. The only addition I would ask for is type inference not only for performance but also for verifying correctness, ML-style. 2. This is what makes functional programming in JavaScript possible. I'm guessing you also got rid of unnamed functions (lambdas) and closures. 3. The JavaScript model of object as directory is one of the cool things about it that makes it so unique. And the ability to modify the behavior of builtin objects is also an extremely powerful feature (it is what makes BeyondJS possible). By getting rid of prototypes and adding classes, JScript.NET becomes just another C++/Java/C# clone, instead of a unique and viable choice. 4. A good thing 5. But what about the caller and callee properties? To see more comments I've had about JScript.NET check out: http://www.google.com/custom?sitesearch=lambda.weblogs.com&q=jscript.net+shappir Please note that my intent is not to disparage either .NET or JScript.NET. They are both great technical achievements. My point is simple: the same changes meant to enhance JScript also robed it of its reason for being.

RE: Compatibility vs. Performance

Jay Hugard — Sat, 25 Oct 2003 01:30:00 GMT

* Built-in objects are entirely read-only. In JScript Classic it is legal to add, modify and (if you are perverse), delete some properties on the Math object, the String prototype and the other built-in objects. Glad you didn't call this "goodness". My host adds a few dozen string functions for ease of use (justify, space, repeat). I see being able to expand the built-in library as a strength of ECMAScript. It also overwrites Function.prototype.toString ;-) Sure would be nice if it were possible to enable a "mode" to add to these built-in objects, yet still get the benefits of complation.