4 ms·

Is it full stack Lisp in the sense that Lisp is running on both the server and in the client (browser/mobile)? If it is the latter, that would be quite compell

Is it full stack Lisp in the sense that Lisp is running on both the server and in the client (browser/mobile)? If it is the latter, that would be quite compelling. Clojure/Clojurescript is quite compelling from a developer point of view, since you don't have to switch mental context to develop your server and client code (as you would have to do if you develop Go on the server and JS in the browser).

junke 10y ago
I don't know if it will be explained in the book, but you can generate javascript from Lisp, using parenscript. https://common-lisp.net/project/parenscript/tutorial.html https://common-lisp.net/project/parenscript/tutorial.html
pavelludiq 10y ago
I plan on covering par, but mostly the name came from an attempt to explain the current state of lisp libraries, the "stack".
- e12e 10y ago
  Interesting book. Your introduction covering toolsets, choice of lisp etc was enough that I bought a copy! I've been seeing (common) lisp everywhere lately, from talks on clasp to the recent(ish) work on (really) fast http parser for lisp etc. It really feels like cl, with the help of a few, but very much needed tools and libraries (like quicklisp) and mature implementations that compile down to machine code could have a bit of a renaissance. I think a lot of people simultaneously realized that one didn't have to code old style lisp, just because the cl spec has been written. Like the project to reimplement cl in cl. There's no need to rely on old broken crutches, just take the good parts of cl, combine with 40 years of experience from system and language engineering, and reduce back down to cl. And suddenly you have something very elegant and efficient and powerful. Ok, I admit, I still want "sweet expressions"[1] -- but I think just a simple thing like acknowledging that global variables with * earmuffs * , are still global variables - and generally a bad idea -- and that cl is much more than some small "functional" language goes a long way. I remember I came to lisp rather late, and was confused by how un-functional a lot of the code was. There was just a lot of messy examples with detached functions for manipulating ad-hoc data structures that didn't seem properly motivated at all. And it all seemed terribly brittle. But if one ignores all of that (and a lot of the classic lisp books), what emerges is that the "good" parts of cl are really great, and there's really no reason not to use those parts. And the warts in moderation (as with any other language). [1] http://srfi.schemers.org/srfi-110/srfi-110.html http://srfi.schemers.org/srfi-110/srfi-110.html
  - wtbob 10y ago
    > Ok, I admit, I still want "sweet expressions" There's a Common Lisp library on Sourceforge: http://readable.sourceforge.net/ http://readable.sourceforge.net/ I've been thinking of using it to make a Lisp interface palatable to non-Lispers. We'll see though.
lokedhs 10y ago
In Potato we did exactly this. The server side is written in Common Lisp and the client side is implemented in Clojurescript. While I have to say that it has worked pretty well, Lisp and Clojurescript are different enough that it really isn't much of a benefit to use both together. Even the S-expression format of the two languages are so different that we need to use JSON when sending messages from the server to the client (and vice versa, of course). Please feel free to look at the code if you want to learn more about how it's done. I'll be happy to answer any questions: https://github.com/cicakhq/potato https://github.com/cicakhq/potato
zelcon 10y ago
Lisp is a better language than Clojure. People only use Clojure out of force.
- collyw 10y ago
  Yet a lot more stuff seems to be getting built in Clojure these days.

junke 10y ago

I don't know if it will be explained in the book, but you can generate javascript from Lisp, using parenscript. https://common-lisp.net/project/parenscript/tutorial.html https://common-lisp.net/project/parenscript/tutorial.html

pavelludiq 10y ago

I plan on covering par, but mostly the name came from an attempt to explain the current state of lisp libraries, the "stack".

e12e 10y ago
Interesting book. Your introduction covering toolsets, choice of lisp etc was enough that I bought a copy! I've been seeing (common) lisp everywhere lately, from talks on clasp to the recent(ish) work on (really) fast http parser for lisp etc. It really feels like cl, with the help of a few, but very much needed tools and libraries (like quicklisp) and mature implementations that compile down to machine code could have a bit of a renaissance. I think a lot of people simultaneously realized that one didn't have to code old style lisp, just because the cl spec has been written. Like the project to reimplement cl in cl. There's no need to rely on old broken crutches, just take the good parts of cl, combine with 40 years of experience from system and language engineering, and reduce back down to cl. And suddenly you have something very elegant and efficient and powerful. Ok, I admit, I still want "sweet expressions"[1] -- but I think just a simple thing like acknowledging that global variables with * earmuffs * , are still global variables - and generally a bad idea -- and that cl is much more than some small "functional" language goes a long way. I remember I came to lisp rather late, and was confused by how un-functional a lot of the code was. There was just a lot of messy examples with detached functions for manipulating ad-hoc data structures that didn't seem properly motivated at all. And it all seemed terribly brittle. But if one ignores all of that (and a lot of the classic lisp books), what emerges is that the "good" parts of cl are really great, and there's really no reason not to use those parts. And the warts in moderation (as with any other language). [1] http://srfi.schemers.org/srfi-110/srfi-110.html http://srfi.schemers.org/srfi-110/srfi-110.html
- wtbob 10y ago
  > Ok, I admit, I still want "sweet expressions" There's a Common Lisp library on Sourceforge: http://readable.sourceforge.net/ http://readable.sourceforge.net/ I've been thinking of using it to make a Lisp interface palatable to non-Lispers. We'll see though.

lokedhs 10y ago

In Potato we did exactly this. The server side is written in Common Lisp and the client side is implemented in Clojurescript. While I have to say that it has worked pretty well, Lisp and Clojurescript are different enough that it really isn't much of a benefit to use both together. Even the S-expression format of the two languages are so different that we need to use JSON when sending messages from the server to the client (and vice versa, of course). Please feel free to look at the code if you want to learn more about how it's done. I'll be happy to answer any questions: https://github.com/cicakhq/potato https://github.com/cicakhq/potato

zelcon 10y ago

Lisp is a better language than Clojure. People only use Clojure out of force.

collyw 10y ago
Yet a lot more stuff seems to be getting built in Clojure these days.