

Parenscript- Compile Lisp to Javascript - e1ven
http://common-lisp.net/project/parenscript/

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

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

~~~
gruseom
_I was asking about Joel's article because you used the phrase "JS has become
your assembly language", which he also mentions._

Ah, no, I didn't get that from Joel, it's just the obvious analogy if you're
generating low-level JS.

 _my original comment, "You still have to deal with HTML and CSS and the DOM",
which you didn't address_

I thought I did address it. You can generate these things from something
higher-level which is much easier to work with (but not so abstract that you
don't still have to understand what you're generating). I don't claim that
this is a unique approach but it is certainly an area of strength for Lisp,
and Parenscript deserves to be better known.

Incidentally, in the app I work on we don't deal much with HTML or CSS. We
keep those to a minimum and do almost everything in Javascript. We even try to
avoid the DOM when possible and do as much as we can in pure JS (for example,
using arrays rather than childNodes). This is the only way we've been able to
get acceptable (or nearly acceptable) performance in the browser.

 _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 don't think you're full of shit. I'm describing the best solution of the
ones I've seen so far. If you can do better, I look forward to hearing about
it.

I remain skeptical, though, that HTML/JS can be fully abstracted away in a way
that doesn't leak (now there's a term I did get from Spolsky) and still yields
usable, performant web apps. There's too much going on there that's too
essential to what a web app is. Take for example that html sexp you quoted.
There's a lot of information in it. However you represent it, you still need a
way to say that you want a 1px border, a certain font, links that get bigger
when you mouse over them and so on. There's a whole model there which can
certainly be abstracted into something else, but that something else won't
necessarily be simpler (it will, however, be non-standard). My feeling is that
there isn't much "compression" to be had in the general case. But I'm willing
to be proven wrong.

~~~
boucher
" However you represent it, you still need a way to say that you want a 1px
border, a certain font, links that get bigger when you mouse over them and so
on. There's a whole model there which can certainly be abstracted into
something else, but that something else won't necessarily be simpler (it will,
however, be non-standard)."

The thing is, is that really what people who are building applications need to
figure out? Yes, they probably need access to changing these properties, but
the vast majority of what you are doing when you are writing an actual
application on the web is far more complicated then setting a few class
properties on some divs.

It isn't so much about compressing this, as it is about throwing out this
broken architecture. HTML/CSS are great technologies for page layout. In fact,
I have a perverse love for them which I am unable to explain, let alone
understand. But they suck when it comes to dynamic, application like
behaviors. We need a new technology. And yes, while it won't be a w3c or
whatwg standard, if its open source, who cares? I, for one, am tired of
relying on browser manufacturers to get things done.

~~~
gruseom
Hmm, we're talking in the same general space but miscommunicating on details,
so this discussion may need to wait until you guys can provide specifics of
what you're working on. But let me try to clear up a couple points.

 _The thing is, is that really what people who are building applications need
to figure out? Yes, they probably need access to changing these properties_

You answered your own question. Yes, they need this, along with a lot of other
things. That complexity is intrinsic to making a web app and therefore is hard
to completely abstract away.

Of course I do not exaggerate the importance of div borders. My point was that
even the sexp your colleague cited as a counterexample contains a lot of
information - not just browser nastiness or crud, but useful information,
which any model you try to replace HTML/CSS/JS with will still need to
represent.

 _It isn't so much about compressing this_

When I said "compression" I didn't mean it literally, as in gzip, but
metaphorically. A good abstraction is a kind of logical compression inasmuch
as it replaces a complex, detailed model with a simpler one that contains the
same information. It does this by throwing out non-essential details (like
duplication). Now, if your goal is to build a general abstraction ABC on top
of HTML/CSS/JS, ABC must be _much_ simpler in order to justify its learning
curve and the fact that it's nonstandard. (By "nonstandard" I simply mean
unfamiliar.) That means you're going to have to find a lot of "noise" to throw
out. My skepticism is based on the fact that I don't see a lot of such noise
in the general case. A thing can be messy and yet still difficult to abstract
over. But I'm not saying it can't be done, and good for you if you can do it.

The approach we take with Parenscript is more modest, I think. We're not
building universal abstractions for web apps, just for our own. That means we
can abstract away from anything _we_ don't need, whether or not it's needed by
others. That and the fact that Lisp gives us a homogeneous way of representing
all the HTML/CSS/JS pieces are two very big wins. Is it enough to get non-
Lisp-geeks to use it? Probably not. But I don't think that's why most hackers
take up something like Lisp in the first place.

~~~
tlrobinson
I think the problem is we have two very different solutions to two _different
problems_. Parenscript seems great for the things you're describing, but those
are the things I happen to not be interested in.

I'll be sure to let you know when we have something more to show, I'd be
interested to hear your opinions of it.

~~~
gruseom
I'll keep an eye out for it. Good luck.

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

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

