Live data from Hacker News

JavaScript is Dead. Long Live JavaScript

peter.michaux.ca

31–40 of 69 posts

Re: JavaScript is Dead. Long Live JavaScript

#31
post #26

Earlier quoted context omitted.

Yeah, javascript's prototypal inheritance is flexible enough to simulate classical inheritance. I wouldn't call that a wart. http://www.prototypejs.org/learn/class-inheritance http://dojotoolkit.org/reference-guide/dojo/declare.html Plus, I tend to prefer prototypal inheritance to classical inheritance. I do agree that the constructor pattern using the new keyword and the prototype object is a bit odd, but that's not…

The wart is that since classical inheritance isn't built into the language, we get: 1) Crummy syntax. 2) Everybody doing it a different way.

I see your point to some extent. I don't think the functions for mimicking classes provided by libraries like Prototype and Dojo have particularly crummy syntax. But since there isn't a standardized way to create classes, implementations are usually a little different.

Still, according to this logic, any language that doesn't support classical inheritance has warts. I'm not sure I agree with that. JavaScript doesn't have classical inheritance built in, but I haven't seen anything to make me think that it's really needed from a programming standpoint. Your point #2 is valid, but could that can be attributed to the programmers who use the language rather than the language itself?

Re: JavaScript is Dead. Long Live JavaScript

#32
post #18

What happened to the idea of standardising Mono (the open source .NET) bytecode as a new browser language? Then you can use whatever java-like/basic-like/functional-like language you want, and have it compile to bytecode. Also, with sophisticated JITs for that style of bytecode already lying around, you could probably instantly beat javascript's performance even under the best engines, because of static typing etc. r…

1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. 2. I don't think anyone but Microsoft would support .NET bytecode in the browser, simply because Microsoft controls .NET and has patents on it. It would take a lot more to reassure other browser vendors than Microsoft's existing CPs. 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on…

>> 1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all... >> 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on Mono (or the JVM for that matter), and compare them to native implementations of dynamic languages, in particular JavaScript and Lua. The native implementations beat dynamic languages on Mono by a large margin, simply because .NET is a bytecode made for static languages.

It's not fair to compare JavaScript, which is already approaching a limit of how fast it can go, with the speed it gets running in Mono. Why? The two implementations have a vast difference of amount of energy and resources thrown at them; had Google, Mozilla, and Microsoft wanted JS to run fast on Mono, it would run fast on Mono.

Also saying that .NET is a bytecode made for static languages is kind of iffy now that the "Dynamic Language Runtime" is a part of .NET

Re: JavaScript is Dead. Long Live JavaScript

#33
post #4

He calls inheritance in Javascript a wart. It's one of its major strengths, IMO: the fact that you can directly override methods for a single object. Class inheritance, as he'd like to see, is not all it's cracked up to be. Just look at Java with its anonymous inner classes, for one incredibly ugly construct... BTW an easy way to produce traditional class inheritance in Javascript is to have a single instance from th…

Yeah, javascript's prototypal inheritance is flexible enough to simulate classical inheritance. I wouldn't call that a wart. http://www.prototypejs.org/learn/class-inheritance http://dojotoolkit.org/reference-guide/dojo/declare.html Plus, I tend to prefer prototypal inheritance to classical inheritance. I do agree that the constructor pattern using the new keyword and the prototype object is a bit odd, but that's not…

I've used both methods of inheritance.

Prototypical inheritance in the IO Language is a beautiful thing.

Not so much in Javascript.

Class based inheritance in Smalltalk and its dynamic mind-children Python and Ruby are similarly elegant and flexible. Not so much in C++ or Java.

The problem isn't with Prototypical inheritance, its with the implementation of it in Javascript.

Re: JavaScript is Dead. Long Live JavaScript

#34
post #32
post #18

Earlier quoted context omitted.

1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. 2. I don't think anyone but Microsoft would support .NET bytecode in the browser, simply because Microsoft controls .NET and has patents on it. It would take a lot more to reassure other browser vendors than Microsoft's existing CPs. 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on…

>> 1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. http://shootout.alioth.debian.org/u32/benchmark.php?test=all... >> 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on Mono (or the JVM for that matter), and compare them to native implementations of dynamic languages, in particular JavaScript and Lua. The native implementations bea…

He's wright, apart from pidigits the V8 execution is within the same order of magnitude as a Mono execution.

Re: JavaScript is Dead. Long Live JavaScript

#35
"Optional Parameters and Default Values"

Since JavaScript will still invoke a function call even if the number of arguments don't match up, parameter defaults will not completely eliminate all the problems he lists.

  function(a = 1, b = "Smith", option = {}) { .. }
Will still break upon trying to invoke it without parameter 'b' since param 'option' will just take its place while option will become an empty object.

Furthermore he argues against "option = option || {};" only to do the same thing in the function header: "function(a, b, option = {}) { .. }"? What difference does that make?

The whole section in my opinion is negated by passing object literals to functions. Stuff like:

  func({ a: 1, b: "Smith", option: { .. });
That makes it easy to read and easier to handle since names are agreed upon by both the caller and the function handling the invocation:

  var opt = config.option || {};
This is a common practice in JavaScript already, and it beats the solutions he wished were added to the language.

Re: JavaScript is Dead. Long Live JavaScript

#36
post #32
post #18

Earlier quoted context omitted.

1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. 2. I don't think anyone but Microsoft would support .NET bytecode in the browser, simply because Microsoft controls .NET and has patents on it. It would take a lot more to reassure other browser vendors than Microsoft's existing CPs. 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on…

>> 1. JavaScript's speed is actually not far from Mono's now. And constantly getting closer. http://shootout.alioth.debian.org/u32/benchmark.php?test=all... >> 3. Running dynamic languages on Mono is slow. Look at the speed of all the dynamic languages on Mono (or the JVM for that matter), and compare them to native implementations of dynamic languages, in particular JavaScript and Lua. The native implementations bea…

1. The Alioth results are not necessarily final - they compare a single JS engine, and we have several fast ones now (SpiderMonkey with type inference can be significantly faster on some benchmarks, for example). Even so, the median speed there is 2X, which is fairly close. Admittably there are some bad cases though, in particular pidigits (badly written benchmark code? bug in v8?).

2. It is true that JS on Mono has had far less work done, and that the DLR exists. However, the fact remains that dynamic languages are a late addition to the JVM/.NET model. For example, one very important thing for dynamic language performance is PICs, and to my knowledge there is no good example of fast PIC performance on the JVM or CLR. In fact, we don't even have a good example of a generic virtual machine that can run multiple dynamic languages fast (Parrot exists, but is not that fast) - all the fast dynamic language implementations are language-specific, so it shouldn't surprise us that VMs built for static languages don't do that well either.

Re: JavaScript is Dead. Long Live JavaScript

#37
post #19
post #14

Earlier quoted context omitted.

CoffeeScript allows loops no? Therefore it is turing complete (practically).

Practically you need some desicion making control structure (cond, if) and an emulation of read/write tape (arrays)

Well actually unbounded recursion and infinite memory is what is required for turing equivalence. Conditioning can be present in a non turing complete language. I added the practically because all computers on which language models are built on are finite. It is easier to get turing completeness than to ensure you haven't accidently allowed it to sneak in - as evinced in C++ templates.

http://en.wikipedia.org/wiki/Primitive_recursive_function#Co...

Re: JavaScript is Dead. Long Live JavaScript

#38
post #14
post #12

Earlier quoted context omitted.

I hope someone writes a decompiler for one of these supra-JS languages (not sure if CoffeeScript is Turing-complete) to run against existing Javascript codebases. It could well speed up adoption if a mass-tangle of JS can be boiled down to a more readable and understandable structure.

CoffeeScript allows loops no? Therefore it is turing complete (practically).

I was giving a simple metric by which to check turing completeness. If the language allows you to do infinite loops e.g. "while loops" then it is turing complete.

Re: JavaScript is Dead. Long Live JavaScript

#39
post #12
post #5

I tend to agree that compiling to JavaScript is the future of browser programming. CoffeeScript seems to be a nice language, but I bet there will be many more to come in the next year or two.

I hope someone writes a decompiler for one of these supra-JS languages (not sure if CoffeeScript is Turing-complete) to run against existing Javascript codebases. It could well speed up adoption if a mass-tangle of JS can be boiled down to a more readable and understandable structure.

Not sure if that's what you meant, but there is already JavaScript to CoffeeScript compiler: http://ricostacruz.com/js2coffee/

Re: JavaScript is Dead. Long Live JavaScript

#40
post #27

Why not just have a library in Javascript, for example: Q.each(arr, function(i) { this.rocks(); arr.pop(); // watch out doing this in the loop arr.push('foo'); // watch out doing this in the loop }); Q.each(obj, function(k) { this.rocks(); delete obj[k]; // should be safe maybe }); var p = Q.pipe(crazy stuff involving pipes and callbacks) doSql("SELECT * FROM users", p.fill('users')); getUsers = Q.getter(getUsers); /…

Features that can be added through libraries should be added that way. You cannot add new syntax which involves scoping of variables through libraries. How would you do destructuring assignments with a library and have it as succinct as it can be done with syntax?

Yeah, some features can be pushed into the language, but I like languages which have few rules. Like C and like CHESS :)

My favorite languages are C, Java and Python though. So go figure...

Post reply on HN