5 ms·

There are too many incomplete lisp-on-js solutions. No, CLJS doesn't count. It would be so awesome if one ever made it to actual usable maturity. Is it too har

by hashkb 7y ago

There are too many incomplete lisp-on-js solutions. No, CLJS doesn't count. It would be so awesome if one ever made it to actual usable maturity. Is it too hard? Is there something that makes everyone give up? Or is lisp just too academic for most people to care?

Turing_Machine 7y ago
If you include Scheme under the heading of Lisp, BiwaScheme is pretty darned good. https://www.biwascheme.org/ https://www.biwascheme.org/
- hashkb 7y ago
  I do. Checking it out.
  - aidenn0 7y ago
    I find it somewhat arbitrary that you accept scheme but not clojure as a lisp.
    - hashkb 7y ago
      I accept Clojure as a lisp. Didn't mean to start a holy war. I just don't personally want to deal with it and its ecosystem, which includes Java. I need your average web developer to be able to clone the repo, run yarn, and go.
      - slifin 7y ago
        I understand your point, CLJS is a superset so it's ideal to understand the substrate that it's based on, it's more complex than just JS from that point of view but usability wise: lein new re-frame myapp lein run or git clone https://github.com/jacekschae/shadow-reagent.git && cd shadow-reagent yarn install yarn dev It is very much fire and go in a way that a typical JavaScript developer might grok
      - aidenn0 7y ago
        Ah, I don't use CLJS, and I had thought it was self-hosting.
- madmulita 7y ago
  I don't think I ever saw it mentioned in HN, but Hop[1] based on Bigloo[2] seems so much more than just a Scheme to Javascript. If I'm not mistaken, Hop (now hop.js) could even compete in a lot of use cases with Electron. [1] http://hop.inria.fr/home/index.html http://hop.inria.fr/home/index.html [2] http://www-sop.inria.fr/mimosa/fp/Bigloo/ http://www-sop.inria.fr/mimosa/fp/Bigloo/
slifin 7y ago
Why doesn't CLJS count?
- hashkb 7y ago
  Because I don't want Clojure. It's too opinionated. Also CLJS has (had? been a minute) painfully slow tooling.
  - chrisjc 7y ago
    I think his question is why is CLJS an incomplete lisp-on-js solution? Not why you don't like or use it.
    - iLemming 7y ago
      I completely disagree with that assessment. Disclaimer: I've been doing front-end for a long time. I've tried all sorts of ways to transpile/compile/deal with Javascript. I've tried Coffeescript, Typescript, Babel, Traceur, Fay, Haste, GHCJS, looked into Elm, Purescript and Reason, KotlinJS and ScalaJS. Clojurescript is one of the most stable and better choices for writing production-ready web-apps. Clojure, currently is the most widely used Lisp dialect in the industry. Lots of people trying it and find it massively productive. Just because some lispers "don't like it", doesn't make it less valuable technological choice.
      - armitron 7y ago
        "Clojure, currently is the most widely used Lisp dialect in the industry." Citation needed. I would bet money that this isn't true. There are a lot of places using proper Lisps that stay out of the public eye.
        yogthos 7y ago
        It's quite rare to see postings for CL jobs, yet plenty of companies are actively using and hiring for Clojure. It's certainly a far more popular choice for green field development nowadays. Sounds like you're the one who needs to provide citations here and not the other way around.
deleted 7y ago
[deleted]
aidenn0 7y ago
1. Common Lisp is a fairly big specification for a lisp 2. People doing webdev in lisp have solutions that work "well enough" for them. 3. It's not obvious how to compile a lot of commonly used CL constructs into efficient javascript. Discarded multiple values, for example, are extremely efficient on bare-metal implementations, but will have measurable overhead when not inlined in any javascript implementation.
- taeric 7y ago
  I'm curious why the same tricks can't be used on discarded multiple values?
  - phs2501 7y ago
    If I recall correctly they typically involve manipulating the execution stack; that's not something you can do in JS obviously.
    - taeric 7y ago
      Fair. I was assuming you could do something at the evaluation layer that was somewhat equivalent. But it makes sense the bare metal ones are doing something at the machine code layer.
Scarbutt 7y ago
Maybe this is the one. IMO, Babeljs could be leveraged to create one much faster.
- hashkb 7y ago
  My thoughts are along these lines, too. If it's not incrementally adoptable in webpack/etc projects, it won't see significant adoption.
rini17 7y ago
It could be done using WebAssembly. But AFAIK all existing Common Lisp implementations want to manipulate the stack in ways that WASM disallows.
- register 7y ago
  Can you be more specific about the peculiar way in which CL manipulates the stack? Where to find more details about CL internals?
  - rwallace 7y ago
    In CL, if you catch an exception, you have the option of trying to fix the problem and then letting the code continue from where it left off. This is only moderately difficult to implement in machine code, but somewhere between problematic and impossible on a high level platform that has already implemented exceptions by stack unwinding.
- pjmlp 7y ago
  There is schism if you are into Schemes, but it does rely on experimental support for tail calls and reference types. https://github.com/google/schism https://github.com/google/schism https://www.youtube.com/watch?v=V7IxiMjKWZM https://www.youtube.com/watch?v=V7IxiMjKWZM
- tachyonbeam 7y ago
  You mean call/cc type of manipulations?
ken 7y ago
If you mean Common Lisp, that’s a Lisp-2 (actually Lisp-N), while JS is a -1. That means there’s no universal obviously “correct” way to do JS interop. It’s complicated... Closure is a Lisp-1, as is Scheme, and (despite it being at least as “academic” as CL) there are lots of Scheme-in-JS implementations.
- kazinator 7y ago
  There is somehow a pretty obvious way to do C interop from Common Lisp, even though C has one namespace for functions and variables.
zelly 7y ago
The latter. Lisp is too academic for anyone to care to do it. Compilers need to be dogfooded, i.e., the people who work on it also write non-compiler programs with the compiler. TypeScript and Emscripten are mature because they are used to create real web applications. No one uses Lisp to write regular applications, much less web applications. Web applications in Lisp are unlikely to be its hidden niche after all these years, so very few people bother altogether.
- wglb 7y ago
  > No one uses Lisp to write regular applications, much less web applications. These are both false. This site is just one example. Here is another: https://wigflip.com/signbot/ https://wigflip.com/signbot/. And another: https://wigflip.com/roflbot/ https://wigflip.com/roflbot/. (Base domain is https://wigflip.com/ https://wigflip.com/). Grammarly is Lisp.

by hashkb 7y ago

Turing_Machine 7y ago

If you include Scheme under the heading of Lisp, BiwaScheme is pretty darned good. https://www.biwascheme.org/ https://www.biwascheme.org/

hashkb 7y ago
I do. Checking it out.
- aidenn0 7y ago
  I find it somewhat arbitrary that you accept scheme but not clojure as a lisp.
  - hashkb 7y ago
    I accept Clojure as a lisp. Didn't mean to start a holy war. I just don't personally want to deal with it and its ecosystem, which includes Java. I need your average web developer to be able to clone the repo, run yarn, and go.
    - slifin 7y ago
      I understand your point, CLJS is a superset so it's ideal to understand the substrate that it's based on, it's more complex than just JS from that point of view but usability wise: lein new re-frame myapp lein run or git clone https://github.com/jacekschae/shadow-reagent.git && cd shadow-reagent yarn install yarn dev It is very much fire and go in a way that a typical JavaScript developer might grok
    - aidenn0 7y ago
      Ah, I don't use CLJS, and I had thought it was self-hosting.
madmulita 7y ago
I don't think I ever saw it mentioned in HN, but Hop[1] based on Bigloo[2] seems so much more than just a Scheme to Javascript. If I'm not mistaken, Hop (now hop.js) could even compete in a lot of use cases with Electron. [1] http://hop.inria.fr/home/index.html http://hop.inria.fr/home/index.html [2] http://www-sop.inria.fr/mimosa/fp/Bigloo/ http://www-sop.inria.fr/mimosa/fp/Bigloo/

slifin 7y ago

Why doesn't CLJS count?

hashkb 7y ago
Because I don't want Clojure. It's too opinionated. Also CLJS has (had? been a minute) painfully slow tooling.
- chrisjc 7y ago
  I think his question is why is CLJS an incomplete lisp-on-js solution? Not why you don't like or use it.
  - iLemming 7y ago
    I completely disagree with that assessment. Disclaimer: I've been doing front-end for a long time. I've tried all sorts of ways to transpile/compile/deal with Javascript. I've tried Coffeescript, Typescript, Babel, Traceur, Fay, Haste, GHCJS, looked into Elm, Purescript and Reason, KotlinJS and ScalaJS. Clojurescript is one of the most stable and better choices for writing production-ready web-apps. Clojure, currently is the most widely used Lisp dialect in the industry. Lots of people trying it and find it massively productive. Just because some lispers "don't like it", doesn't make it less valuable technological choice.
    - armitron 7y ago
      "Clojure, currently is the most widely used Lisp dialect in the industry." Citation needed. I would bet money that this isn't true. There are a lot of places using proper Lisps that stay out of the public eye.
      - yogthos 7y ago
        It's quite rare to see postings for CL jobs, yet plenty of companies are actively using and hiring for Clojure. It's certainly a far more popular choice for green field development nowadays. Sounds like you're the one who needs to provide citations here and not the other way around.

deleted 7y ago

[deleted]

aidenn0 7y ago

1. Common Lisp is a fairly big specification for a lisp 2. People doing webdev in lisp have solutions that work "well enough" for them. 3. It's not obvious how to compile a lot of commonly used CL constructs into efficient javascript. Discarded multiple values, for example, are extremely efficient on bare-metal implementations, but will have measurable overhead when not inlined in any javascript implementation.

taeric 7y ago
I'm curious why the same tricks can't be used on discarded multiple values?
- phs2501 7y ago
  If I recall correctly they typically involve manipulating the execution stack; that's not something you can do in JS obviously.
  - taeric 7y ago
    Fair. I was assuming you could do something at the evaluation layer that was somewhat equivalent. But it makes sense the bare metal ones are doing something at the machine code layer.

Scarbutt 7y ago

Maybe this is the one. IMO, Babeljs could be leveraged to create one much faster.

hashkb 7y ago
My thoughts are along these lines, too. If it's not incrementally adoptable in webpack/etc projects, it won't see significant adoption.

rini17 7y ago

It could be done using WebAssembly. But AFAIK all existing Common Lisp implementations want to manipulate the stack in ways that WASM disallows.

register 7y ago
Can you be more specific about the peculiar way in which CL manipulates the stack? Where to find more details about CL internals?
- rwallace 7y ago
  In CL, if you catch an exception, you have the option of trying to fix the problem and then letting the code continue from where it left off. This is only moderately difficult to implement in machine code, but somewhere between problematic and impossible on a high level platform that has already implemented exceptions by stack unwinding.
pjmlp 7y ago
There is schism if you are into Schemes, but it does rely on experimental support for tail calls and reference types. https://github.com/google/schism https://github.com/google/schism https://www.youtube.com/watch?v=V7IxiMjKWZM https://www.youtube.com/watch?v=V7IxiMjKWZM
tachyonbeam 7y ago
You mean call/cc type of manipulations?

ken 7y ago

If you mean Common Lisp, that’s a Lisp-2 (actually Lisp-N), while JS is a -1. That means there’s no universal obviously “correct” way to do JS interop. It’s complicated... Closure is a Lisp-1, as is Scheme, and (despite it being at least as “academic” as CL) there are lots of Scheme-in-JS implementations.

kazinator 7y ago
There is somehow a pretty obvious way to do C interop from Common Lisp, even though C has one namespace for functions and variables.

zelly 7y ago

The latter. Lisp is too academic for anyone to care to do it. Compilers need to be dogfooded, i.e., the people who work on it also write non-compiler programs with the compiler. TypeScript and Emscripten are mature because they are used to create real web applications. No one uses Lisp to write regular applications, much less web applications. Web applications in Lisp are unlikely to be its hidden niche after all these years, so very few people bother altogether.

wglb 7y ago
> No one uses Lisp to write regular applications, much less web applications. These are both false. This site is just one example. Here is another: https://wigflip.com/signbot/ https://wigflip.com/signbot/. And another: https://wigflip.com/roflbot/ https://wigflip.com/roflbot/. (Base domain is https://wigflip.com/ https://wigflip.com/). Grammarly is Lisp.