Although it does point out one reason that JS is a poor language to be the foundation for client-side web computing: It's extremely difficult to optimize a language this dynamic. I honestly think we could be leaving 50% perf improvement on the floor due to the dynamic nature of the language.

And this is on top of the fact that you already have to reduce the amount of time spent optimizing since you don't compile the code ahead of time (most optimistically using a JIT of some sort).

Can we please move away from JS and move to a nice IL?

> I honestly think we could be leaving 50% perf improvement on the floor

Unfortunately, humans have not got significantly faster (or smarter) in the last couple thousand years, as opposed to computers, that get twice as fast every 18 months or so.

Dynamic languages, by placing the burden of optimization on the compiler/runtime are making the right bet. Static-typing is little more than a human doing the machine's work, often at the expense of introducing subtler bugs (the compiler catches the obvious mistakes and that may leave programmers with a false sensation of security).

> Can we please move away from JS and move to a nice IL?

As for moving to precompiled, possibly obfuscated scripts, I would much rather concede a little less dynamism on the language and move the compiler into the browser. You could, conceivably, declare the type of arguments and return values and rather easily, in that case, perform some optimization as the code is parsed.

I have no love for JavaScript. It's a little tortured language that I am sure passed through a lot more marketing specialists than needed before taking its current form and bears the scars from that process. It has, however, some good parts that are very good.

Do you really need to be able to override the valueOf method on an integer?

Lua manages to be both dynamic, and to play with the big compiled boys on the Compiler Shootout with its JIT. I don't know the details but I suspect it is because its dynamicity is carefully designed with an eye to the cost/benefit tradeoffs, instead of always choosing to make things dynamic regardless of the costs. How much time does a straightforward implementation of a conformant Javascript interpreter actually need to spend looking up and executing "valueOf", anyhow? The vast bulk of those will be wasted.

With the nature of Javascript even "optional type declarations" are easier said than done; you not just to specify "an int", but "an int that you have not mucked with the prototype of, or any of the prototypes of the parent objects", and that's actually a declaration that intrinsically fights against the nature of the language. Actually propagating such things out will eventually create an implicit dichotomy matching the much-maligned Java difference between objects and primitive types, only in a language where it was bolted on a decade after the fact instead of at least being in there since day one (of public release).

It's an interesting enough language but it's not really suitable for use as the base level of a tech stack. Nevertheless, it will be forced into that role. (It's not like there's actually a choice of a really well-designed tech stack out there that can replace the web, it's all various incoherent pieces bashed on by monkeys until it mostly works most of the time. Not really trying to be sarcastic here, this is a realistic assessment, IMHO.)

It is a good idea to let the compiler/runtime do work for you.

But highly dynamic structures make some kinds of static analysis (which the compiler needs to do to optimize) really hard and often undecidable. We need a pretty good (hotspot like) JIT in the runtime to compensate.

Interesting. I look at (good: e.g. ML or Haskell) static typing as the machine doing the work that a human would have to do in a dynamic language. Especially type inference.

I don't write much Javascript, but I do use Python quite a bit. I'd say that most of the code I write is probably just statically typed code without declarations. That's not a bad thing, because it makes it easy to take advantage of a JIT (either psyco or pypy) or, if the JIT approach isn't fast enough, to statically compile with cython by adding declarations.

In my experience however, those cases are not many and doing it when you don't have to creates unneeded complexity.

In my experience however, those cases are not many and doing it when you don't have to creates an unneeded burden on the programmer.

(sorry -- this is probably not to HN's taste, but I just wanted to show how an entirely different perspective can also be valid)

Now I am curious: what do you do? I do mostly server-side web stuff, but I have done embedded/driver and can see situations where you really need a 3-byte unsigned integer to stay a 3-byte unsigned integer. But, apart from that, I can't imagine other cases.

Of course there is. I program more in dynamic languages (particularly JS) than in statically-typed ones, and I always keep worrying about passing representation A of some data rather than representation B. I find myself having to look at the source code of callees far more than I think I should be.

On the other hand, my academic life revolves around statically-typed languages (Haskell). The way Haskell's type system is designed means that there are entire programming paradigms that are not just available but production-ready in Haskell, but are virtually impossible in any other popular language. For a concrete example, see software transactional memory.

I'm also a huge fan of pushing as much lower-level drudgery as possible to machines to free up human minds for higher-level thinking, and a good type system combined with good type inference goes a long way.

It's interesting you feel like this with JS. I spend most of my time with Python and seldom have any doubts about what should I do. I usually make little assumptions on the type of the object I am receiving and don't think much about it.

We did Ruby first and O'Caml afterwards (we were to implement a scheme interpreter for the O'Caml project). Anyway, the impression I got was that most students hated O'Caml and loved Ruby, but while it was harder to get used to working in O'Caml I loved what the typing system did for me.

Every time I'm working in a language like Ruby and suffer from a bug a type system would have caught, it frustrates me. Perhaps for other programmers, every time they have to do extra work so the type inference works when in a language like Ruby they wouldn't have to, they get frustrated.

I prefer my frustration up front, and honestly, found that O'Caml told me, "You didn't think of this nimrod" mostly when I needed it, and rarely when it was just being a pain.

http://www.0x61.com/forum/programming-haskell-cafe-f245/is-t...

It looks like STM works better for functional languages and you have to mark shared data somehow. And then you have to mark the code that manipulates shared data somehow (so it won't prematurely launch missiles). Then you're reinvented monad.

I reserve right to be wrong so I'd like to see what are the ways for imperative languages.

edit: well, Clojure restricts mutability too, so STM is sort of tractable there, but it doesn't get the other benefits that Haskell's type system gives you.

Maybe it is, in which case this would be great it seems. Not that I have intimate knowledge of it, but still ;)

Javascript could have a "fixate foo bar qux" command that did something similar. Of course, for best results, it would need to fixate the current foo bar qux, as Javascript frameworks seem quite keen on overriding the standard functions. I'm sure it would be a pain to implement, but...

A thousand times this. The web is playing a bigger and bigger role in computing but IMO it's hamstrung a bit by having it's "assembler" Javascript. I think a lot of developers are just going to use some other language that compiles to Javascript anyway, why not give us an "assembler" option.

That's a disgusting thought...

What happens is usually developers who don't want to program in more than one language (or One True Language, as many of them may think) rely on such tools to generate an unreadable, sub-optimal and utterly messed up tangle of JavaScript code that kills a baby jesus every time it runs.

And who then blame JavaScript for their problems. And downvotes anyone who disagrees with them ;-)

I assume we have different interpretations of what's normal.

I am not sure we are talking about the same thing here. What we are talking here is you inputting Java (and the most readable Java code is not that readable to begin with) into utterly unreadable JavaScript that's also less efficient than what a human experienced in JavaScript would be able to write and larger than the minified version of whatever that experienced human would be able to write.

The thing with JavaScript is that the initial time for loading and parsing a script in the browser counts as part of the performance. This is why every implementation (except for CL-JavaScript: http://svrg.net/CL-Javascript%200.10.05.html) hasn't moved to compilers but JITs instead. So minifying JS does have some performance benefit in that it reduces load and parse time.

And no. Minification of JS would not count as code optimization in any self-respecting compsi course.

It is because every character the parser reads is a loop iteration at best, a state machine transition at worst. Minification does more than just deleting whitespace - identifiers are shortened too.

"The improvements you see must derive mostly from the size reduction and download time improvement."

The former yes because more code fits in cache and you need less time to parse it, the latter no because gzip compression does a better job than minification.

"And no. Minification of JS would not count as code optimization in any self-respecting compsi course."

This is why you learn about compilers by writing them instead of taking courses.

[People using node.js however.. ;-)]

I think the whole point of the post is to poke fun at how Microsoft is cheating the benchmark and how it was caught. The part on the definition of Angles and that the "optimizer" should throw an exception it doesn't (most probably because it's not optimizing anything) is hilarious.

What are you talking about? That code is getting optimized away into a no-op when it shouldn't be, which is why no exception is thrown. This means that

a. the optimization is definitely happening

b. it is unsound

I also think the "for beginners" in the title is somewhat directed towards whoever implemented the "optimizer".

That isn't unsoundness, that's incompleteness. An optimization being incomplete means that something that could be optimized isn't -- one being unsound means that something that shouldn't be optimized is. These terms come from mathematical logic.

Being incomplete means the code you generate is not as fast as possible. Being unsound means the code you generate may be wrong. We don't normally call an optimizer "broken" if it does not optimize something even though we can recognize the optimization could be applied - no optimizer does every conceivable thing. But generated code that is not semantically equivalent to what was given violates correctness.

The only reason to trust this code to do other optimizations well is all the evidence it's targeted at one specific benchmark.

  function add(a,b) { return a + b }

  function add1(a,b)
  {
    if(is_null(a)) throw ArgumentNullException()
    if(is_null(b)) throw ArgumentNullException()
    low_level_generic_add(a,b)
  }

Suppose further that our hypothetical language has a tracing JIT, and that most of the time when a and b are called, they're both integers. In that case, the compiler might perform the following transformation:

  function add2(a,b)
  {
    if(is_integer(a) && is_integer(b)) return add_integers(a,b)
    else return add_generic(a,b)
  }

  function add_integers(a,b)
  {
    if(is_null(a)) throw ArgumentNullException()
    if(is_null(b)) throw ArgumentNullException()
    perform_integer_addition(a,b)
  }

This has been your woefully incomplete dynamic compilation moment.