Hacker News Reader

Comment by lgessler | Hacker News Reader

When I saw this I thought "I wonder why someone would make a JS-hosted Lisp when ClojureScript exists and is used widely." I then found that the author has had significant involvement in the Clojure community, which piqued my curiosity even more. Alan, if you're reading this, I'd be interested to hear about why you're pursuing this project!

View on HN

Hi, thanks for your interest. The main thing I'm after is a "residential" [1] Lisp development system, where applications and tools co-evolve in the same environment.

Most contemporary compile-to-JS languages target the browser, but do not inhabit it. I'm excited about a system that encourages apps and tools to evolve organically together, instead of tools developing separately from applications, which is the status quo.

Other than that, Common Lisp has some really interesting capabilities relative to ClojureScript, and is also fun!

1:http://bitsavers.org/pdf/xerox/interlisp/Interlisp_Reference... section 1.2

I do think Common Lisp is fun and different form Clojure, and it's cool to see it in the browser as well, and I totally support that effort.

But, with regards to your description of inhabiting the browser, what would differ with JACL say compared to self-hosted ClojureScript?

The JACL reader is asynchronous, and so JACL can read characters from external sources (in-browser REPL, DevTools connection, websocket, experimental File API) without blocking the event loop and without relying on an external tool. JACL app artifacts will be created by dumping the Lisp image using a Lisp function.

Other than these technical differences, there seems to be a difference in "philosophy of use". I have the sense that the ClojureScript project does not emphasize or particularly support the idea of using self-hosted ClojureScript to build web apps.

Hum, I see. Yes, the maintainers of ClojureScript believe the bundle sizes would be too big if you always had to include the compiler with the APP. (also because the Google Closure compiler JS implementation is not as full featured as the Java one)

But it sounds in your case, maybe that can be removed before shipping? But used while developing?

Yes. My plan is for the image dumping facility to support tree-shaking and direct linking. I think tree-shaking by itself might produce reasonably-sized images, for my purposes at least. If not, the direct-linking would make Babel/Google Closure applicable.

That would be really cool. Will keep an eye out, good luck on your efforts.

Sounds good to me!

Are you thinking of something like Amber Smalltalk? Amber is a complete development system, well worth experimenting with if you have not already done so. Good ideas should be shared.

Thanks for your interest and the pointer to Amber. I'll check it out. With JACL I hope to find a good balance of internal vs. external development tools, without necessarily ruling out either by design.

Reply on news.ycombinator.com