in the end it would be nicer to have an Arc library that wraps the underlying gui racket library in the spirit of Arc. Arc is much simpler than scheme code. I does not like complicated syntax. I also does not like OO and classes of racket. It is the wrong way. Hashtable like in Javascript and writing your own OO-like library is much more flexible.
You should build it :) Doesn't have to be complete at the start, just use it for a certain program and try to think of a cleaner way to express what you build. Then come ask us for help.
Thank you very much. I assume that I could use another syntax for [...] like in Arc. But I did not find it. So often it is better to ask people you has better scheme background. I am not grown up with Lisp stuff.
"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.
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.
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.
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.
I don't know exactly what you're asking for, but I'll try to help you. :)
---
Thank you, Pauan.
Ok. I made a mistake not to call apply.
Now it is clear. I learned from this mistake.
---
The phrase "apply it" is confusing because we sometimes say "apply a function (to some arguments)" even when we're not calling apply.
As a verb, "to mistake something (for something else)" means "to misunderstand something (thinking it's something else instead)." As a noun, "a mistake" is an accidental occurrence. The idiom "to make a mistake" means to cause an occurrence by accident.
The word "mistake" isn't usually broken up into "mis-" ("incorrectly") and "take" ("understand").
