Arc Forumnew | comments | leaders | submitlogin
Why we need HTML + JavaScript, when we have Lisp (Arc)?
2 points by ChristophRe 2637 days ago | 13 comments
Dear Sirs, Dear Madam!

I have a question?

Why we do not use Lisp or Arc instead on HTML?

If I click on a links the browser could load instead of and HTML file a lisp file. So you would not need to have JavaScript. Lisp is data + code. And in my mind as browser could directly eval the lisp instead of html+javascript and renders it.

What you say about this?

Instead of <html> <head>..</head> <body>..</body> </html>

(arc (settings ... {instead of <head>} (load "common-styles.arc") (styles (hello (font "10pt Arial") (color "red" ) ) ) (render ... {= instead of <body>} (repeat 4 (box {insteaf of <div>} style "hello" "Hello World")) (br) (a href "") ) )

Above is only a quick & dirty example without thought much about how the structure should look like.

A HTML Parser written C is much more complicated then eval Lisp (Arc) with Lisp.

Thank you for answers ChrRe

3 points by thaddeus 2636 days ago | link

I whole heartedly agree with you. HTML/XML should die. It really is an outdated transform which unfortunately, while appropriate 20 years ago, is not appropriate for what we do these days. I do hope that someday some of the big guns like google, apple etc take on the challenge of really re-writing the web.

And, actually, I think the bigger problems are the inconsistencies in the spec and the web browser compatibility nonsense that occurs.

In other words I'd rather have a single transform that's not HTML and does not have to support all the nonsensical, historical artifacts, while easily aligning itself with functional or other language paradigm.


1 point by Pauan 2637 days ago | link

Lisp is the obvious technically superior option for the web browser: rather than having three languages (HTML, CSS, and JS), you'd have one language: Lisp.

This would mean that things like SASS and HTML templates would be unnecessary: the HTML and CSS would be generated by Lisp macros, so you could use variables and other things.

Such a system would be incredibly elegant and would immediately solve lots of problems that HTML, CSS, and JS have. The reason why such a system hasn't been developed has little to do with technical reasons, but has to do with social reasons.

Most people don't make decisions based on whether it's a good idea or not, but based primarily upon what other people think. Most people play a power game involving reputation, honor, domination, putting other people down, raising their own ego, etc.

In such a world, these people see no gain in Lisp because it doesn't confer them any advantage in the power game they play, and HTML+CSS+JS already exists, so they prefer that.

In addition, these people believe that familiarity is the same thing as readability, thus because people are used to the status quo, they think that makes the status quo better. These people prefer to not take risks: they prefer inferior strategies that are normal compared to superior strategies that are unknown.

And from a more practical standpoint, if you're a boss of a company, it's much easier to find people who know HTML+CSS+JS than people who know Lisp.

Thus, the popular options remain popular, and the impopular options remain impopular, regardless of technical superiority or inferiority. This is true in almost all areas of our society, not just programming.


2 points by Pauan 2637 days ago | link

On a related note... even though we're stuck with the HTML+CSS+JS mess for the foreseeable future, there is the possibility of designing a Lisp that compiles down to JS. My own language Nulan is such a project. This would let you write Lispish code that executes very fast in the browser.


2 points by kinleyd 2637 days ago | link

We also have ClojureScript, which is basically Clojure that compiles to Javascript: Lisp for the web browser. It combines the power of Clojure with Google's Closure web development library to spit out tight Javascript without any of the bad parts.

It's still not fully baked, but it's getting there. Clojure Lisp for web client development on top of Clojure on the desktop and server - my cup of Lisp doth brimmeth over.


2 points by ChristophRe 2636 days ago | link

I looked at ClojureScript at the source and perhaps I am wrong, but I like the simplicity of Arc and his approach. But it is fine that others also go into this direction.


1 point by kinleyd 2636 days ago | link

I think the difference is that to run an Arc powered website, you would need an Arc box on the server side, which is what you would need for running Clojure websites as well. What ClojureScript does is generate and compile the necessary JavaScript which can be off-loaded onto any (or at least most) web hosting sites, including shared web hosts. Additionally, the use of compiled JavaScript gives you the benefit of leveraging client-side processing, as opposed to Arc or Clojure boxes which are server-side solutions.

But you are right, Arc is great too, and it ultimately boils down to individual choice. Arc is my first Lisp, and I like it above Scheme/Common Lisp, as well as Python and Ruby.


2 points by ChristophRe 2636 days ago | link

Dear Pauan!


Thanks for your answer.

But what if we not look at others and do our own. If somebody wants not to learn lisp and or see it advantages or decide to say in pride what make people blind.

My trainer said to me: "What others do is NOT your problem. Do not judge."

So what if Lisp (Arc) never gets popular, why is this a problem?

I am seeking for years for a better way of user interfaces and one things for me is also the programming language as programming user of the computer.


1 point by rocketnia 2635 days ago | link

To format code, indent the whole thing by two spaces (

    (settings ... {instead of <head>}
     (load "common-styles.arc")
            (font  "10pt Arial")
            (color "red"
    (render ... {= instead of <body>}
      (repeat 4
         (box {insteaf of <div>} style "hello" "Hello World"))
      (a href "")
I think the primary use case for HTML+CSS+JS is to distribute interactive content to multiple kinds of user agents (desktop screens, mobile screens, text-to-speech screen readers, Web crawlers, etc.), with various kinds of user agent customization (user styles, user scripts, text size configuration, browser extensions, machine translation, etc.).

The specs are kind of a mess, but the way I see it, HTML and CSS try to establish a development experience where developers can cover most cases without thinking about all of them at once. When that falls short, JavaScript provides an escape hatch where developers can model the world the way they see fit, even if it's short-sighted and alienates many users.

I don't see lisp syntax as being particularly well-suited as a format for text. Nor do I see lisp semantics as being a great fit for distributed, networked, interactive computation; they're practically the same as JavaScript's semantics.


3 points by ChristophRe 2631 days ago | link

Dear rocketnia,

Can you explain the last two sentences?

Why is HTML/XML a well-suited format for text and Lisp not? Where are the differences?

And why is it not good for distributed, networked computation?

What would be better and why?



5 points by rocketnia 2630 days ago | link

"Why is HTML/XML a well-suited format for text and Lisp not? Where are the differences?"

The shorthands of HTML can be pretty nice. For instance, it's nice that HTML collapses whitespace to a single space, and I think there's actually an odd boost in brevity and readability of rich text:

  lisp:        "Said the program, \"" (i Helloooo) ", nurse world.\""
  HTML:        Said the program, "<i>Helloooo</i>, nurse world."
Racket tries to get around this shortcoming with its own TeX-like syntax, Scribble:

  TeX:         Said the program, ``\emph{Helloooo}, nurse world.''
  Scribble:    Said the program, "@i{Helloooo}, nurse world."
Arc has its own mechanism:

  atstrings:  "Said the program, \"@(i Helloooo), nurse world.\""
Then, of course, there are markdown languages, which try to incorporate kludges that look similar to the everyday kludges people already use when trying to communicate in unformatted Unicode:

  markdown:   Said the program, "*Helloooo*, nurse world."
I prefer my own approach, which is probably just a more minimalistic variant of TeX, supporting only a lisp-like section syntax. It lets the section type dictate any idiosyncratic treatment of the section body:

  Chops:      Said the program, "[i Helloooo], nurse world."
You can see my approach in use at, which generates the content portion of the page


"And why is it not good for distributed, networked computation?"

I mostly make that claim because I strongly believe in David Barbour's RDP (Reactive Demand Programming). RDP, like much research (and practice) in distributed computation, deals with designing control flow constructs that represent changes in the location of the computation. This makes it easier to manage behavior on multiple machines from a single body of source code.

In Web programming, distributed code typically takes the form of a program that primarily runs on the server but generates HTML+CSS+JS. Tools intended to help in this process include text-munging tools like PHP and Rails's use of templating syntax; control-flow-munging tools like Racket and Arc's Web continuation management; and languages whose distributed control flow is more seamless by design, like Opa and Ur/Web.

While most forays into distributed computation, including these, seem to start from an imperative language, RDP starts from a reactive one. A reactive control flow graph applies at any given instant, rather than implicitly carrying interactions across time. Thanks to both time- and space-transportation being represented explicitly, it's probably easier to account correctly for the time cost of space transportation. (And when state, being the time-distribution channel it is, is represented externally to the program, it's easier to use other tools to manage it.)

Although RDP is reactive, it even diverges from popular reactive models like FRP (Functional Reactive Programming) by abandoning the idea of discrete events. Discrete events tend to complicate fan-in computation flow (how do we zip and deduplicate event streams?), and yet they're inessential to the continuous and tentative way we actually interact with the world.

Much of the complexity of Web programming is likely due to the fact that our space- and time-distribution standards--HTTP requests, HTTP caching, cookies, WebSockets, HTML forms, HTML local storage, etc.--are designed with eventful interaction in mind. JavaScript (and potentially a JavaScript-like lisp) only enables our event addiction.

On the other hand, HTML and CSS have reactive semantics. They're very inelegant as they stand today, but with some maintenance, they might represent a better evolution path toward a simple Web.


2 points by akkartik 2637 days ago | link

I'd like that! Sadly, I think we don't have lisp syntax in the browser for the same reason we don't have lisp syntax in all programming languages: most people aren't converted to its benefits.


2 points by kinleyd 2637 days ago | link

According to Rich Hickey, the average person goes for what they find to be "simple" as defined as easy or familiar. Whereas the power of simple requires you to go beyond the easy or familiar, and that's always tough if you aren't willing to put in some effort on the learning curve.

The benefits follow, just like in other areas of our life. I think one good analogy is the average person's attitude to gratification which usually of the instant variety. Whereas the ones who do well in life are prepared to delay that gratification, choosing investing over spending, etc. The difference in outcome shows up many years later, but show up it does.


2 points by ChristophRe 2636 days ago | link

Thank you for that.

Do you know the paper "INTUITIVE EQUALS FAMILIAR"?