
Take the Arc Challenge - mqt
http://www.paulgraham.com/arcchallenge.html
======
bayareaguy
Arc seems to embody the idea that "Language design is library design, and
vice-versa", but how can we tell where the boundry is?

When I look at something like

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

what I see is more or less ordinary lisp that uses a library to solve an issue
with applications that rely on http. I'm sure plenty of us could do the
equivalent with the appropriate Python/Perl/Php/Ruby library, but then the
obvious criticism would be that you're not really comparing lanugages. You
would be comparing libraries.

Plenty of examples over here: <http://arclanguage.com/item?id=722>

Is it really the case that when you boil it down, Arc (language+libraries) is
about making small web programs? If not, why this challenge and if so I
suspect it won't live up to the 100-year idea.

~~~
pg
It's true that this example will do more to distinguish Arc from other
languages than from other Lisp dialects. But if I'd used a Lispy sort of
problem as a challenge, everyone would have accused me of cheating by using an
example that favored Lisp dialects.

I'll eventually post some comparisons of the same programs in Arc and other
Lisp dialects.

~~~
gibsonf1
I'm very interested in the Arc vs. Lisp comparisons. (especially vs. CL)

------
Annoynymous
> Though simple, as such tests have to be, this is not a contrived example.
> Web apps have to do this sort of thing all the time.

No. Web app _prototypes_ do that sort of thing all the time. For production
web apps, the problem ends up including such confounding factors as meeting
accessibility policy, making the HTML surrounding the form elements match what
a web designer came up, etc. The more web development work I do, the more wary
I am of any system that writes HTML for me. Inevitably the system ends up
putting too many constraints on what HTML can be output.

Witness the ASP.NET framework, which writes lots of HTML for you. Unlike Arc
it was written with the best practices of the time in mind, but it's aged
badly as the web has grown and changed. Doing accessible, cross-browser,
standards-based work in ASP.NET today involves a certain amount of fighting
the framework which offsets the initial productivity gains.

I understand that Arc is intended for exploratory work and rapid prototyping.
But that's exactly why the Arc challenge is meaningless. We're being asked to
compare Arc to languages that provide -- dare I say it -- a great deal more
flexibility and expressive power when it comes to outputting HTML.

So here's my challenge: Take a sample Arc application and modify it to replace
tables with appropriate block elements that have designer-specified IDs and
classes. Use <label> elements for each input if you aren't already. Replace a
few regular submit buttons with image buttons or vice versa. Reorder some
elements, and throw a few more arbitrary containers in here and there. Compare
that process against a conventional language and let's see where we get.

In my line of work, that kind of scut work is _absolutely_ part of
prototyping. Before I can build the real thing my prototype has to be approved
by people who have a hard time looking past even minor visual inconsistencies
with what they're used to. For that reason I'm very wary of any design that
makes fine-grained control of HTML any harder than it has to be, and I've come
to value clean view/everything else separation even in early prototypes.

I suspect that Arc is much more appealing to people who don't live with such
constraints.

~~~
pg
Do you consider News.YC a mere prototype? It's been around for a year, never
gets runtime errors, and serves about 80k pages a day without breaking a
sweat. And the source is full of code like this.

I think you're confusing types of software with organizations that sponsor
them.

Arc certainly wasn't designed for use in the sort of environment where
programs are 10% functionality and 90% the embodiment of the random
bureaucratic processes of the organization paying for them. More for the
opposite end of the spectrum, in fact. That's where you need power.

That said, if you care to make your challenge a precise one, it's likely I (or
someone else) would try implementing it in Arc, if only out of curiosity.

~~~
richcollins
How about releasing the source to news.yc so we can see how terse it is for a
non-trivial application :)

~~~
pg
I will eventually, but first I have to abstract out all the news.yc-specific
stuff.

------
mdemare
Just counting the tokens in the codetree is not an acceptable measure of
brevity, because it implies that adding primitives to a language always makes
it more powerful as long it makes your application shorter just once.

But adding primitives has a cost too. You could just have _let_ , or you could
have a _let_ for one value, one for more values, one for more values
initialized as nil, or as 0, or as an empty string, etc.

In Ruby I write expressions like this a lot: condition ? string : "" I'd like
to say: condition &&? string

This would make my applications shorter, but, I claim, less readable and no
more powerful.

To measure power, it is not enough to look at succinctness - you must hold
something else constant too.

~~~
pg
Sure. There are lots of pathological counterexamples to the length test. I
took that as understood.

------
tig
PHP:

    
    
      if ($S['foo']) echo "you said {$S['foo']}";
      elseif (PtoS('foo')) link('said','click here');
      else form('foo');
    

For me, making programs short is not a design goal. But if it would, I would
do it like above. My framework then would include this functionality:

    
    
      S[] contains all session variables
      P[] contains all posted variables
      PtoS copies an entry from P to S. Returns false if P was not set.
      link() prints a link
      form() shows a form with the given fields. target is the current url.

------
NickSmith
Paul, in emphasising code brevity I think you are missing a greater good. I
believe most of us subconsciously look for a language that is frictionless --
one that allows us to express our ideas without the language getting in the
way. To me this is a far more appropriate measure of a language's power than
the length of a program. I'd love a language that would allow me to stay in
flow* and express my creativity without having to stop and think about the
actual language itself. That would be the ultimate Zen power tool.

To be more specific here are three attributes that seem to aid frictionless
flow. (perhaps in order of importance) -

\--> Expressiveness -- i.e. simple, explicit and unambiguous abstractions.

\--> Obviousness and readability. -- i.e. no need to decipher tokens, and the
code structure illuminates the intention and flow of the process.

\--> Terse. -- i.e. apart from the obvious benefit of requiring less work it
also helps me 'keep the whole program in my head'.

There's nothing wrong with brevity of course, but when pursued for it's own
sake it seems to be counter productive, in that when you focus on terseness
alone there can be a tendency to ride roughshod over the more important
attributes: expressiveness and obviousness. You then end up with code that's
not as enjoyable to create and whose beauty is lost, except perhaps initially
to it's creator.

BTW Paul, this is a great first shot, so a big thank you. I, for one, am
routing for Arc to be a widespread success, if only so I can do most of what I
need to do in a language that I really enjoy.

* On Flow -> <http://www.life2point0.com/2006/06/the_little_book.html>

~~~
lispcast
I think by aiming toward brevity, what he is actually aiming for is the
ability to refactor code into something more brief.

The idea is that by ensuring the progression of long code becoming shorter,
and by upholding his second principle (axiomaticity), he is making sure that
the code he does factor out will be useful to future programmers. He is
removing the need to write common boilerplate code -- and giving the ability
to remove boilerplate code to all programmers.

And that supports the idea that PG likes about Lisp -- that the language
evolves with the program. The reason it seems to only be good for web programs
is that his principle application is a web program. If he were to work on some
other kind of program, say a word processor, you would see different kinds of
abstractions.

The point is that the language can be adapted to ANY kind of application. That
is what he is aiming for. And that's why he doesn't want you to have to count
library import statements. He wants to compare the code you have to write
repeatedly, not the once-off code. He is claiming that the code you have to
write repeatedly indicates how expressive a language is. If you have to repeat
yourself, then the language does not adequately represent the abstraction you
want to capture.

That's what _On Lisp_ is about. That's what basically all of his Lisp essays
are about. Paul Graham is aiming for brevity so that he knows that any
programmer can make their program brief by evolving the language. Brevity is a
sign of a tight fit between language and the concepts expressed in the
program.

------
ashu
I have _generally_ felt that short programs feel more elegant and enjoyable --
as long as the "flow" of the program is clear immediately by looking at it. So
PG's emphasis on brevity is correct, I think.

The other problems people talk about (make this refactorable, etc. etc.) are
essentially problems which arise when we transition from a small code base to
a large one. And to have any insight about that, I suspect we will actually
need to first _build_ something truly large in Arc. Without doing that,
arguments from both sides will just be fanciful and sensationalistic blog
crud.

New languages are designed so that we can think differently. Let's first try
to honestly think about such an artifact and see if we can express it easily
using Arc. Hack first, folks, then talk.

------
rtf
I think it is quite mistaken to put brevity above everything else. For a
100-year language, presumably with corresponding 100-year codebases, surely
the promotion of readable and refactorable source code would be the key. Macro
systems already provide a means toward brevity - whatever the language itself
does becomes inconsequential given that.

------
shiro
Here's a Scheme version. (Gauche, with a web framework Kahua):

    
    
        (define-entry (said)
          (define (page . s) `((html (body ,@s))))
          (page
           (form/cont:
            (@@: (cont (entry-lambda (:keyword foo)
                         (page (a/cont: (@@: (cont (entry-lambda () (page "You said: " foo))))
                                        "click here")))))
            (input: (@: (name "foo")))
            (input: (@: (type "submit"))))))
    

I'm defeated. I admit Arc is quite optimized for web app, at least.

Now, beyond a certain point, optimization becomes specialization. It's like
compression. The more you know about the domain, the shorter you make the
frequent patterns, and the net amount of code gets smaller. But how do you
know you're not overspecializing?

Some of Lispers, including me, have this fear for overspecialization. Reading
arc does have an effect to cure that. I see some nice abstractions in arc
which I'd like to steal from.

I'm more curious, though, to see wider range of applications in arc and how
the core abstractions will live up.

(btw, Paul, if you read this could you reset my password in Arc forum and send
it to shiro@acm.org?)

~~~
rms
and if he doesn't read this, just email him about it, he doesn't bite...

~~~
shiro
I did. Twice.

~~~
shiro
And now problem solved. Thank you, Paul.

------
jpbf
I'm interested in this part: "Steele and Sussman tried to start over when they
first began working on Scheme, but they seem to have been practically the only
ones. And they made, at least from the point of view of brevity/power, some
serious mistakes early on."

Paul, out of curiosity, what are those serious mistakes?

~~~
pchristensen
I'm also curious.

------
mynameishere
Take the C++ Challenge (entries will be judged by quality rather than fewness
of lines.)

<http://en.wikipedia.org/wiki/Id_Tech_4>

Take the Java Challenge (entries will be judged by quarterly revenue, rather
than fewness of lines)

<http://www.ebay.com>

------
irrelative
The idea behind Arc seems to be to create a new language to stand the test of
time. The problem I'm having with this challenge, and Arc in general, is that
it's very domain specific.

Now, lisp /scheme is really great at making DSLs. This example makes me think
that Arc isn't a new all-purpose language, but rather a DSL language that can
easily be modified to withstand criticism. "It doesn't have feature x!!!" ...2
weeks later... "Well, it does now."

I'm not saying that DSLs are insignificant, or that Arc's creation was
trivial, but when examples like this are used, it feels more like a framework
than a new paradigm. I think most Python/Ruby/Haskell/(modern language)
hackers could fairly easily implement a library to do what Arc does in about
as many lines, but they wouldn't call it a new language.

------
utnick
is program shortness really that important?

what percentage or time developing an app do you guys spend typing? For me it
is quite low but maybe i'm not a superhacker or i just type fast

~~~
pg
It's not so much about typing as thinking. It's not just to save typing that
you use high level languages instead of machine languages, right?

------
henning
Suggestion to Arc fans: do not do XML examples, as C# 3/VB 9 and LINQ to XML
will leave you in the dust.

------
walesmd
Everyone loves a short girl (particularly Asian), you can throw them around
the room and generally have a good time with them.

A short, hideous girl (Arc)? I wouldn't hit it.

I'm sticking to the short and beautiful (Python/Ruby).

