3 ms·

Parenscript- Compile Lisp to Javascript

27 points by e1ven 19y ago

tlrobinson 19y ago
Neat, but does this really actually improve web application development (the client side of things)? You still have to deal with HTML and CSS and the DOM.
- gruseom 19y ago
  Yes. Not Parenscript as such, but the design style that it fits into can hugely improve web app development. Lisp being Lisp, you can build up natural constructs on the server side for the app you want, then generate your HTML, CSS, and JS from these. Since HTML, CSS, and JS are represented as Lisp expressions, you have the full power of Lisp macros to raise the level of abstraction of your code. Essentially, the browser becomes the target platform of your own compiler and you write your client-side code in a high-level language that is suitable for what you are trying to do. What are the advantages? Your code is higher-level, so it's clearer and shorter. You get to do most of your work (client- and server-side) in a single powerful environment. JS has become your assembly language, so you can make it low-level and efficient. This is the way out of the tradeoff between abstraction and performance in the browser. (We found that the higher-level JS libraries and frameworks are too slow because they make you pay for all that abstraction at runtime in the browser.) Oh, and it's easy to do code transformations: we wrote a profiler in about 50 lines of Lisp that works much like Firebug's but runs in all browsers. Another advantage is that you can compile a different version for each browser that you support (no more client-side browser detection). It turns out, though, that browser incompatibilities go way down once you eschew complexity in the browser. Low-level and simple things are much more likely to work the same in different browsers than fancy stuff with CSS or tables.
  - tlrobinson 19y ago
    You read Joel's Strategy Letter VI, didn't you? This does nothing to abstract away all the nastiness of dealing with browsers. For example, from their introduction, you end up with stuff like this: (html-stream *standard-output* (html (:html (:head (css (* :border "1px solid black") (div.bl0rg :font-family "serif") (("a:active" "a:hoover") :color "black" :size "200%"))))))
    - gruseom 19y ago
      There are at least three fallacies here. First, appeal to authority. Second, straw man: nowhere did I claim "to abstract away all the nastiness of dealing with browsers". (I won't repeat what I did claim, since it's just a few lines away.) Third, argument by selective example. What you call "this" isn't representative of what I'm talking about, although it does show what html and css sexps look like. Still, let's not get into an argument, I'd rather trade thoughts. The idea of abstracting away from the browser entirely seems attractive, but turns out to be impractical once you get to know the problem better. It's like abstracting away the network. So for me it's become clear that there's no way to get away from the browser altogether (except by not building HTML-based apps in the first place). That doesn't mean we can't significantly improve matters by building appropriate abstractions. As I said, we can reduce duplication, increase clarity and efficiency, and so on. The environment I'm describing has provided more of these benefits than anything else I've seen so far. Re Joel Spolsky, I find most of his stuff tiresome and overblown, but he occasionally comes out with a great idea. What specifically did he say that you find relevant?
      - tlrobinson 19y ago
        I was asking about Joel's article because you used the phrase "JS has become your assembly language", which he also mentions. My comment regarding abstracting away browser nastiness was in response to my original comment, "You still have to deal with HTML and CSS and the DOM", which you didn't address. "The idea of abstracting away from the browser entirely seems attractive, but turns out to be impractical once you get to know the problem better." In fact, I know the problem very well, and can tell you that this is simply not true. Unfortunately I can't give you any more details right now, so I'm sure you'll think I'm full of shit. I'll admit that a) I'm biased, and b) I haven't looked at Parenscript in depth, but from what I've seen I don't see it solving any problem well enough to get non-Lisp geeks to use it.
        cstejerean 19y ago
        you're missing the point. This is not for non lisp users, it's a way to make javascript and client side development more bearable for lisp users. As far as the abstractions, you will need to write some ugly DOM code at first, but then you hide away the ugly low level stuff inside of a package, write a couple of macros and you move on to writing the meat of the application at a higher level of abstraction. To make an analogy, think of starting with C, implementing Python in it and then writing your application in it.
- Goladus 19y ago
  It's clearly not a silver bullet. Basically it looks to me like the main advantage is that you can write client-side code in Javascript using s-expression trees instead of C-like syntax(statements and binary operator expressions).
arvid 19y ago
from reddit: "Excellent discussion on GWT and (versus) Parenscript" http://metabang.com/unclogit/?p=190 http://metabang.com/unclogit/?p=190
gruseom 19y ago
One thing is worth mentioning here: Parenscript is not a CL to JS compiler, but rather a way of embedding JS inside Lisp. You're not writing your PS code in Lisp and you don't have the full power of CL. Over time, people have added more Lisp-like features (for example, keyword parameters), but it's still very much a sexp dialect of JS. On the surface this seems less cool, but it has advantages that would be hard to achieve with a full Lisp->JS compiler. The generated JS is very efficient. Plus, it's very readable, so you can use all the standard tools for debugging etc. These things are critical for application development, which is why you see full compilers pop up more in the research world and not so much in business.
joshwa 19y ago
...but when can I compile JS to Lisp? ;)

27 points by e1ven 19y ago

Neat, but does this really actually improve web application development (the client side of things)? You still have to deal with HTML and CSS and the DOM.

gruseom 19y ago
Yes. Not Parenscript as such, but the design style that it fits into can hugely improve web app development. Lisp being Lisp, you can build up natural constructs on the server side for the app you want, then generate your HTML, CSS, and JS from these. Since HTML, CSS, and JS are represented as Lisp expressions, you have the full power of Lisp macros to raise the level of abstraction of your code. Essentially, the browser becomes the target platform of your own compiler and you write your client-side code in a high-level language that is suitable for what you are trying to do. What are the advantages? Your code is higher-level, so it's clearer and shorter. You get to do most of your work (client- and server-side) in a single powerful environment. JS has become your assembly language, so you can make it low-level and efficient. This is the way out of the tradeoff between abstraction and performance in the browser. (We found that the higher-level JS libraries and frameworks are too slow because they make you pay for all that abstraction at runtime in the browser.) Oh, and it's easy to do code transformations: we wrote a profiler in about 50 lines of Lisp that works much like Firebug's but runs in all browsers. Another advantage is that you can compile a different version for each browser that you support (no more client-side browser detection). It turns out, though, that browser incompatibilities go way down once you eschew complexity in the browser. Low-level and simple things are much more likely to work the same in different browsers than fancy stuff with CSS or tables.
- tlrobinson 19y ago
  You read Joel's Strategy Letter VI, didn't you? This does nothing to abstract away all the nastiness of dealing with browsers. For example, from their introduction, you end up with stuff like this: (html-stream *standard-output* (html (:html (:head (css (* :border "1px solid black") (div.bl0rg :font-family "serif") (("a:active" "a:hoover") :color "black" :size "200%"))))))
  - gruseom 19y ago
    There are at least three fallacies here. First, appeal to authority. Second, straw man: nowhere did I claim "to abstract away all the nastiness of dealing with browsers". (I won't repeat what I did claim, since it's just a few lines away.) Third, argument by selective example. What you call "this" isn't representative of what I'm talking about, although it does show what html and css sexps look like. Still, let's not get into an argument, I'd rather trade thoughts. The idea of abstracting away from the browser entirely seems attractive, but turns out to be impractical once you get to know the problem better. It's like abstracting away the network. So for me it's become clear that there's no way to get away from the browser altogether (except by not building HTML-based apps in the first place). That doesn't mean we can't significantly improve matters by building appropriate abstractions. As I said, we can reduce duplication, increase clarity and efficiency, and so on. The environment I'm describing has provided more of these benefits than anything else I've seen so far. Re Joel Spolsky, I find most of his stuff tiresome and overblown, but he occasionally comes out with a great idea. What specifically did he say that you find relevant?
    - tlrobinson 19y ago
      I was asking about Joel's article because you used the phrase "JS has become your assembly language", which he also mentions. My comment regarding abstracting away browser nastiness was in response to my original comment, "You still have to deal with HTML and CSS and the DOM", which you didn't address. "The idea of abstracting away from the browser entirely seems attractive, but turns out to be impractical once you get to know the problem better." In fact, I know the problem very well, and can tell you that this is simply not true. Unfortunately I can't give you any more details right now, so I'm sure you'll think I'm full of shit. I'll admit that a) I'm biased, and b) I haven't looked at Parenscript in depth, but from what I've seen I don't see it solving any problem well enough to get non-Lisp geeks to use it.
      - cstejerean 19y ago
        you're missing the point. This is not for non lisp users, it's a way to make javascript and client side development more bearable for lisp users. As far as the abstractions, you will need to write some ugly DOM code at first, but then you hide away the ugly low level stuff inside of a package, write a couple of macros and you move on to writing the meat of the application at a higher level of abstraction. To make an analogy, think of starting with C, implementing Python in it and then writing your application in it.
Goladus 19y ago
It's clearly not a silver bullet. Basically it looks to me like the main advantage is that you can write client-side code in Javascript using s-expression trees instead of C-like syntax(statements and binary operator expressions).

arvid 19y ago

from reddit: "Excellent discussion on GWT and (versus) Parenscript" http://metabang.com/unclogit/?p=190 http://metabang.com/unclogit/?p=190

gruseom 19y ago

One thing is worth mentioning here: Parenscript is not a CL to JS compiler, but rather a way of embedding JS inside Lisp. You're not writing your PS code in Lisp and you don't have the full power of CL. Over time, people have added more Lisp-like features (for example, keyword parameters), but it's still very much a sexp dialect of JS. On the surface this seems less cool, but it has advantages that would be hard to achieve with a full Lisp->JS compiler. The generated JS is very efficient. Plus, it's very readable, so you can use all the standard tools for debugging etc. These things are critical for application development, which is why you see full compilers pop up more in the research world and not so much in business.

joshwa 19y ago

...but when can I compile JS to Lisp? ;)