> JS is a poor language to be the foundation for client-side web computing
> 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.
This is a false dichotomy. You can have a dynamic language that isn't as insane to optimize for as Javascript (or Python).
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.)
> Dynamic languages, by placing the burden of optimization on the compiler/runtime are making the right bet.
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.
> Static-typing is little more than a human doing the machine's work
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 was going to write the exact same thing. As long as I don't have to explicitly declare the type of variables and functions, I don't really care whether it's because the compiler infers the types or because the language is dynamic.
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.
Unless you intend to strictly enforce types (rather than validity) on your dynamic code, there is no burden on the developer.
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.
Unless you intend to strictly enforce types (rather than validity) on your dynamic code, there is no burden on the developer.
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.
I am not familiar with Haskell typing - Haskell is on my "languages to learn" list right after Clojure. I just need an excuse to move it up. Lately I bumped the project in favor of a "learn to use Google's App Engine" project.
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.
Do look at Haskell whenever you can. Haskell (and ML/F# to an extent) pushed me from the "static typing is a PITA" camp to the "static typing done right is a magnificent benefit to programming" camp.
I wonder to what degree this depends on the individual programmer. I had a class in University that used both Ruby and O'Caml (only the more functional aspects allowed for use there) for different projects.
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.
I quote Simon Peyton-Jones: "STM requires runtime logging of every memory read and write. In an imperative language (such as C#), in which the very fabric of computation involves reads and writes, STM is bound to be expensive. [Lots of work has been done to omit redundant logging based on program analysis, but it's still expensive.] When do you need readTVar/writeTVar? Answer, precisely when you are manipulating state shared between threads."
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.
With the same performance, static protection against irreversible side-effects, and clever aversion of the privatization problem? I'm not aware of any. While STM can be theoretically done in any memory-safe imperative language, Haskell -- mainly because of its purity and type system -- seems to be the only language in which it can be fast enough and correct enough for practical use.
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.
Static typing (and especially type inference) is useless in a web scripting language. Every time you load a new script, you would have to re-compile all the previously loaded scripts as a unit, and in the worst case throw away all existing state (pretty much equivalent to reloading the page).
Comments
> JS is a poor language to be the foundation for client-side web computing
> 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.
This is a false dichotomy. You can have a dynamic language that isn't as insane to optimize for as Javascript (or Python).
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.)
> Dynamic languages, by placing the burden of optimization on the compiler/runtime are making the right bet.
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.
> Static-typing is little more than a human doing the machine's work
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 was going to write the exact same thing. As long as I don't have to explicitly declare the type of variables and functions, I don't really care whether it's because the compiler infers the types or because the language is dynamic.
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.
There are cases when it makes sense to use static typing or, at least, to stick to certain types for input and output.
In my experience however, those cases are not many and doing it when you don't have to creates unneeded complexity.
There are cases when it makes sense to use dynamic typing (e.g. dealing with XML and friends).
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)
Unless you intend to strictly enforce types (rather than validity) on your dynamic code, there is no burden on the developer.
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.
Unless you intend to strictly enforce types (rather than validity) on your dynamic code, there is no burden on the developer.
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.
I am not familiar with Haskell typing - Haskell is on my "languages to learn" list right after Clojure. I just need an excuse to move it up. Lately I bumped the project in favor of a "learn to use Google's App Engine" project.
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.
Do look at Haskell whenever you can. Haskell (and ML/F# to an extent) pushed me from the "static typing is a PITA" camp to the "static typing done right is a magnificent benefit to programming" camp.
I wonder to what degree this depends on the individual programmer. I had a class in University that used both Ruby and O'Caml (only the more functional aspects allowed for use there) for different projects.
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.
I don't understand why you need monads to get STM. orElse is neat, but there are other ways to do the same thing in imperative languages.
I quote Simon Peyton-Jones: "STM requires runtime logging of every memory read and write. In an imperative language (such as C#), in which the very fabric of computation involves reads and writes, STM is bound to be expensive. [Lots of work has been done to omit redundant logging based on program analysis, but it's still expensive.] When do you need readTVar/writeTVar? Answer, precisely when you are manipulating state shared between threads."
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.
Oh, tons of work has been done in trying to bring STM to imperative languages, most notably with STM.NET (which is what SPJ's referring to there).
With the same performance, static protection against irreversible side-effects, and clever aversion of the privatization problem? I'm not aware of any. While STM can be theoretically done in any memory-safe imperative language, Haskell -- mainly because of its purity and type system -- seems to be the only language in which it can be fast enough and correct enough for practical use.
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.
Static typing (and especially type inference) is useless in a web scripting language. Every time you load a new script, you would have to re-compile all the previously loaded scripts as a unit, and in the worst case throw away all existing state (pretty much equivalent to reloading the page).