6 ms·

JACL: JavaScript Assisted Common Lisp

62 points by register 6y ago

jandrese 6y ago
It's interesting to think what the world would look like if Netscape had decided to put Lisp in the browser instead of inventing Javascript.
- kazinator 6y ago
  I suspect that, as a synergistic, beneficial effect, HTML and CSS would be gone by now. The web could not work with Lisp for nearly a quarter century without getting a clue and jettisoning the obvious garbage. At first, pages would be written in a Lisp notation that expands to HTML (or directlyto the dom) and CSS client side. Then that would become built-in, allowing static pages to be written that way.
- JadeNB 6y ago
  One can easily imagine it going at least two ways: in one, Lisp becomes as much a lingua franca as Javascript is; in the other, people don't flock to Lisp as they did to Javascript, and so the programmatic web never takes off (which may or may not be a bad thing).
  - kryptiskt 6y ago
    People go with the VBScript support in Internet Explorer instead, and later Netscape implements support for that for compatibility and in 2020 we are all programming BASIC.
    - invalidOrTaken 6y ago
      I had a job in 2011 writing VBScript. As far as I know that company is still around This comment should not be interpreted as me saying "Wow, it was such a great language that it was still relevant in 2011!" It is more of a caution:kludges never die.
    - pjmlp 6y ago
      Plenty of people write Basic as Office macros, VB.NET, Xojo or Blitz.
  - enitihas 6y ago
    It is almost impossible to see a world where people wouldn't flock to a language due to pragmatic reasons. People didn't go to js because it was good, just because it was the only option. If you don't, your competitor would, and likely put you out of business. People didn't make so many Objective c apps because of it's capabilities, but because it was what you use to make iOS apps, and that's where the money was. There is no chance the programmatic web would have ever depended on programmer's preference for language.
    - JadeNB 6y ago
      > If you don't, your competitor would, and likely put you out of business. I think you're looking farther along the curve than I am. Before businesses considered the possibilities of the Javascript-ified web, they had to be shown the possibilities by non-commercial hackers, who aren't worried about their competitors putting them out of business, but are driven only by the desire to play with cool toys. The browser provided an easy-to-program source of cool toys. If it had been harder to program, then the hobbyists who drive later trends might have looked elsewhere, and we wouldn't have the do-everything-through-rich-Web-interfaces world in which we live today, but would find the default interface … somewhere else; who knows? (That is, I don't think anyone would ever say "I won't use the programmatic web because of Lisp; I'll hold out for Javascript", but I can imagine someone, if Javascript didn't exist, saying "it's too hard to innovate quickly in Lisp; let's find another platform where it's easier.") None of this is a prediction, just a reminder that where we are now isn't inevitably, but the end result of many many small nudges, some of which we recognise and some of which we don't.
      - enitihas 6y ago
        > The browser provided an easy-to-program source of cool toys. If it had been harder to program. It was harder to program though. The amount of gotchas in JavaScript are so high compared to many other popular mainstream programming languages of even that era, and not to mention hou could only use it in a browser, which was severely lacking in functionality compared to native APIs. So the hackers who wanted cool toys already had far better options, which goes to show even if js was much worse it couldn't have done badly. Although there is not much data that I am aware of about the early websites making cool things with javascript, if we take iOS and Objective C, it wasn't cool hackers filling the app stores with cool toys, but real businesses looking to make money. Hell, even Mosiac and Netscape didn't want to be cool toys, theh wanted to be real businesses making lots of money.
- cscurmudgeon 6y ago
  Viaweb would have bought Yahoo.
- lgessler 6y ago
  It was close to happening, too[1]: > Eich originally joined intending to put Scheme "in the browser",[10] but his Netscape superiors insisted that the language’s syntax resemble that of Java. The result was a language that had much of the functionality of Scheme, the object orientation of Self, and the syntax of Java. [1]: https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaScript https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_Java...
  - afiori 6y ago
    regarding this I always wondered why not to simply have a java-like syntax over scheme-like semantics, especially for things like confusing equality rules and truthy values. I suspect that in the end we would have gotten the same javascript with scheme syntax.
    - dreamcompiler 6y ago
      That's largely what R is. For java-like syntax over Common Lisp, see Dylan.
- pjmlp 6y ago
  Well at least it its there on WebAssembly. If you bother to implement a macro system on top of it, you can easily get your own browser Lisp.
  - dreamcompiler 6y ago
    AFAIK WebAssembly still cannot talk to the DOM. Which makes it pointless, IMO.
lgessler 6y ago
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!
- 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
So, a JavaScript assisted Common Lisp that has no demo that I can run in the browser? Or am I missing the link? It looks very interesting otherwise.
- kazinator 6y ago
  I read the paper on JACL. Unfortunately, it is too humble. My take-away message was that if I wanted some CL-like environment in JavaScript, I should probably try SLip or Valtan.

62 points by register 6y ago

It's interesting to think what the world would look like if Netscape had decided to put Lisp in the browser instead of inventing Javascript.

kazinator 6y ago
I suspect that, as a synergistic, beneficial effect, HTML and CSS would be gone by now. The web could not work with Lisp for nearly a quarter century without getting a clue and jettisoning the obvious garbage. At first, pages would be written in a Lisp notation that expands to HTML (or directlyto the dom) and CSS client side. Then that would become built-in, allowing static pages to be written that way.
JadeNB 6y ago
One can easily imagine it going at least two ways: in one, Lisp becomes as much a lingua franca as Javascript is; in the other, people don't flock to Lisp as they did to Javascript, and so the programmatic web never takes off (which may or may not be a bad thing).
- kryptiskt 6y ago
  People go with the VBScript support in Internet Explorer instead, and later Netscape implements support for that for compatibility and in 2020 we are all programming BASIC.
  - invalidOrTaken 6y ago
    I had a job in 2011 writing VBScript. As far as I know that company is still around This comment should not be interpreted as me saying "Wow, it was such a great language that it was still relevant in 2011!" It is more of a caution:kludges never die.
  - pjmlp 6y ago
    Plenty of people write Basic as Office macros, VB.NET, Xojo or Blitz.
- enitihas 6y ago
  It is almost impossible to see a world where people wouldn't flock to a language due to pragmatic reasons. People didn't go to js because it was good, just because it was the only option. If you don't, your competitor would, and likely put you out of business. People didn't make so many Objective c apps because of it's capabilities, but because it was what you use to make iOS apps, and that's where the money was. There is no chance the programmatic web would have ever depended on programmer's preference for language.
  - JadeNB 6y ago
    > If you don't, your competitor would, and likely put you out of business. I think you're looking farther along the curve than I am. Before businesses considered the possibilities of the Javascript-ified web, they had to be shown the possibilities by non-commercial hackers, who aren't worried about their competitors putting them out of business, but are driven only by the desire to play with cool toys. The browser provided an easy-to-program source of cool toys. If it had been harder to program, then the hobbyists who drive later trends might have looked elsewhere, and we wouldn't have the do-everything-through-rich-Web-interfaces world in which we live today, but would find the default interface … somewhere else; who knows? (That is, I don't think anyone would ever say "I won't use the programmatic web because of Lisp; I'll hold out for Javascript", but I can imagine someone, if Javascript didn't exist, saying "it's too hard to innovate quickly in Lisp; let's find another platform where it's easier.") None of this is a prediction, just a reminder that where we are now isn't inevitably, but the end result of many many small nudges, some of which we recognise and some of which we don't.
    - enitihas 6y ago
      > The browser provided an easy-to-program source of cool toys. If it had been harder to program. It was harder to program though. The amount of gotchas in JavaScript are so high compared to many other popular mainstream programming languages of even that era, and not to mention hou could only use it in a browser, which was severely lacking in functionality compared to native APIs. So the hackers who wanted cool toys already had far better options, which goes to show even if js was much worse it couldn't have done badly. Although there is not much data that I am aware of about the early websites making cool things with javascript, if we take iOS and Objective C, it wasn't cool hackers filling the app stores with cool toys, but real businesses looking to make money. Hell, even Mosiac and Netscape didn't want to be cool toys, theh wanted to be real businesses making lots of money.
cscurmudgeon 6y ago
Viaweb would have bought Yahoo.
lgessler 6y ago
It was close to happening, too[1]: > Eich originally joined intending to put Scheme "in the browser",[10] but his Netscape superiors insisted that the language’s syntax resemble that of Java. The result was a language that had much of the functionality of Scheme, the object orientation of Self, and the syntax of Java. [1]: https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_JavaScript https://en.wikipedia.org/wiki/Brendan_Eich#Netscape_and_Java...
- afiori 6y ago
  regarding this I always wondered why not to simply have a java-like syntax over scheme-like semantics, especially for things like confusing equality rules and truthy values. I suspect that in the end we would have gotten the same javascript with scheme syntax.
  - dreamcompiler 6y ago
    That's largely what R is. For java-like syntax over Common Lisp, see Dylan.
pjmlp 6y ago
Well at least it its there on WebAssembly. If you bother to implement a macro system on top of it, you can easily get your own browser Lisp.
- dreamcompiler 6y ago
  AFAIK WebAssembly still cannot talk to the DOM. Which makes it pointless, IMO.

lgessler 6y ago

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!

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

So, a JavaScript assisted Common Lisp that has no demo that I can run in the browser? Or am I missing the link? It looks very interesting otherwise.

kazinator 6y ago
I read the paper on JACL. Unfortunately, it is too humble. My take-away message was that if I wanted some CL-like environment in JavaScript, I should probably try SLip or Valtan.