4 ms·

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 enviro

by wooby 6y ago

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_Manual_Oct_1983.pdf http://bitsavers.org/pdf/xerox/interlisp/Interlisp_Reference... section 1.2

didibus 6y ago
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?
- wooby 6y ago
  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.
  - didibus 6y ago
    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?
    - wooby 6y ago
      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.
      - didibus 6y ago
        That would be really cool. Will keep an eye out, good luck on your efforts.
mark_l_watson 6y ago
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.
- wooby 6y ago
  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.

by wooby 6y ago

didibus 6y ago

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?

wooby 6y ago
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.
- didibus 6y ago
  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?
  - wooby 6y ago
    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.
    - didibus 6y ago
      That would be really cool. Will keep an eye out, good luck on your efforts.

mark_l_watson 6y ago

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.

wooby 6y ago
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.