JACL: JavaScript Assisted Common Lisp | Hacker News Reader

JACL: JavaScript Assisted Common Lisp

tailrecursion.com

62 pointsregister27 comments

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.

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.

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.

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

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.

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.

Plenty of people write Basic as Office macros, VB.NET, Xojo or Blitz.

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.

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

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

> just because it was the only option

initially, it wasn't - MS had vbscript in IE

js as 'the' browser language is a consequence of the browser wars

Viaweb would have bought Yahoo.

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

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.

That's largely what R is. For java-like syntax over Common Lisp, see Dylan.

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.

AFAIK WebAssembly still cannot talk to the DOM. Which makes it pointless, IMO.

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.

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!

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