ArcLite - Arc Ported to JavaScript(jonathan.tang.name)
jonathan.tang.name
ArcLite - Arc Ported to JavaScript
http://jonathan.tang.name/files/arclite/
23 comments
It'd be interesting to see this profiled against the canonical implementation. I wouldn't be surprised if a v8-as-target Arc outperformed one targeting MZScheme, not to mention if the the coming server-side JS wave really materializes this would give Arc access to stuff emerging there, much like Clojure lives in the Java world.
It's interpreted, so I really doubt it'd outperform MzScheme Arc. Though it uses normal JavaScript objects for the stack frames (modulo some __proto__ hackery to serve as the static link), so I'm curious how well V8 can optimize that.
It seems that PLT Scheme it is still twice as fast, at least according to this language shootout.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
Along these lines, it would be cool if browsers supported some sort of "LispScript" (or at least "SchemeScript"). I hate JavaScript with a passion. This is all just wishful thinking, of course.
And yes, there is a LispScript project, but it compiles to JavaScript. I'm thinking more of a native interpreter in the browser.
And yes, there is a LispScript project, but it compiles to JavaScript. I'm thinking more of a native interpreter in the browser.
I think most people who "hate javascript", dislike working with the DOM, is that true for you? I personally think javascript is a pretty simple & beautiful language. It has its warts, but so does ruby, python, and other dynamic languages.
Yes I dislike the DOM. Maybe I it's that JS is TOO simple (or not simple enough?). I find myself having to constantly match brackets and braces. And the browsers provide little help in the area of syntax checking.
Yes, I'm aware of Firebug; it's nice (although it seems to have gotten buggier).
Yes, I'm aware of Firebug; it's nice (although it seems to have gotten buggier).
Matching brackets and braces? Your editor should do more for you.
You should try Webkit's debugger (and not chrome's). It's fast and stable. Chrome's debugger is getting there, but is still missing some basic stuff compared to webkit/firebug.
I rarely find syntax a problem though -- javascript syntax is pretty simple. You could probably write a javascript parser in one day, but it would probably take you a month to write a ruby parser.
I rarely find syntax a problem though -- javascript syntax is pretty simple. You could probably write a javascript parser in one day, but it would probably take you a month to write a ruby parser.
Prototype (like jQuery) has really easy DOM access. $$("div.className[attributeName=value]").pluck("innerHTML") does what you expect.
I do wish more IDEs would integrate JSLint. I even put it into my iPhone PHP IDE Mides.
You could try JSlint for syntax checking.
What's wrong with compiling to JavaScript? It's already widely supported and if you're compiling another language to it you can pretend like it doesn't exist.
I can understand not liking JavaScript, but hating it with a passion seems excessive. Do you really hate JavaScript or just having to deal with the issues of incompatible browsers? I prefer languages like Haskell that enforce strong static typing, but as far as runtime typed languages go I think JavaScript is pretty nice.
I can understand not liking JavaScript, but hating it with a passion seems excessive. Do you really hate JavaScript or just having to deal with the issues of incompatible browsers? I prefer languages like Haskell that enforce strong static typing, but as far as runtime typed languages go I think JavaScript is pretty nice.
I guess I would be concerned about compiling to JS because you're adding another layer of abstraction on an already fussy language (when being interpreted by the browser). It's hard enough to find bugs as it is.
I'm a big fan of Haskell, too. The type system alone makes it a wonderful language to work in.
I'm a big fan of Haskell, too. The type system alone makes it a wonderful language to work in.
I guess I would be concerned about compiling to JS because you're adding another layer of abstraction on an already fussy language (when being interpreted by the browser). It's hard enough to find bugs as it is.
On the other hand, mechanically generating the code you've abstracted away will make sure you only get the same bugs every time. ;)
On the other hand, mechanically generating the code you've abstracted away will make sure you only get the same bugs every time. ;)
JavaScript was based on Scheme with a "C-like" syntax to make it more widely appealing, so spiritually JavaScript is LispScript. More to your point, other browser scripting languages have been done and already failed. IE supports VBScript, Firefox could at one point support Python via an extension. The reality is that browser implementors want to support all sorts of things, but the only ones that matter are those that are supported in all browsers. Since you cannot create a new browser without supporting JavaScript, and JavaScript solves the code problem, it is the only language that will ever be used in browsers.
Which leads into the second question: whats wrong with compiling to JavaScript? Compilation is historically (outside of a VM) the only way to write portable code. Most compiled languages have a toolchain that covers compiling, profiling, and debugging, and there is no reason to assume that a language compiled to JavaScript could not have these as well (ex an external profiler might look like dynaTrace Ajax).
You might not like JavaScript, but its all we're going to get. Most people don't like programming x86 assembly, but I don't see them complaining that CPUs need to support a different assembly language.
Which leads into the second question: whats wrong with compiling to JavaScript? Compilation is historically (outside of a VM) the only way to write portable code. Most compiled languages have a toolchain that covers compiling, profiling, and debugging, and there is no reason to assume that a language compiled to JavaScript could not have these as well (ex an external profiler might look like dynaTrace Ajax).
You might not like JavaScript, but its all we're going to get. Most people don't like programming x86 assembly, but I don't see them complaining that CPUs need to support a different assembly language.
though I dislike having to type function() { and }); all the time, and scoping rules are a bit confusing, I've rather gotten use to it. Maybe you should read, "Javascript, the Good Parts"
http://ejohn.org/apps/learn/ Resig's js tutorial also helped hammer in why people like js and what's so special about it.
http://ejohn.org/apps/learn/ Resig's js tutorial also helped hammer in why people like js and what's so special about it.
Thanks for the pointers. I really dislike the scoping rules, and prototypes.
My brain jumps straight to a javascript port of clojure. Potentially one with a websockets bridge between some of the concurrency primitives. Set a future on the server from the browser, use the promise to update an agent on the server again, that kind of thing.
The implementation would be nine kinds of hell but it would make for a fascinating development environment.
The implementation would be nine kinds of hell but it would make for a fascinating development environment.