> (...) even the optimized JavaScript libraries like Box2D becomes faster when ported to JSX.
Box2D is a C++ library that has been ported to ActionScript and then, from ActionScript, converted to JavaScript - not by hand, but by a bunch of scripts[1]. The JS version of Box2D still carries around a lot of unnecessary weight from the original C++ and ActionScript versions and has much room for improvement.
A rewrite or "smart" conversion from C++ to JS, that endorses JS instead of trying to emulate C++ or ActionScript, should be able to improve performance a lot.
I don't know how Box2D was ported to JSX. Maybe it was a rewrite by a human? In any case, I'm not saying what they do isn't impressive, but calling Box2D an "optimized JavaScript library" is just plain wrong.
[1] There are several different JS ports of Box2D available, but, to my knowledge, none of which is a sensible rewrite by a human.
Probably the biggest inefficiency with all the ports is that they don't pool vectors. In the C++ version, vectors are often on the stack, which is way more efficient. In JS, it creates large numbers of temporary vectors that must be garbage collected.
For my iPad port of one of my Flash games (written in Haxe, so it was actually being translated back into C++), I spent quite a few days profiling the places that were vectors were being created the most, and modifying them to use a pool.
Then some verification code in debug mode checked that there was never a dead vector being written to or read from.
In pathological places with tons of collisions, that got the speed from 2 fps to 30.
"JSX offers a solid class system much like the Java programming language, freeing the developers from working with the too-primitive prototype-based inheritance system provided by JavaScript."
That's a weird thing to think. If you can simulate classes with prototypes, but you can't simulate prototypes with classes, what is the natural conclusion you can come to about which is more expressive or primitive?
You can't simulate most imperative programs with functional ones because writing in a functional language eliminates a vast majority of bugs due to incomplete reasoning about memory barriers and other really hard to duplicate issues like race conditions.
CHESS is an amazing piece of software precisely because it CAN simulate race conditions and reproduce them, however, if these things didn't exist no one would ever bother trying to reproduce them.
I'm quite fine not being able simulate these issues.
It is, but on the other hand if you write code to work with sockets then you get a performance boost on spinning disks because your IO is sequential. And many other benefits like trivial cache prediction, buffering, etc.
I do think that prototypes have useful properties, but I'm not sure that a prototype isn't a form of an open class. I tend to think that the biggest problem with prototypes in js is the interface.
Prototypes in JS are problematic due to false cognates- it tried to look like Java (due to marketing department fuckery), and use the same keywords as java, but it doesn't act at all like Java which leads to some nasty surprises. This has been fixed in ES5- the correct way to inherit from a prototype is no longer via constructor functions and their prototype property, but via Object.create()
Just as you said yourself: classes can be simulated with prototypes and are therefore higher level than prototypes. In other words, prototypes are lower level (more primitive) than classes.
The Gameboy color hardware can be simulated on a desktop computer in a browser, in javascript. Does that make desktop computers more primitive than Gameboys?
It's a difference of power and size, not level of complexity. In theory you could simulate a desktop computer with a browser and javascript on a gameboy color given enough processing power and memory. (without increasing instruction set complexity / requiring more abstraction levels than on a desktop / sneakily inserting more complexity in some other way)
@viraptor and so we can see that we must take into account more than just whether one can be simulated on another, we must take into account /expressiveness/, or level of complexity as well! In theory, you could simulate prototypes with classes too. You have to be able to, or else it wouldn't be possible to write an interpreter for a language which supports prototypes. The question of "can" and "can't" then, in the context of my original question has to do with the level of difficulty in doing one or the other. Now that we've got this far, what is more difficult- simulating classes with prototypes, or simulating prototypes with classes? Which requires more code, and more complexity? And from that, what do we conclude about primitiveness?
I'd still stand by the opinion that the browser in GBA is the same level of complexity as GBA in browser. They're interpreters of some code essentially (one of GBA roms, the other of html/js). There is of course a different human complexity of "how hard would it be to implement"... but if we're adding JS engine to the mix, the browser may be actually harder.
With classes / prototypes (sorry for wibbly wobbly explanation, my CS is not good enough to use the proper terms, which probably exist out there), you can pretend there's a "behaves like" relationship. To simulate a prototype using a class you have to build the freely accessible dictionary and initialisation/cloning semantics level inside of the class.
To simulate classes using a prototype... that depends on your definition of a class. Dynamic dispatch is already there, encapsulation too, subtypes just need a field specifying the name and cloning the right prototype, inheritance is on by default. Self-referencing is usually in there too.
So in my opinion classes can be substituted by prototypes in a large number of cases. Classes however need another layer on top to act like prototypes. So prototypes look like more primitive than classes and classes look like a special-cased version of prototypes. Then again, it's late here, so maybe I missed something obvious...
I htink the word you are looking for isn't actually "primative", but expressiveness.
A prototypical inheritance model can express a larger range of constructs than a class based inheritance model can, and this is normally called expressiveness. Its actually difficult to say which one is more "primative" (by your definition of primative), because they are actually both on a similar layer.
Anything I can do with a string, I could also do with an array. However, it would take extra work to make an array behave like a string, in the form of helper functions, etc.
If I really wanted to prove a point, I could make a string behave like an array. But that would take even more work because an array is a very flexible tool used for a variety of low level purposes.
Therefor, according to your argument, a string is a more primitive data type because it takes more work to make a string act like an array than it does to make an array act like a string. This goes in direct contradiction to the actual definition of a programming primitive.
Back to the original poster's quote, "JSX offers a solid class system much like the Java programming language, freeing the developers from working with the too-primitive prototype-based inheritance system provided by JavaScript."
He is quite clearly addressing a specific case here, which is programmers who want to use Java-like classes when developing in Javascript. A lot of extra work is required if you want to make a Javascript prototype behave like a Java class, with inheritance, etc. So in this context, it is obvious that Javascript prototypes are "too primitive" for the task at hand.
Similar to the way that strings are, in fact, arrays with lots of extra functions for frequently repeated, string-related tasks, JSX classes are JS prototypes with a lot of the oft-repeated boilerplate code done for you. I'm not sure how to make it more clear how the chain of "primitiveness" flows in this case.
You're kind of stretching the metaphor a bit far here. In the javascript language interpreters, prototypes are implemented with classes. In JSX classes are implemented with prototypes. In C, strings are implemented as arrays. In shell scripting, arrays are implemented with strings. All we get out of this is that whether a programming construct is low level or high level is relative to how it was implemented, and is not an intrinsic quality of the construct itself. This doesn't make any sense to me.
Something being "a primitive" is entirely based on implementation details. Not implementation details of how the language interpreters/compilers are constructed, but how you as a programmer implement things in the language in question.
A associative array might be considered a language primitive in PHP, but not in C. It is contextually dependent on the language being discussed.
Without speaking about a specific language, you cannot define something as a primitive or not in the strictly programming sense. Once you start talking about comparing two types of constructs in an abstract sense, the word primitive can only be interpreted using the English common usage, and then you are talking about an entirely different concept.
Re-reading this... It's clear what is "a primitive" in javascript. but what does "Too-Primitive" mean? The sense of the word "primitive" as in language primitive is a set, not a quantity. Something is either a primitive or it is not. there's no such thing as "too primitive"
You're right, when talking about a primitive type in the programming sense, something either is primitive or it isn't.
I took this phrase to mean that the prototype construct is "one step down on the composite type hierarchy" from what is needed to emulate as a Java-style class.
Rather, its a good building block but the necessary boilerplate code makes it "too basic" for that purpose. Therefor this developer has created a type further up the composite type hierarchy (or further away from the primitives) to accomplish his goal.
I don't think he's trying to suggest any deficiency in the expressiveness or capability of the prototype construct (he's obviously quite familiar with it to create this language). This is simply a tool for people who aren't familiar with (or don't make use of) that aspect of Javascript to be productive by utilising a more brief, or possibly more familiar (ie Java) syntax.
@olalonde that's a bit of a cop out, of course I've read that article. That is why I'm baffled by the assertion that prototypes are more primitive than classes. It doesn't add up with the definitions of what amounts to being high level and low level. If you have something more specific to say I suggest you say it, but it's pretty lame to just wave your hands at a wikipedia article and tell me to figure out something that you've obviously got wrong, from my point of view.
Prototypes are a primitive data type of Javascript (a basic building block). Classes are not offered natively and have to be constructed with lower level building blocks such as prototypes. This is why classes are said to be higher level than prototypes in Javascript. Does that help?
Do you think that is the sense of the word "Primitive" intended by the author of JSX? In that sense of the word, what does "More" primitive or "Too primitive" mean? I would have thought something was either a primitive or it wasn't- not a sliding scale.
I find it hilarious that olalonde appears to be turning your condescending use of socratic irony back on you by treating you as the "ignorant student" that you pretend to be, and then not only do you not pick up on it, you actually get offended! Brilliant.
There was no question that he was asking me to answer. He just told me that I was confused and pointed me at an article. He didn't say what he thought I was confused about. There was no obvious conclusion he was attempting to lead me to. There was no new evidence he was presenting. It's probably an mistake to read offense into text. There is no way for you to know whether I was offended or not. In this case I was not offended, I was pointing out that his reply was devoid of content, and lacking in effort. Likewise if you want to read condescension into my text, that's up to you, but has nothing to do with anything I wrote.
Your arguments all tend to make sense when using the English common usage of the word primitive, because I believe that JS prototypes are possibly more advanced than Java classes.
However, speaking solely about the language Javascript, I think it's also fairly clear that in Javascript a prototype is a language primitive that you would use to build a Java-like class construct. Therefore in this context, according to the programming term primitive, prototypes are clearly "more primitive".
It doesn't matter what the Javascript interpreters are doing behind the scenes, because all we care about is Javascript as a language, and what building blocks are available there.
Your use of the word primitive does not seem to logically match the definition of the word provided in the Wikipedia article (admittedly not the best reference for programming concepts), which is why I believe the link was entirely warranted.
And just as a side note, it is entirely possible to be condescending without consciously intending to be.
As a side note, when a human communicates something there is an intent and an interpretation. If the two don't match up, do you defer to the intent, or the interpretation as the correct meaning?
@viraptor (i can't reply directly to messages sometimes for some reason. is it a karma thing?) , So, what you are saying is that if you want to simulate A in B, but B needs an abstraction layer to simulate A, while A can simulate B more directly and naturally, that makes A more primative? So then does that mean that C is more Primitive than Assembler?
@j_baker I do not agree that prototypes are primitive and I decided to express this in the form of socratic irony.
@fleitz Whether prototypes are overly complex is neither here nor there. the question is whether they are primitive. More primitive than classes- something which is historically and demonstrably untrue, in my opinion.
It would seem as though prototypes are the more expressive option if you can use them to simulate classes. In fact, one could argue that this is essentially what Python does.
...but the OP seemed to indicate that prototypes were "primitive", and it sounds like you agree with him. Are you trying to say something that I'm missing?
> JSX performs optimization while compiling the source code to JavaScript. The generated code runs faster than an equivalent code written directly in JavaScript.
This is just absurd. It is claiming it will run faster than JavaScript ... by compiling to JavaScript. If generated JavaScript code would run faster, it just mean the JavaScript code could have been written better in the first place. They probably have logic optimization behind the scene, but clamming it will run faster that JavaScript is just ridiculous.
CoffeeScript makes the exact same claim, right on their front page (emphasis mine):
"The compiled output is readable and pretty-printed, passes through JavaScript Lint without warnings, will work in every JavaScript runtime, and tends to run as fast or faster than the equivalent handwritten JavaScript."
This is not absurd at all, it has been a proposition made by many languages in the past regarding their target. In fact it's kind of the whole point of an optimizing compiler. Whether its C being turned into better ASM than you'd write by hand, or CoffeeScript being turned into better JavaScript than you'd write by hand, the basic idea is the same. Of course you could theoretically just write the better ASM/JavaScript/whatever yourself, but the point is that usually how to do so is not obvious or not worth your time. If the average programmer's output ends up more performant with your compiler, then the claim is fair.
There are certain javascript constructs and memory usage strategies which are known to harm performance- and a compiler can ensure that your code does not use any of these constructs. While you can't make this claim for any arbitrary code, it's not completely absurd.
EDIT: The above Dart code currently generates 445 lines of JS with comments and readable formatting. Obviously it's not quite where it needs to be but it's coming along quite well.
Those are pretty unimportant metrics. Especially given that Dart's eventual intended usage is not to be compiled to JS and the infamous example you cite is strikingly unfair . The real world is much, much, much, much less code.
Besides taking something like "5 lines vs 8 lines for a hello world" and acting as if ALL code bases are automatically that much more bloated via a percentage like that is silly at worst, disingenuous at best.
Is it weird that I'm happy this site doesn't have a lot of pretty gradients and fancy art? For whatever reason I'm a little tired of too pretty sites related to JavaScript or other client side development. I think the reason for this is because I get the impression that the contributors emphasize trivial features and care more about artificial things, like a really opinionated interface but not a lot of innovation in performance.
It's like the bike shed concept. Anyone can paint a bike shed, but it takes real skill and hard work to build a decent one. It's great to have a nice coat of paint, but the accomplishment wasn't picking the color. That's how I feel about ember.js's website, and the website for all these other client side things with fancy buttons, large web fonts and gratuitous use of space. It's probably a pretty coat of paint, but I doubt I can get efficiently achieve 200,000 datastore operations with speed.
Looks quite good. Very similar to AS3, although it has the type inference of Scala. Nice. Either way something like this needs to exist to produce more robust code when creating large projects in Javascript. Google did this in using Java, but Java is overly restrictive. Being able to mix static (to a compilers checks + self-documentation) & dynamic (e.g. write parsing code more easily) typing is the future. This either/or approach is antithesis of what's good in CS.
here is a recent hacker news thread about a very similar (and in my opinion much more interesting and useful) project called LLJS http://news.ycombinator.com/item?id=3965713
Looks like ActionScript, which is already based off ECMAScript...why not just use that, or extend what's already there? Getting adoption for a brand new language is tough, plus there's already a ton of software/libraries/tools written in As3
ActionScript running directly in the browser could be interesting. It has some cruft (much of it shared with JS due to the ECMAScript heritage), and the ECMAScript lineage leads to some weird features (e.g., typically its class-based inheritance is used, but it does include prototype inheritance), but it's not a bad language.
I agree We should also take periods out of sentences They aren't needed as long as you capitalize the first letter of every sentence This makes things much cleaner
Odd, I had no problem reading your comment. It also has an unusual clean-ness.
Maybe period-less sentences are the future Throughout history english has already had many typological changes From a DRY stand-point capitalization and periods contain the same information payload Eliminating one of them would thus be good software engineering Right?
I didn't notice there were no periods till I finished reading and then had a "hey, wait a second" glance back This is an experiment worth trying out: just write everything in this style for a while
The main problem I see here is figuring out whether a new sentence has been started when a Proper Noun or capitalized pronoun like "I" has been introduced I provide the current sentence as an example of that It's not so hard to figure out from context usually, but I'm sure there are easily constructed cases where the meaning changes based on the period Then again, much of the English language is like that
This is a cognitive problem. I also read you as doing a "double-take", even though you clearly wrote "triple-take". Another cognition issue. The unthinking mind reacting automatically without consulting our conscious. The solution is obviously to augment our brains with computers. :)
I think they make the types read better, personally, especially if you leave out the space to the left-hand side of the ':'. It clearly signifies to the reader where the code is entering the type grammar. And if you leave out both the spaces to the left and the right of the ':' (as OCaml code often does), it's exactly as many characters as the version with spaces.
I was hoping it was because they allowed `(x, y, z: int)` as syntax sugar (like OOC does)... but no, they don't. In that case the : is a bit pointless.
Faster: a language change is not worth performance < an order of magnitude. Safer: unit tests; user input is only one type. Easier: prototypal inheritance is not a bug.
Box2D is a C++ library that has been ported to ActionScript and then, from ActionScript, converted to JavaScript - not by hand, but by a bunch of scripts[1]. The JS version of Box2D still carries around a lot of unnecessary weight from the original C++ and ActionScript versions and has much room for improvement.
A rewrite or "smart" conversion from C++ to JS, that endorses JS instead of trying to emulate C++ or ActionScript, should be able to improve performance a lot.
I don't know how Box2D was ported to JSX. Maybe it was a rewrite by a human? In any case, I'm not saying what they do isn't impressive, but calling Box2D an "optimized JavaScript library" is just plain wrong.
[1] There are several different JS ports of Box2D available, but, to my knowledge, none of which is a sensible rewrite by a human.