Slashdot Mirror

Java and C# are not different languages. They are the same language - much more similar than, for example Medley Common Lisp and Franz Allegro Common Lisp, and those are two implementations which both conform to the same published specification. Java and C# have very slightly different syntax, and slightly different core libraries. But if you can read (or write) one you can read (or write) the other. The compilers work in very much the same way, and even the object code and virtual machines are similar.

Which isn't surprising. Microsoft based C# on its own implementation of Java, changing it (only) just enough to get around legal problems with Sun. It's a very sincere flattery. C# is slightly newer, so it has slightly less legacy cruft. Apart from that, you are comparing apples with apples here. If you want a more interesting comparison, compare Java/C# with Ruby, Python, Lua, JavaScript/EcmaScript or Clojure.

Global-by-default-unless-declared for variables is a recipe of disaster.

ES5 strict mode already disallows that.

If I declare a "var" inside a pair of curly braces, it should only be visible in those curly braces

The "let" keyword will fix that. It has block scope. Eventually all variables should be declared with "let".

Syntax for lambdas is overly verbose

There is still no agreement in the ECMAScript comitee about which option to take, but there are two very good proposals:
- Arrow function syntax taken from CoffeeScript: (x) -> x * x;
- Block lambdas, which allow you to treat chunks of code as data
Personally, I love arrow functions.

"new Boolean(false)" is considered true in a conditional expression..

I never heard of that particular example and trying "true == new Boolean(false)" always evaluates to false in a console. But yes, the == type coercing operand is the worst part of JavaScript. The === operator solves 99% of cases. For the 1% that it doesn't help with, ECMAScript 6 will have an "is" operator, and before that probably an Object.is() function.

While we're at it, what's up with the whole separation into primitives and objects?

I agree with you, everything should've been an object from the start. That's probably because of the Java legacy.

Global-by-default-unless-declared for variables is a recipe of disaster.

ES5 strict mode already disallows that.

If I declare a "var" inside a pair of curly braces, it should only be visible in those curly braces

The "let" keyword will fix that. It has block scope. Eventually all variables should be declared with "let".

Syntax for lambdas is overly verbose

There is still no agreement in the ECMAScript comitee about which option to take, but there are two very good proposals:
- Arrow function syntax taken from CoffeeScript: (x) -> x * x;
- Block lambdas, which allow you to treat chunks of code as data
Personally, I love arrow functions.

"new Boolean(false)" is considered true in a conditional expression..

I never heard of that particular example and trying "true == new Boolean(false)" always evaluates to false in a console. But yes, the == type coercing operand is the worst part of JavaScript. The === operator solves 99% of cases. For the 1% that it doesn't help with, ECMAScript 6 will have an "is" operator, and before that probably an Object.is() function.

While we're at it, what's up with the whole separation into primitives and objects?

I agree with you, everything should've been an object from the start. That's probably because of the Java legacy.

Global-by-default-unless-declared for variables is a recipe of disaster.

ES5 strict mode already disallows that.

If I declare a "var" inside a pair of curly braces, it should only be visible in those curly braces

The "let" keyword will fix that. It has block scope. Eventually all variables should be declared with "let".

Syntax for lambdas is overly verbose

There is still no agreement in the ECMAScript comitee about which option to take, but there are two very good proposals:
- Arrow function syntax taken from CoffeeScript: (x) -> x * x;
- Block lambdas, which allow you to treat chunks of code as data
Personally, I love arrow functions.

"new Boolean(false)" is considered true in a conditional expression..

I never heard of that particular example and trying "true == new Boolean(false)" always evaluates to false in a console. But yes, the == type coercing operand is the worst part of JavaScript. The === operator solves 99% of cases. For the 1% that it doesn't help with, ECMAScript 6 will have an "is" operator, and before that probably an Object.is() function.

While we're at it, what's up with the whole separation into primitives and objects?

I agree with you, everything should've been an object from the start. That's probably because of the Java legacy.

Crazy rules for var? Like every child object of the object in which var is declared has access to that variable?

No, the fact that it's always function-scoped rather than block-scoped, while the syntax still permits you to write it inside a block. This breaks the established rule for all C-family languages out there - in every other case, either in-block declarations are scoped to the block (C99, C++, C#, Java, D, ...), or else you can only declare variables at the outermost block in function body (classic C).

Using "let" instead of "var" is a workaround that Mozilla provides, but it's a non-standard extension which only they currently support (albeit slated for inclusion in EcmaScript Harmony).

Ultimately, what you want to do is to hide the whole call-with-continuation pattern that is the fundamental building block of async under a thick layer of syntactic sugar in the language, such that your async code looks almost exactly the same as the corresponding synchronous version, with marker keywords to identify "points of asynchrony" (where the rest of the code path is an implicit continuation, and a closure is generated for it under the hood). Kinda like this in the (yet upcoming) C# 5.0.

Good thing is that there is a proposal for this feature for the next major EcmaScript version. Hopefully it'll end up in the spec.

What you're really asking for is a way to keep tables of object-to-value.

One way a language can accomplish that, as you suggested, is for the language to supply a "hash code" function and then using the language's string-to-value hashes. But a "hash code" function has many problems. A moving garbage collector has to keep extra information around, at least for objects whose hash code has been retrieved. Any implementation that doesn't give away sensitive information (including pointers) is likely to be slow. More subtly, any implementation that prevents hash-key collisions will violate GC confidentiality. So the "hash code" function has to allow collisions, which means your object-to-value map (build on top of hashkey) has to use buckets, which make your code slow, leaky, and difficult to test.

A more straightforward solution is for the language to provide an object-to-value table type. I think this will be part of ES6 as WeakMap. Which, by the way, has excellent GC semantics.

Here's an overview of ECMAScript 4, the new version of JavaScript:

http://www.ecmascript.org/es4/spec/overview.pdf

It sure looks to me like they are taking all the coolest stuff from Python and grafting it onto JavaScript.[1] The result will be a language a lot like Python, but with code blocks wrapped in curly braces and no significant whitespace.

One of the biggest changes will be a class inheritance model much more like Python's. The prototype-based inheritance will still be available, but I for one will be happy to use the new model.

Already, my favorite features from Python have been grafted on to JavaScript, and are available right now in Firefox 2:

http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7

Steve Yegge has said that he thinks he knows what the "Next Big Language" will be. I think he is talking about JavaScript, and I think he may be right.

steveha

[1] If you are a fan of some other language, it may look to you like they are grabbing cool things from your language. And far be it from me to argue about which language a feature was "really" borrowed from. Python borrowed much of its cool features from other languages anyway.

Here's an overview of ECMAScript 4, the new version of JavaScript:

http://www.ecmascript.org/es4/spec/overview.pdf

It sure looks to me like they are taking all the coolest stuff from Python and grafting it onto JavaScript.[1] The result will be a language a lot like Python, but with code blocks wrapped in curly braces and no significant whitespace.

One of the biggest changes will be a class inheritance model much more like Python's. The prototype-based inheritance will still be available, but I for one will be happy to use the new model.

Already, my favorite features from Python have been grafted on to JavaScript, and are available right now in Firefox 2:

http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7

Steve Yegge has said that he thinks he knows what the "Next Big Language" will be. I think he is talking about JavaScript, and I think he may be right.

steveha

[1] If you are a fan of some other language, it may look to you like they are grabbing cool things from your language. And far be it from me to argue about which language a feature was "really" borrowed from. Python borrowed much of its cool features from other languages anyway.

int, uint, long - now we can deal with currencies. I never understood the lack of explicit integer types in js. What was the idea behind that?

Also, the TFA link to the ECMA site is down and does not go to an authoritative document anyway. Try http://www.ecmascript.org/es4/spec/overview.pdf

How will this affect libraries such as Dojo? My first thought is that browser support will be even more complex and make libraries more necessary.

First, ignore the ad for the blog and go directly to the language specification.

I read through that and winced. It's one of those backwards compatible hacks that makes a language ugly. Current Javascript has a class implementation based on copying a base object, but no real class abstraction. This follows the model in Self. Most other object oriented languages (C++, Python, Java) have explicit class declarations. Javascript 2.0 adds class declarations without throwing out the old mechanism. This is a mess. I understand why they were forced to that decision, but it's still a mess.

The trend continues. They threw in most of the things Python 3K has and current Javascript doesn't: type annotations, generators, and packages, and namespaces. There's type checking, but it's optional for now. (This is like the transition from K&R C to ANSI C). Java-type interfaces where thrown in. At least they didn't add templates. It's a collection of features in search of a design.

In the end, we get something that's like a mixture of Java and Python.

For those who didn't RTFA, it should be noted that Javascript 2.0 is actually ECMAScript 4.0 (ES4). Even if IE9 and FF4 supported ES4 completely, we'll still have to develop for the legacy browsers! Oy vey! Such is the life of a front-end web developer!

That being said, Flash Actionscript 3.0 (available now) includes many of the new features found in ES4 such as real classes. The next version of Actionscript will most likely be ES4-compliant.

Notable features in ES4 include:
- Classes and interfaces
- Generics
- Packages and namespaces
- Compile-time type checking
- Constants
- Operator overloading
- Record types (i.e., structs or light-weight classes)
- Typed arrays and hash maps
- Iterators
- Exceptions

More info: http://www.ecmascript.org/es4/spec/overview.pdf

Actually, ES4 does do JSON (here, or whatever spec you can actually find). Without evaluating things, because eval() sucks. See also overview PDF, top of page 39.

(Yes, I find it horribly difficult to figure out what they actually agree on, which makes trying to figure things our really hard)

Actually, ES4 does do JSON (here, or whatever spec you can actually find). Without evaluating things, because eval() sucks. See also overview PDF, top of page 39.

(Yes, I find it horribly difficult to figure out what they actually agree on, which makes trying to figure things our really hard)

One interpretation of your efforts here, in all charity, is that your employer wishes to handicap the standardized Web. As I keep saying, this is not relevant to ECMA TG1's deliberations.

The ECMAScript 4 is backward compatible. Brendan Eich:

Two languages not really credible for small systems; backwards compatibility within growth is a better choice. . . . we are maintaining compatibility.

Are you trying to tell me that the addition of new reserved words to a language is a "small" change? [(ee the ES4 overview for details.) Particularly when those reserved words are common terms like "cast"? Sorry, but that's major breakage, and not a small matter. If the default were to behave exactly as ES3 or ES4 interim, and the new restrictions only applied then, it might be a justifiable change -- but that is explicitly not what the overview says.

Sorry, but this is BS.

The overview of the current ES4 proposal is here: http://www.ecmascript.org/es4/spec/overview.pdf

Go check it out and decide for yourself.