Hacker News new | ask | show | jobs
by Touche 3446 days ago
It is a sign of the quality of the language. No amount of money can make a square peg fit into a round hole.

Lua is better optimized because it is smaller. It's been the right decision to keep Lua small given where it specializes. Given where JavaScript specializes it's been the right decision to not keep it small but to evolve it. JavaScript is big because it can be big; it has the resources to make it so.

You're wrong.
1 comments
tps5 3446 days ago
> It is a sign of the quality of the language. No amount of money can make a square peg fit into a round hole.

I think this is fundamentally wrong. I think you're confusing the language itself with how the language has been implemented.

Speed is entirely separate from the language. It's possible to write two different JS interpreters: one very fast and one very slow, both of which meet the language standard set by ECMA.

These days JS generally gets JIT compiled and a tremendous amount of work has gone into improving the popular compilers. Lots of tricks are involved. These tricks are quite clever (though sometimes inelegant) and result in significant speedups. But they have nothing to do with the language itself.

link
jessaustin 3446 days ago
Speed is entirely separate from the language. It's possible to write two different JS interpreters: one very fast and one very slow, both of which meet the language standard set by ECMA.

If so, you're basically agreeing with parent, in parent's disagreement with this from further upthread:

JS semantics are garbage... for optimizations

link
tps5 3446 days ago
Yeah, in retrospect I responded without thinking.

Of course the semantics of a language can impact how easy/hard it is to write a fast implementation for that language. And as far as I know, there isn't anything special about the ECMA specification that makes it any harder to speed up compared to other languages in the same space (dynamic languages, whose specifications were written with an interpreter approach in mind).

Still, in my mind, speeding up any sufficiently dynamic languages with eval and metaprogramming without straying at all from the language spec is like "fitting a square peg inside a round hole." And I think that has been done successfully with JS, at the cost of making it harder to reason about how the compiler is going to treat my code.

link
Dylan16807 3446 days ago
Most code isn't using eval. It's okay if that part is slow. But even the most basic operations in javascript have all sorts of weird hooks that slow down evaluation. Most of it is little to no benefit to the programmer while a huge pain to the implementation.
link