

HN: Please review my JavaScript superset, JSC. - arturventura
http://www.surf-the-edge.com/?p=80

======
tolmasky
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:
[http://280slides.com/Viewer/?user=56&name=Ajax%20Experie...](http://280slides.com/Viewer/?user=56&name=Ajax%20Experience&fullscreen&slide=24)

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: [http://cappuccino.org/discuss/2008/12/08/on-leaky-
abstractio...](http://cappuccino.org/discuss/2008/12/08/on-leaky-abstractions-
and-objective-j/)

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
_today_. You will get more actual useful feedback in one week than anything
some committee that never actually tries using it will tell you.

------
notauser
"I’m not releasing JSC compiler today because I’m not satisfied with the code
in the current version."

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.

------
Maciek416
Interesting work. Some questions:

1) Have you have discussed your work with the current ECMAscript committee, or
interacted with them at all?

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?

-

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".

------
arturventura
To answer you:

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.

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.

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

~~~
thwarted
Please leave the lack of threaded conversations on twitter -- use the reply
link under each comment when replying to a comment.

