"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."
"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.
> "There may be a fundamental law that the more underpowered the language, the easier it is to read."
That's a lot stronger claim than your original :) Aren't python, ruby, and haskell all high-power but easy to read?
There's the confounding effect of learnability; lisp gets more readable over time. There's also the confounding effect of density or difficulty. This quote captures both:
"If you're used to reading novels and newspaper articles, your first experience of reading a math paper can be dismaying. It could take half an hour to read a single page. And yet, I am pretty sure that the notation is not the problem, even though it may feel like it is. The math paper is hard to read because the ideas are hard. If you expressed the same ideas in prose (as mathematicians had to do before they evolved succinct notations), they wouldn't be any easier to read, because the paper would grow to the size of a book." (http://www.paulgraham.com/power.html)
I've started reading the book, but am having trouble connecting it up to s-expressions. Can you elaborate on examples of traditional lisp code that violate its principles?
I think C is a great language. It maps straightforwardly onto to the capabilities of the hardware. What I meant by calling it underpowered is that it doesn't do much to increase your power beyond freeing you from having to write assembly language.
Higher order functions and metaprogramming are the sort of things I associate with a powerful language, like Lisp. But sometimes things get so abstract you can't tell what you're looking at.
As you point out, it's easy to ruin something like a programming language while trying to improve it. (I haven't created a programming language, but I've used bad ones.)
I don't think Pauan was referring to C syntax as a whole. In this subthread, I think we've been specifically talking about whether certain languages have a "single, canonical" indentation style that "falls out naturally."
---
"There may be a fundamental law that the more underpowered the language, the easier it is to read. Sort of like how Dr. Seuss books are more readable than research papers on programming languages theory, right?"
In one sense that's true, since it's easy to make naive improvements to one feature while neglecting another. In another sense, a less readable language is always relatively "underpowered" due to its greater difficulty to use (assuming it's a language we use by reading :-p ).
(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 "www.arclanguage.org")
)
)
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.
>> C's syntax isn't actually more uniform than Lisp
C's syntax is actually less uniform, isn't it?
C isn't a very sophisticated language, but it tends to be readable. At least in the sense of following the flow of control; perhaps things like error handling make it hard to see the forest for the trees.
There may be a fundamental law that the more underpowered the language, the easier it is to read. Sort of like how Dr. Seuss books are more readable than research papers on programming languages theory, right?
To create /about, use newsop. Here's a simple example to append to news.arc:
(newsop about ()
(shortpage user nil "about" "About" nil
(pr "hihihi")))
Does this work? Feel free to ask more questions if it didn't. If it did work, read on.
---
If it works, you might notice that the "about" link on the top nav of the about page isn't highlighted like say the "new" link is for the corresponding page. To fix this, add "about" to toplabels, and change the call in toprow to this:
(toplink "about" "about" label)
Now the "about" in shortpage gets passed to label in toprow and toplink has enough information to decide to highlight it.
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.
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.
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.
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.
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.
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.
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.
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.
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.
16 lines total. Probably less than it would have taken to do the 'nil -> () conversion. But Arc can't tell the difference, unless I've overlooked something.
"I feel uneasy about the shallow change to +; I'm sure the same bug exists in some other functions since deep niltree is the default."
From what I can see, there are only three places in the pg-Arc code where 'ac-niltree traverses too far, and they're all in ac.scm. Two are the definitions of + and ar-+2, and one is a misleading comment:
; Arc primitives written in Scheme should look like:
; (xdef foo (lambda (lst)
; (ac-niltree (scheme-foo (ar-nil-terminate lst)))))
; That is, Arc lists are NIL-terminated. When calling a Scheme
; function that treats an argument as a list, call ar-nil-terminate
; to change NIL to '(). When returning any data created by Scheme
; to Arc, call ac-niltree to turn all '() into NIL.
; (hash-table-get doesn't use its argument as a list, so it doesn't
; need ar-nil-terminate).
From another point of view, there are only a few places where 'ac-niltree probably needs to be recursive. Those are in the definitions of 'ac-call, 'ac-mac-call, and 'ac-macex, where they deal with quotation and macroexpansion, the two ways literal code is made available to Arc programs.
The other uses of 'ac-niltree are in 'ar-coerce (string to cons), 'dir, and 'timedate, where the lists are flat anyway.
I only looked for uses in pg-Arc, not any code that's been derived from it.
"Confusing that you're using deep/shallow with two meanings in the same comment :)"
Whoops! My comment was originally going to stand on its own, but I adapted it into a reply when Pauan got to what I wanted to say first. :) I didn't notice the word overlap.
"Hmm, can you elaborate on how it manages this? Is it just printing nil, but otherwise leaving the actual cons cells ()-terminated? (That option has probably been discussed multiple times: http://arclanguage.org/item?id=3094. I'm sure I mentioned it too at some point.)"
Yes. And then "nil" is a global variable that is bound to (). I also have to do a few other things like changing quote so that it changes the symbol "nil" to (), but overall it isn't that hard to have perfect Arc compatibility, even without doing the conversion.
"I also just noticed: It is _utterly_ insane that niltree converts () to nil, while nil-terminate does the opposite."
It's called "tree" because it recurses on the car. In other words, it traverses sublists. As for why it's called "nil", well, I guess that's because you can't use () in the name without using || quotes. I'd call them "nil->null" and "null->nil". Or perhaps "arc->racket" and "racket->arc".
Arc/Nu manages to implement that Arc feature without conversion
Hmm, can you elaborate on how it manages this? Is it just printing nil, but otherwise leaving the actual cons cells ()-terminated? (That option has probably been discussed multiple times: http://arclanguage.org/item?id=3094. I'm sure I mentioned it too at some point.)
