HN: Please review my JavaScript superset, JSC.

I find this really amusing and nostalgic because our original implementation of Objective-J was very similar to this while in college, you can see what one of the iterations looked like in my "Road to Cappuccino" Ajax Experience presentation: <a href="http://280slides.com/Viewer/?user=56&#38;name=Ajax%20Experience&#38;fullscreen&#38;slide=24" rel="nofollow">http://280slides.com/Viewer/?user=56&#38;name=Ajax%20Experie...</a><p>Ultimately we decided to drop the Java-like syntax in favor of the Objective-C style syntax because we wanted the language to be both a strict superset of JavaScript and future-proof (in other words, if the class keyword or any other keyword later entered the JavaScript language, for our superset to continue working). That presentation has some more info on that, as does my abstractions post: <a href="http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractions-and-objective-j/" rel="nofollow">http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractio...</a><p>I think anyone who works on JS on large systems ultimately reaches these conclusions. That's why so many JS frameworks invent some sort of class model. I hope you find those links useful in your own endeavors. I would recommend not bothering with ECMA and just releasing something for people to play with <i>today</i>. You will get more actual useful feedback in one week than anything some committee that never actually tries using it will tell you.

"I’m not releasing JSC compiler today because I’m not satisfied with the code in the current version."<p>No one is ever satisfied with the code in the current version. If it works, open it up with suitable disclaimers. That'll put pressure on you to fix the bits you really don't like and also open the possibility that someone else might point you at the bits that need work first.

Interesting work. Some questions:<p>1) Have you have discussed your work with the current ECMAscript committee, or interacted with them at all?<p>2) Why did you choose to focus on packages and classes? Why not other stuff along the lines of where ES5/ES6 is moving currently? Are there other ways to move forward in JS Programming-In-The-Large research instead of just straight up OO extensions? In Coders At Work, Brendan Eich suggests that academic and industrial influence on ECMAScript needs to evolve hand in hand, but not just directly along the "expected" line of OO features. Do you have any thoughts on that?<p>-<p>Small note: Make sure to spell-check your paper and have a native English speaker proof-read it for you :). The first page has some errors like "witch" and "althought" and "avaible".

To answer you:<p>1) No. This was just a hacking solution that I got. ECMA already has a solution but browsers haven't implemented yet. When JS engines start implementing ECMA class system, JSC will became obsolete.<p>2) I looked to ES4 and 5 spec, but they were too extense. I wanted something more simple, that could be similar in syntax to Java-like language with some flavours of SmallTalk. My main problem was with code from the same class being scattered on several files. This led me to creating the same classes and packages concepts that exist on other languages. More so, if you never code in JS before, this syntax seems more friendly than some weird new object system.

@notauser Yeah, but I have to write my thesis until January 7 and I need to focus on that for now.