

What's happening with Arc? - zeynel1
http://stackoverflow.com/questions/448613/whats-happening-with-arc

======
loewenskind
Personally I have a hard time seeing what the goal for Arc would be. "100 year
language" seems pretty fuzzy. I mean, Lisp is already at least a 100 year
language IMO so what could Arc do to make itself more so? What is it going to
do that the other two popular Lisp-1s don't? The only differentiator I've seen
so far is pg's confusion of terse for concise [1].

I think there is always more room for programming languages in the world,
especially given how awful most of them are. I just think they need some clear
reason to exist or their creation isn't worth the fracturing effect [2].

[1] Personally I use terse to mean "short and unreadable" and concise to mean
"short and _more_ readable" (think: "I didn't have time to write a short
letter..."). The first thing that occurred to me when I saw Arc was "oh man, a
bunch of cryptic one or two letter functions. Is this meant to be programmed
over a 1200 baud modem or something?" Every one of those kinds of things is
something that has to be memorized, and given how much more advanced IDEs are
today what's lost in readability is not made up in typing savings. For me the
classic example of "concisity" is Smalltalk. Most methods are just a line or
two, they read almost literally as English yet so much is said with so little.
No meaningless cryptic two letter sequences but yet one line is equivalent to
at least 3 lines of Java [3].

[2] I.e. users becoming party of a community of this new mostly irrelevant
language A instead of helping the community of the language that would have
been said to obsolete A if it had been written after A instead of before it.

[3]
[http://www.cincomsmalltalk.com/blog/blogView?showComments=tr...](http://www.cincomsmalltalk.com/blog/blogView?showComments=true&printTitle=Smalltalk_and_Productivity&entry=3256379312)

~~~
hasenj
I like your "terse vs concise" argument. I always felt that PG's notion of
succinct is analogous to "cryptic".

Short is not always good.

~~~
silentbicycle
It probably has a positive correlation, but isn't an end in itself.

"Short" languages typically have a programming model which makes common coding
tasks _implicit_ : ML (and other languages with type inference) make most type
annotations implicit, pattern-matching languages (Erlang, Prolog, ML, Haskell,
awk) make a lot of de-structuring and switching code implicit, APL dialects
(APL, J, K/Q, etc.) make looping implicit, concatenative languages (i.e.
Forth, Joy, Factor) and tacit / "points-free" languages (Haskell and J, again)
make variables and dataflow implicit, constraint and/or logic languages
(Prolog, Mercury, Oz) make search implicit, etc.

It's often a net win, but some problems inevitably clash with their model - it
seems important to have some kind of escape built into the language.

------
pg
I'll probably release a new version later this year. Most of the changes will
be in news.arc, which is now pretty solid. Maybe I'll actually make an effort
to make it installable without having to understand the source.

~~~
SiVal
Graham cares about having a better programming language, but he doesn't really
care enough to do what it takes to make it happen. (He has no obligation to do
so, of course.)

Practical programming languages these days aren't just ways of expressing
"algorithms," but toolkits for marshalling the vast information processing
resources around the world (people, libraries, net protocols, platforms from
microcontroller to supercluster, communications systems, etc.) The number of
issues is enormous and growing. Useful programming languages have to have a
whole army of specialists who provide feedback and code dealing with security,
internationalization, performance, accessibility, net protocols, commercial-
grade GUI wrapper/frameworks, installers, compilers/runtimes for countless
platforms, scientific computing, embedded/realtime computing, frameworks of
all sorts, dev tools.... Many of these things will be done poorly, if at all,
if not accounted for in the design of the foundations of the language. That's
the reason for the serious warts on all popular languages and the desire of
many for something better designed.

Yet Graham's approach is, as always, to work privately, get feedback from the
same half-dozen friends, then make announcements on a "when we have something
to announce, I'll announce it, so don't bother asking" schedule. If none of
his friends knows enough about international coding issues, for example, to
even realize how little they know about text (something more important to Lisp
than to most languages), then he'll make a silly architectural decision
regarding Unicode, which he'll announce to, not discuss with, the rest of the
world. Hey, if my friends don't seem concerned by it, it can't be very
important, right?

This is too bad. Few languages have the potential Lisp has for creating
flexible, evolvable code that can rapidly adapt to the changing world. Yes, I
do think that the language matters, but it's the whole platform, not just the
syntax.

But I don't think you can create a successful, practical, general purpose
language these days without an army of specialist volunteers behind you.
Graham's message to specialist volunteers is "go away, you're not the people
whose opinions I care about," so I think the language WILL last 100 years--in
approximately its current form.

~~~
pg
My goal from the beginning was to continue where JMC left off: to continue
building Lisp up from axioms till I have a more complete language. I've
compromised a bit to make it something runnable, which I think you need in
order to test out your ideas on programs of substantial length. But "practical
programming" is not in itself the main goal.

Paradoxical as it sounds, that may be the way to end up with the best language
for practical programming. It worked for McCarthy, and I think there's more
juice yet to be squeezed out of this orange.

~~~
hasenj
Wasn't McCarthy working on a model that's more elegant than Turing machines?

As far as axioms go, you can't get simpler than the Turing machine: it doesn't
even have a notion of a variable, let alone types or strings.

I don't know about the history of Lisp other from what I've read from you, but
it seems what McCarthy was working on was a more elegant model, rather than an
"axiomatically pure" model.

Arc on the other hand, is trying to compete with Ruby and Python.

~~~
pg
I believe his goal was a formal model of computation that was also good for
expressing algorithms. Plus eval probably seemed like a neat trick. We take it
for granted, but imagine how pleasing that must have been to think of.

I'm not trying to compete with Ruby and Python. If I were I'd be recruiting
armies of people to write libraries.

~~~
hasenj
I meant "compete" in terms of expressiveness. And actually that's not the only
thing.

A language that can express algorithms in few lines that are very cryptic
(read: hard to read) is not very useful.

I think were python hit the mark spot on is the adoption of the idea that
"programs should be written for people to read, and only incidentally for
machines to execute".

And where ruby hit it spot on is "optimizing for happiness", I particularly
like Matz's his idea about "harmony"[1].

    
    
      Matz> I believe consistency and orthogonality are tools of design, not the primary goal in design.
    

If the language forces you to carry the compiler in your brain as you try to
read code, it's a bad idea.

One of the things that annoy me about lisp as a beginner, and maybe this only
because I'm a beginner, is that I always have to manually compile code into
the syntax tree.

[1]: <http://www.artima.com/intv/ruby2.html>

~~~
evanrmurphy
_A language that can express algorithms in few lines that are very cryptic
(read: hard to read) is not very useful._

Part of Arc's design philosophy is to never inconvenience advanced users in
order to serve novice ones. Long, descriptive names help people unfamiliar
with a language's operators better understand what they do, but the length can
become a burden once they do know.

For example, when I first started learning Arc, it would have saved me some
headache if _afn_ had been named _anaphoric-function_. Now I would find that a
real nuisance. I love being able to invoke such a powerful abstraction with
just three keystrokes.

Here's an interesting exercise. This is the given solution to the Arc
Challenge [1]:

    
    
      (defop said req
        (aform [w/link (pr "you said: " (arg _ "foo"))
                 (pr "click here")]
          (input "foo")
          (submit)))
    

What would you prefer that it looked like? If you replaced all the abbreviated
names with long descriptive ones, you'd have something like:

    
    
      (define-operator said request
        (html-anaphoric-form
          [html-with-link 
            (print "you said: " (argument _ "foo"))
            (print "click here")]
          (html-input "foo")
          (html-submit)))
    

\---

[1] <http://arclanguage.org/item?id=722>

~~~
hasenj
I despite long names in JavaLibrariesAndFrameWorks but I don't appreciate tla
aop (three letter acronyms all over the place).

Your second code snippet is actually much more pleasant to read.

~~~
evanrmurphy
Sure, it's subjective. :)

I forgot to mention though that the idea is to use the shortest names possible
for the _core language operators_. That's when they're the biggest win, since
you'll learn those well enough not to need descriptive names, and they cut
program length more substantially since they're used so often.

~~~
hasenj
Right, and I agree with that. I prefer = over define.

The problem comes when everything is "inlined".

    
    
        (def color (r g b)
          (with (c (table) 
                 f (fn (x) (if (< x 0) 0 (> x 255) 255 x)))
            (= (c 'r) (f r) (c 'g) (f g) (c 'b) (f b))
            c))
    

This is the first thing in html.arc

I can't make sense of it, it's way too terse.

This is probably why python doesn't have a proper lambda expression.

EDIT:

After some pondering, I see what it does ..

An equally terse implementation in python:

    
    
      def limit(n, lower, upper):
          if n < lower: return lower
          if n > upper: return upper
          return n
    
      def color(*args):
          return dict(zip("rgb", [limit(c, 0, 255) for c in args]))
    
      >>> color(10, 20, 30)
      {'r': 10, 'b': 30, 'g': 20}
    

This is a lot clearer, without sacrificing conciseness:

    
    
      def color(*args):
          rgb_values = [limit(c, 0, 255) for c in args]
          return dict(zip("rgb", rgb_values))
    

By simply getting the inlined list comprehension outside the dict expression,
the whole thing becomes 10 times easier to read: "Ah, it's mapping 'rgb'
characters to rgb values."

------
jackowayed
Why would I use Arc?

In particular, I've been playing with Clojure and enjoying that. It's still a
Lisp, so it has a lot of the advantages that Arc has. In addition, it has some
cool unique features and almost certainly has more comprehensive libraries
thanks to being able to use Java libraries. What advantages does Arc have over
Clojure?

I'm not trying to be mean to Arc lovers and call it a useless language. I
genuinely want an excuse to give Arc a try.

~~~
mechanical_fish
_What advantages does Arc have over Clojure?_

It has nothing to do with Oracle's Java and vice versa.

If that doesn't seem like much of an advantage to you, you're probably right,
and it isn't, and godspeed. There is no pressing need to learn Arc today. (I
haven't yet, myself, though not for lack of ambition.) Arc will still be
there, still unconnected to anything Java, in five years; we'll see how it
feels then.

~~~
khafra
Almost unrelatedly, any idea if there's a strong push for a more current,
well-maintained .NET/mono version of Clojure, now that the JVM is going down
in flames?

~~~
yena
Yes, ClojureCLR. It is supposed to work on Mono as well.

------
rglovejoy
I'm playing around with it. Right now, my spare-time project is filling out
the blogging software that came with the language. I am finding that it's a
lot of fun to work with.

------
olalonde
Wasn't Arc meant to be a toy/academic language?

~~~
silentbicycle
Wasn't Unix written to play _Space Travel_
([http://www.courses.fas.harvard.edu/~lib215/reference/history...](http://www.courses.fas.harvard.edu/~lib215/reference/history/spacetravel.html))?

~~~
hasenj
What a gem! nice find!

