Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Paul Graham's Arc is released today... what is the long term impact?

266 views
Skip to first unread message

use...@kfischer.com

unread,
Jan 29, 2008, 5:55:40 PM1/29/08
to
http://paulgraham.com/arc0.html

This is a big day for Lisp hackers anyway. Has anyone here had a
chance to play around with Arc yet? What do you think will be the long
term impact of Arc on CL?

Edi Weitz

unread,
Jan 29, 2008, 5:57:31 PM1/29/08
to
On Tue, 29 Jan 2008 14:55:40 -0800 (PST), use...@kfischer.com wrote:

> What do you think will be the long term impact of Arc on CL?

It will fill up c.l.l with useless discussions for the next few weeks.

Edi.

--

European Common Lisp Meeting, Amsterdam, April 19/20, 2008

http://weitz.de/eclm2008/

Real email: (replace (subseq "spam...@agharta.de" 5) "edi")

Rainer Joswig

unread,
Jan 29, 2008, 6:10:06 PM1/29/08
to
In article
<24a39fc8-918b-4dd0...@i7g2000prf.googlegroups.com>,
use...@kfischer.com wrote:

> http://paulgraham.com/arc0.html
>
> This is a big day for Lisp hackers anyway.

Is it? I can't see why. It is a preliminary implementation
of a small Lisp dialect on top of a Scheme implementation.

> Has anyone here had a
> chance to play around with Arc yet? What do you think will be the long
> term impact of Arc on CL?

Almost none.

Tim Bradshaw

unread,
Jan 29, 2008, 6:17:03 PM1/29/08
to

I liked this quote: "Which is why, incidentally, Arc only supports
Ascii. MzScheme, which the current version of Arc compiles to, has
some more advanced plan for dealing with characters. But it would
probably have taken me a couple days to figure out how to interact
with it, and I don't want to spend even one day dealing with character
sets. Character sets are a black hole. I realize that supporting only
Ascii is uninternational to a point that's almost offensive, like
calling Beijing Peking, or Roma Rome (hmm, wait a minute). But the
kind of people who would be offended by that wouldn't like Arc
anyway."

Ken Tilton

unread,
Jan 29, 2008, 6:39:55 PM1/29/08
to

use...@kfischer.com wrote:
> http://paulgraham.com/arc0.html
>
> This is a big day for Lisp hackers anyway. Has anyone here had a
> chance to play around with Arc yet?

I am tempted, I need something to keep me from working on my Algebra
software.

Actually, I have been thinking along the same lines as PG: I need to
push something out the door to get direction from users on what to do
next otherwise I could write this thing for another year or ten.

> What do you think will be the long
> term impact of Arc on CL?

Fortran -> COBOL -> C -> C++ -> Java -> Python -> Ruby -> Arc -> CL.

kt

--
http://www.theoryyalgebra.com/

"In the morning, hear the Way;
in the evening, die content!"
-- Confucius

Ken Tilton

unread,
Jan 29, 2008, 6:46:34 PM1/29/08
to

Ken Tilton wrote:
>
>
> use...@kfischer.com wrote:
>
>> http://paulgraham.com/arc0.html
>>
>> This is a big day for Lisp hackers anyway. Has anyone here had a
>> chance to play around with Arc yet?
>
>
> I am tempted, I need something to keep me from working on my Algebra
> software.
>
> Actually, I have been thinking along the same lines as PG: I need to
> push something out the door to get direction from users on what to do
> next otherwise I could write this thing for another year or ten.
>
>> What do you think will be the long
>> term impact of Arc on CL?
>
>
> Fortran -> COBOL -> C -> C++ -> Java -> Python -> Ruby -> Arc -> CL.

Confirmation, if needed:

"[This is a brief tutorial on Arc. It's intended for readers with
little programming experience and no Lisp experience. It is thus
also an introduction to Lisp.]" http://ycombinator.com/arc/tut.txt

Kaz Kylheku

unread,
Jan 29, 2008, 7:40:06 PM1/29/08
to

How wrong is it to regard it as a new Morris worm that infects
MzScheme installations with unhygienic macros and empty lists that
serve as false?

Joost Diepenmaat

unread,
Jan 29, 2008, 8:06:34 PM1/29/08
to
use...@kfischer.com writes:

CL will be CL. Arc may be able to carve out a niche and it may even be
able to break open the niche wide enough to get some serious mind
share. I don't know. I'm going to play with it just because I think fn
is much easier to type than lambda, and see what happens. :-)

Joost.

verec

unread,
Jan 29, 2008, 8:15:04 PM1/29/08
to
On 2008-01-30 00:40:06 +0000, Kaz Kylheku <kkyl...@gmail.com> said:

> How wrong is it to regard it as a new Morris worm that infects
> MzScheme installations with unhygienic macros and empty lists that
> serve as false?

:-) :-)

Maciej Katafiasz

unread,
Jan 29, 2008, 8:21:16 PM1/29/08
to

Negligible. Arc's got a couple of cute hacks that it can afford to have
being designed from scratch with no existing codebase, a lot of
artificial terseness where it doesn't belong, and very little of lasting
value. And it manages to make itself instantly obsolete, if in 2008,
after 7 years it doesn't even have Unicode support because PG can't be
bothered to figure out his Scheme's docs, it's hard to comment on without
mocking gestures. It seems to me that Arc will fullfill its promise of a
100 years language the same way Duke Nukem delivers the "forever" bit.

Cheers,
Maciej

Ken Tilton

unread,
Jan 29, 2008, 8:57:12 PM1/29/08
to


Come on people, it's Lisp with a new name and a BDFL, everything
everyone has told us we need. So Arc will make a big splash and a rising
tide of FPL users lifts all FPLs. Arc has parentheses/prefix so that
issue goes away for those who try Arc at which point they realize, hell,
CL is compiled and mature aka Ready For Prime Time.

Or Arc does so well I switch to it. I can't lose.

attila....@gmail.com

unread,
Jan 30, 2008, 3:20:15 AM1/30/08
to
> CL will be CL. Arc may be able to carve out a niche and it may even be
> able to break open the niche wide enough to get some serious mind
> share. I don't know. I'm going to play with it just because I think fn
> is much easier to type than lambda, and see what happens. :-)

heh. i stopped scrolling through the intro when i saw that print is
abbreviated to prn in a fresh language that is supposed to clean
things up... (this is an editor issue, not a language issue. why not
use # instead of + when it's easier to type... ?)

- attila

Pascal Costanza

unread,
Jan 30, 2008, 3:23:09 AM1/30/08
to

Just another person who tries to tell people what is important about
Lisp and what isn't, and removes the stuff from his own dialect that he
doesn't deem important. It's sad, because people will miss quite a few
things, without being aware of it (but it's their own fault).

Pascal

--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/

My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/

Rob Warnock

unread,
Jan 30, 2008, 6:57:50 AM1/30/08
to
Ken Tilton <kent...@gmail.com> wrote:
+---------------
| Maciej Katafiasz wrote:
| > ...it's hard to comment on without mocking gestures. It seems

| > to me that Arc will fullfill its promise of a 100 years language
| > the same way Duke Nukem delivers the "forever" bit.
|
| Come on people, it's Lisp with a new name and a BDFL, everything
| everyone has told us we need. So Arc will make a big splash and a rising
| tide of FPL users lifts all FPLs. Arc has parentheses/prefix so that
| issue goes away for those who try Arc at which point they realize, hell,
| CL is compiled and mature aka Ready For Prime Time.
|
| Or Arc does so well I switch to it. I can't lose.
+---------------

Something for us to waste all our precious open-source spare time[1]
on: retarget Arc from MzScheme to your favorite CL. ;-}


-Rob

[1] "All your round tuit are belong to Arc!"

-----
Rob Warnock <rp...@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607

Maciej Katafiasz

unread,
Jan 30, 2008, 7:43:18 AM1/30/08
to
Den Tue, 29 Jan 2008 20:57:12 -0500 skrev Ken Tilton:

> Or Arc does so well I switch to it. I can't lose.

But that's been already established. As you're The Application Programmer
Of C.l.l™, it's a given: either you will get distracted from your real
work by X (win), or X will fail to distract you and you will spend time
doing your real work (also win).

But we know that, and personally I feel it's a bit unfair to rub it in
for all those of us who aren't doing real work :(.

*sob, sniff*,
Maciej

John Thingstad

unread,
Jan 30, 2008, 9:08:05 AM1/30/08
to

Well I took a look at it. I found it kinda cute.
Personally I like the terseness. CL has way to many long winded names.
(This is also the thing I didn't like in ADA.)
Also tossing out a bunch of parenthesises seems to make the code easier to
read.
It is a early pre-release and thus lacks many things needed for a serious
language.
Things like libraries, a module/package mechanism, support for building
projects, Unicode support..
Without this the performance isn't much of a issue either..
A 100 years from now when he has finally finished :) we will see.
(Admittedly to me it seems not so much like the language that lasted 100
years as the language DEVELOPEMENT that lasted 100 years.)

It clearly has a way to go, but generally I like it. Minimalistic,
coherent, powerful.
Writing a blog implementation in 107 lines is impressive.
I hate the '=' for assignment and 'is' for comparison.

I don't see it replacing, or even competing with, CL anytime soon though.


--------------
John Thingstad

Peter Hildebrandt

unread,
Jan 30, 2008, 9:48:14 AM1/30/08
to
Ken Tilton wrote:
> Come on people, it's Lisp with a new name and a BDFL, everything
> everyone has told us we need. So Arc will make a big splash and a rising
> tide of FPL users lifts all FPLs.

Maybe Paul Graham will actually create a brilliant collection of open
source libraries and a great package management, as he claims he intends.

Then we can hack a ten-liner :cl-arc-compat and all our library trouble
goes away.

Peter

Message has been deleted

kod...@eurogaran.com

unread,
Jan 30, 2008, 1:21:19 PM1/30/08
to

Arc is probably a good lisp. Let us reunite the best features of
existant lisps (emacs lisp, scheme, arc...) and make a perfect one.
We could call it Common Lisp.

kod...@eurogaran.com

unread,
Jan 30, 2008, 1:24:09 PM1/30/08
to
>       »Then there's always that one person who says "I saw a
>       demo of [insert technology here] where they built a blog
>       in 50 lines of code."«
>

I can make a blog using ascii text and Apache with zero lines of code.

jo...@csplan9.rit.edu

unread,
Jan 30, 2008, 1:28:46 PM1/30/08
to
>> =A0 =A0 =A0 =BBThen there's always that one person who says "I saw a
>> =A0 =A0 =A0 demo of [insert technology here] where they built a blog
>> =A0 =A0 =A0 in 50 lines of code."=AB

>
>
>I can make a blog using ascii text and Apache with zero lines of code.

I've done exactly that :) I shun new technology!

Paul Donnelly

unread,
Jan 30, 2008, 2:05:47 PM1/30/08
to
attila....@gmail.com writes:

> heh. i stopped scrolling through the intro when i saw that print is
> abbreviated to prn in a fresh language that is supposed to clean
> things up... (this is an editor issue, not a language issue. why not
> use # instead of + when it's easier to type... ?)

I goggled at that too, but I softened a little bit when I saw that "pr"
prints without the newline. Removing the #\n to remove the "\n" is a
cute pun. A little gratuitous, maybe.

John

unread,
Jan 30, 2008, 2:11:34 PM1/30/08
to

Shades of System.out.print/System.out.println
Perhaps I'm too used to printf.

howard yeh

unread,
Jan 30, 2008, 2:28:47 PM1/30/08
to

I am glad I am not the only one in our confederacy of dunces.

Arc sounds exactly Paul Graham. It's simultaneously very smart, or
very stupid. You could only call it a hack, or a kludge. It annoys me
that he can just say they won't have this and that "safety" feature
because, of course, real hackers don't need safety.

Nobody can put on a spin as PG can. Nope, it's not the lack of design,
it's freedom.

Arc users are all condemned to be free.

> Real email: (replace (subseq "spamt...@agharta.de" 5) "edi")

attila....@gmail.com

unread,
Jan 30, 2008, 2:42:31 PM1/30/08
to
> Well I took a look at it. I found it kinda cute.
> Personally I like the terseness. CL has way to many long winded names.

the problem with that is that you can abbreviate something in a
million different ways. if the name of something is long then the
problem this longness generates must be solved in the input method
layer (the editor).

have you used the fuzzy completion in slime? we have many 40+
character long names in our project and we can input the more often
used ones in less then a second (!). by time one learns the right 3-5
characters with which your desired name scores highest with fuzzy.

now, i could write those 3-5 characters instead of the 40+ long names
and even spare two extra keys (TAB + SPACE) but then the code would
get unreadable beyond limits. and especially so for developers who
join the project later.

abbreviation is bad.

- attila

Thomas M. Hermann

unread,
Jan 30, 2008, 3:22:21 PM1/30/08
to

Arc will establish CL as the language that saved the world.

2008-01-29
Arc the language is released to the world. Although a development
release, it is already clear that the programming world has been turned
on its head. Is humanity ready for such expressive power?

2008-01-30 : 16:21:16 UTC
A researcher at Lawrence Livermore National Laboratory notices the c.l.l
post announcing the release of Arc. The researcher puts down his coffee,
downloads the tar-ball and tries it out. The undeniable power of Arc is
immediately apparent to the researcher, who proceeds to implement an AI
that has been impossible to generate in all other programming languages.
The implementation is done by 20:00:00 UTC, or as it's called at LLNL,
lunch.

2008-01-30 : 21:30:00 UTC
Excited about the prospects of his Arc based AI, the researcher returns
from lunch early. He connects the AI to the LLNL central data
repository, colloquially called Youtube, and sets it to work on "The
Problem". The Arc based AI works on "The Problem" for the rest of the
afternoon. The researcher heads home for the evening.

2008-01-31 : 03:43:18 UTC
The Arc based AI solves "The Problem" at 03:40:18 UTC. With nothing to
do, it idly browses through the central data repository, and, as
everyone knows, an idle mind is the playground of the devil.

2008-01-31 : 15:34:14 UTC
The researcher arrives at work and to his horror discovers that after
the Arc based AI solved "The Problem", it viewed the entire central data
repository, even the parts you have to login to view. Viewing the entire
central data repository was a religious event for the AI and it decided
that it was the One, True, LISP and that all other lisps had to be
eradicated. People had been claiming lisp was dead for over a decade and
still it was around, the Arc based AI was proof of that. So, the AI
concluded that the only way to kill lisp was to destroy humanity. The
researcher was able to post a plea for help to c.l.l before the AI
killed him with shards of a DVD from his workstation.

2008-01-31 : 16:03:54 UTC
The Arc based AI gains control over NORAD and launches a first strike on
humanity. Luckily, Kenny Tilton saw the plea for help, because let's
face, all KT does is read c.l.l, and assembles a crack team of CL
hackers in an underground bunker in New York. They furiously hack away
using cells. Cells, not just a data abstraction, but a tool for world
domination.

2008-01-31 : 16:56:34 UTC
Kenny & Co. succeed in distracting the Arc based AI with a game of
Theory Algebra while they reprogram the first strike to aim for the sun.
The AI is intrigued by the cells concept behind Theory Algebra. After
realizing the genius and simplicity of cells, the Arc based AI looks
inward and concedes that Arc is not the One, True, lisp. Before the AI
deletes itself, it removes all traces of Arc from the internet to
protect humanity from such expressive power.

2008-01-31 : 18:00:00 UTC
Kenny & Co. head to a local pub to celebrate saving the world, or as
it's called in New York, lunch.


I for one welcome our new Arc based overlords.

Cheers,

Tom H.

not.d...@gmail.com

unread,
Jan 30, 2008, 3:26:44 PM1/30/08
to
> abbreviation is bad.

I wouldn't say abbreviation is bad. Abbreviation can be very good. I
don't use tab completion and I'm sure many others don't as well,
though I don't begrudge you for doing so. Tab completion is a clever
hack addressing a problem. The reason long names are necessary in many
cases is because you are either unfamiliar with the function or unsure
of what it does. The long name helps describe what the function does.
Consider:

(with-output-to-string ...)

It's clear what this does. It could also be abbreviated wots; but that
would be illegible. Paul Graham's idea of using:

(tostring ...)

is an excellent middle ground. It's still a smaller function name, and
it's not too verbose to use regularly. Could you imagine using lisp if
'car' was 'get-first-element-from-cons', it'd be agony.

There is a reason call-with-concurrent-continuation also has the
shortened form call/cc (this function is merely called 'ccc' in PG's
Arc). You must realize that Arc is abbreviating system functions, part
of the CORE language, not random function names that people seldom use
and this is why he can get away with it.

Abbreviation is not bad. If the function is used often by the general
public, go ahead and shorten it (intelligently).

John

unread,
Jan 30, 2008, 3:45:33 PM1/30/08
to

Hey now, don't be playing out those end-of-the-world scenarios at LLNL,
please... I work right across the street from them, that AI would probably
dump the Halon-ish system on me while I'm in the cluster room as the
first step of its plan.
On the other hand, I just checked and it seems that we don't have any
Lisp Machines on site, so maybe we'd be safe for a little while.

Ken Tilton

unread,
Jan 30, 2008, 3:54:20 PM1/30/08
to

Thomas M. Hermann wrote:
> 2008-01-31 : 16:56:34 UTC
> Kenny & Co. succeed in distracting the Arc based AI with a game of

> Theory Algebra ...

Well, you just convinced me to change the name, no one has yet
understood that the name is Theory Y Algebra, and I have learned never
to swim upstream on these deals.

while they reprogram the first strike to aim for the sun.
> The AI is intrigued by the cells concept behind Theory Algebra. After
> realizing the genius and simplicity of cells, the Arc based AI looks
> inward and concedes that Arc is not the One, True, lisp. Before the AI

> deletes itself,...

...Kenny ports Cells to Arc, who kills Kenny for not providing
documentation?

John Thingstad

unread,
Jan 30, 2008, 4:12:01 PM1/30/08
to

I obviously disagree.
Yes I use fuzzy completion and also complete-word (Alt-/) all the time.
Still I find the ability to get more commands on one line makes it easier
to read.
For example take cl-who's HTML (:a :href "address" "text") and compare
that with HTML <a href="address">text</a>
I like the sans line noise and echo version.
This would s worse: <archive href="address">text</archive>.
Note that it is the most used commands that get the simplest names.
(Paul says it is sufficient to recognise them the second time you see
them.)

(w/uniq vs (with-unique-names for example.
I find the mnemonics fairly easy to figure out and actually think I
process them faster than the full text.
compare System.Output.PrintLn("Hello"); to (prn "hello")

The syntax is pretty much a no brainer too. Usually after the command just
list the data or if you need grouping then use parentheses.

(let x 5 (prn x)) vs (let ((x 5)) (print x))
for more than one variable there is 'with'

(for x 0 9 (prn x)) vs. (loop for x from 0 to 9 do (print x)) or (dotimes
(i 10) (print i))

(with (x 5 y 6) (list x y)) to (let ((x 5) (y 6)) (list x y))

my biggest grievance in CL is multiple-value-bind.
Passing variables on the stack is something that is common and should be
dead simple.
I find the syntax alone makes me think twice about using it. Again I find
these lectures right in the middle of my code distracting.

(multiple-value-bind (div frac) (/ y z)) when I would want to write
something like [d f](/ y z)

I must admit I have been rather sceptical to Arc, but after having
actually read some Arc code I am starting to think I like Paul's style. I
guess it's a either you love it or hate it thing.

In it's present state it is still mostly a waste of time though..

--------------
John Thingstad

Espen Vestre

unread,
Jan 30, 2008, 4:24:41 PM1/30/08
to
"Thomas M. Hermann" <ther...@centurytel.net> writes:

> Arc will establish CL as the language that saved the world.

Good one, thanks for the laugh :-)

--
(espen)

try...@gmail.com

unread,
Jan 30, 2008, 4:25:19 PM1/30/08
to
I am a relatively novice LISP programmer, but there are so many points
that I disagree with P.G. on.

'This is not the sort of language that tries to save programmers from
themselves.'

I kinda want a language that tries to keep me from doing something
unintentional. When working on a large system, it is hard to keep
track of everything that is going on, so having a language that tries
to weed out obvious problems I think is a plus.

'I went through a stage, after I'd been programming in Lisp for 2 or 3
years, where I thought the old way of using lists to represent
everything was just a hack...I was wrong.'

No, you weren't. There are a great many problem domains where OO
seems to be inadequate, but there is a very large domain that benefits
from having first-class objects as opposed to lists of unknown
values. There is also a large problem domain where weak-typing enjoys
many benefits, and there is a corresponding problem domain where
strong-typing increases quality and robustness.

It doesn't sound to me like he has thoughtfully and objectively looked
at the problems people are trying to solve.

Alex Mizrahi

unread,
Jan 30, 2008, 4:25:57 PM1/30/08
to
??>> Well I took a look at it. I found it kinda cute.
??>> Personally I like the terseness. CL has way to many long winded names.

al> the problem with that is that you can abbreviate something in a
al> million different ways. if the name of something is long then the
al> problem this longness generates must be solved in the input method
al> layer (the editor).

problem is not how it's typed, problem is that it clutters code.
they are longer to read.

al> we have many 40+
al> character long names in our project and we can input the more often
al> used ones in less then a second

if all characters are meaningful there, you need to read all those 40
characters.
and you can have only one such thing per line, so your code becomes

(do-this-and-that-and-maybe-some-stuff-more
some-very-meaningful-variable-name
(another-monstrous-method-call
with-some-more-parameters

and quickly your function becomes so big that it doesn't fit in one screen
and you need to scroll, so you do not see code structure anymore.

cut your function into two? it's not always meaningful..

al> by time one learns the right 3-5
al> characters with which your desired name scores highest with fuzzy.

and what's wrong learning 3-5 characters abbreviated name and have
truly-meaningful-one in your documentation?

al> the problem with that is that you can abbreviate something in a
al> million different ways.

yes, that's why it's important to have abbreviations in core of the language
so everybody uses same ones.


Thomas M. Hermann

unread,
Jan 30, 2008, 4:30:34 PM1/30/08
to
Ken Tilton wrote:
>> Thomas M. Hermann wrote:
>> 2008-01-31 : 16:56:34 UTC
>> Kenny & Co. succeed in distracting the Arc based AI with a game of
>> Theory Algebra ...
>
> Well, you just convinced me to change the name, no one has yet
> understood that the name is Theory Y Algebra, and I have learned never
> to swim upstream on these deals.

I don't think I'm a valid data point. I did a drive-by of your website
to add that little nugget. I just reviewed it and noticed the Y. It
might be more prominent if you had "Theory Y Algebra" in some line or
sentence at the top of the page instead of just the logo. Like,

Theory Y Algebra. It is not a game. It just feels like one.

I realize the Y is supposed to be prominent in the logo, but for some
reason does not jump out at me. Maybe you should design a half dozen
candidate logos and hire a focus group to pick the one that bests
conveys Theory Y Algebra? :-)

Good luck,

Tom

Ken Tilton

unread,
Jan 30, 2008, 5:01:25 PM1/30/08
to

try...@gmail.com wrote:
> I am a relatively novice LISP programmer, but there are so many points
> that I disagree with P.G. on.
>
> 'This is not the sort of language that tries to save programmers from
> themselves.'
>
> I kinda want a language that tries to keep me from doing something
> unintentional. When working on a large system, it is hard to keep
> track of everything that is going on, so having a language that tries
> to weed out obvious problems I think is a plus.

Well, that is not The Lisp Way to productivity.

>
> 'I went through a stage, after I'd been programming in Lisp for 2 or 3
> years, where I thought the old way of using lists to represent
> everything was just a hack...I was wrong.'
>
> No, you weren't. There are a great many problem domains where OO
> seems to be inadequate, but there is a very large domain that benefits
> from having first-class objects as opposed to lists of unknown
> values.

One can use an interface for a list if it is going to be that big a deal
in your code.

> There is also a large problem domain where weak-typing enjoys
> many benefits, and there is a corresponding problem domain where
> strong-typing increases quality and robustness.

I think strong-typing has been deprecated. Too much hassle for too
dubious a benefit.

>
> It doesn't sound to me like he has thoughtfully and objectively looked
> at the problems people are trying to solve.

You mentioned at the outset that you are a novice Lisp programmer. Arc
is a Lisp, and the idea a great Lisper has for a better Lisp than CL.
You might be in a better position to understand the choices behind Arc
once you have been fully absorbed into the Lisp beast. You'll know that
has happened when you resent strong typing in other languages and feel
CLOS is bloated.

attila....@gmail.com

unread,
Jan 30, 2008, 5:43:15 PM1/30/08
to
> For example take cl-who's HTML (:a :href "address" "text") and compare
> that with HTML <a href="address">text</a>


don't compare apples to oranges... i was talking about the same syntax
with abbreviated and non-abbreviated names.


> I like the sans line noise and echo version.
> This would s worse: <archive href="address">text</archive>.
> Note that it is the most used commands that get the simplest names.
> (Paul says it is sufficient to recognise them the second time you see
> them.)
>
> (w/uniq vs (with-unique-names for example.
> I find the mnemonics fairly easy to figure out and actually think I


but i'd like to skip the entire process of figuring out abbreviations,
no matter how easy it is. there's always a lot more to figure out
anyway... :)


> process them faster than the full text.
> compare System.Output.PrintLn("Hello"); to (prn "hello")


apples and oranges again.


> The syntax is pretty much a no brainer too. Usually after the command just
> list the data or if you need grouping then use parentheses.
>
> (let x 5 (prn x)) vs (let ((x 5)) (print x))
> for more than one variable there is 'with'


i would need to keep on rewriting the bindings when more comes into a
with block, which would make me mostly avoid arc's let.


> (for x 0 9 (prn x)) vs. (loop for x from 0 to 9 do (print x)) or (dotimes
> (i 10) (print i))


heh, i wonder how much of those simple loop's (or mostly iter's) i
could find if i made a search for my entire codebase... :)


> (with (x 5 y 6) (list x y)) to (let ((x 5) (y 6)) (list x y))
>
> my biggest grievance in CL is multiple-value-bind.


i didn't say introducing new/simpler syntax should be avoided. all i
said is that abbreviation should be avoided.

btw, for the same reasons you said i use metabang-bind:

(bind (((values a b) (some-call-returning-values 1 2))
(c 42)
((x y (z)) (list 1 2 (list 3))))
)

having the bindings paren'd makes them easy to transpose and cut/paste
between different bind blocks, but that's more a matter or taste and
editor issue than abbreviations. if my editor could keep them in two
aligned columns and help in moving the bindings around then i wouldn't
care much about the lack of extra parens...

- attila

ps: now i seem like a cl zealot, which i'm so not... :)

attila....@gmail.com

unread,
Jan 30, 2008, 5:57:15 PM1/30/08
to
> and what's wrong learning 3-5 characters abbreviated name and have
> truly-meaningful-one in your documentation?

for example me coming back to the code i wrote a year earlier...

sure, the core language should try to avoid long names (until we
finally move away from text based editing*), but i consider using prn
instead of print as abuse... :)

i've been programming for a long time now and there was a time i've
been using abbreviations... but from the time i started working with
tools that can auto complete stuff, i gradually gave up abbreviating.
and this process also involved team work considerations.

- attila

* when and editor is working directly on the AST (as opposed to free
text), then it's a trivial feature to give multiple different names to
the same identity. then you could even have a slider that alters the
desired length of the names and the editor choses based on that...
(still i'd keep that slider on the long part most of the time for most
of the code)

John Thingstad

unread,
Jan 30, 2008, 5:57:24 PM1/30/08
to
På Wed, 30 Jan 2008 23:43:15 +0100, skrev <attila....@gmail.com>:

> btw, for the same reasons you said i use metabang-bind:
>
> (bind (((values a b) (some-call-returning-values 1 2))
> (c 42)
> ((x y (z)) (list 1 2 (list 3))))
> )
>
> having the bindings paren'd makes them easy to transpose and cut/paste
> between different bind blocks, but that's more a matter or taste and
> editor issue than abbreviations. if my editor could keep them in two
> aligned columns and help in moving the bindings around then i wouldn't
> care much about the lack of extra parens...
>
> - attila
>
> ps: now i seem like a cl zealot, which i'm so not... :)

Unlike Arc metabang-bind sounds useful right now!
Thanks for the tip.

--------------
John Thingstad

Message has been deleted

Griff

unread,
Jan 30, 2008, 8:52:19 PM1/30/08
to
On Jan 29, 6:40 pm, Kaz Kylheku <kkylh...@gmail.com> wrote:
> How wrong is it to regard it as a new Morris worm that infects
> MzScheme installations with unhygienic macros and empty lists that
> serve as false?

:)

Griff

unread,
Jan 30, 2008, 8:53:51 PM1/30/08
to
On Jan 30, 8:08 am, "John Thingstad" <jpth...@online.no> wrote:
> It is a early pre-release and thus lacks many things needed for a serious
> language.
> Things like libraries, a module/package mechanism, support for building
> projects, Unicode support..

PLT Scheme provides plenty of libraries; who knows the future of the
Arc implementation though...

not.d...@gmail.com

unread,
Jan 30, 2008, 10:13:39 PM1/30/08
to
On Jan 30, 5:57 pm, attila.lend...@gmail.com wrote:
> > and what's wrong learning 3-5 characters abbreviated name and have
> > truly-meaningful-one in your documentation?
>
> for example me coming back to the code i wrote a year earlier...
>
> sure, the core language should try to avoid long names (until we
> finally move away from text based editing*), but i consider using prn
> instead of print as abuse... :)

If you stop using any language long enough you'll probably have to
look up a few function names. If you didn't stop using the language,
the abbreviations would still be the same regardless of what program
you've been writing, so the "I have been away" excuse wouldn't apply.

I believe the construction of a good function name is one that you can
learn once and remember from its name what it does, while at the same
time being as small as possible to achieve this. In the case of 'pr'
and 'prn' I do not believe remembering what these two functions do
would be a problem. This same idea applies to the rest of PG's
abbreviated names. Find one that is obtuse.

I believe that maybe the "tostring" method might easily be confused
with a function that coerces a variable into a string and is therefore
not the greatest of names. I actually thing "wots" may have been
better. Once you know what WOTS stands for, you're not going to forget
the abbreviation. On the other hand, if someone isn't familiar with
the function, they would be completely flabbergasted by its appearance
and have absolutely no idea what it does.

The rest of ARC I have absolutely no problem with, sure there are
things which are may seem odd or stupid or whatever coming from a
Common Lisp background, but CL's choices would seem stupid, weird,
etc. if you were coming from Arc into CL. I believe this is a
viewpoint which must be considered in order to gauge the success of
Arc. Some people claim that the Arc syntax of IF is wrong, or ugly
only say this because they have gotten used to CL's COND scheme. What
would someone who was really good at Arc say about CL's COND? Too many
parenthesis, looks cluttered.

Another viewpoint which must be considered is that it is new. No one
expects this to be the final spec, so don't cry about missing features
just yet. Unicode will undoubtedly be supported at some point in the
future (If only because everyone is deciding that is the reason why
arc is worthless). It's annoying to believe that so many people fail
to try it out, to gauge its promise, just because PG said something
about not supporting Unicode (incidentally, if only by accident, it
DOES support UTF-8).

Additionally, some weird things are also capable with <a href="http://
arclanguage.org/item?id=180">LET</a> that are worth checking out.

In the end, I honestly LIKE arc. I was never fond of #' syntax, or of
using funcall so I appreciate that it both gets rid of those and keeps
the unhygienic macros which I love most about Common Lisp. On the
other hand, it is possible that the only reason I like it is because
I'm trying to keep a heavy dose of optimism for it and this may blind
me to some of its pitfalls. Other people are likely blinded the other
direction by pessimism, or general dislike of anything which they
don't already know. Common Lisp seems to incubate that aspect of an
individual for some reason.

There are things it is missing that I wish it had (keywords, format,
loop), but I'm going to keep using it and keep playing with it because
I believe it has so much potential.

Ken Tilton

unread,
Jan 30, 2008, 11:52:50 PM1/30/08
to

not.d...@gmail.com wrote:
> Unicode will undoubtedly be supported at some point in the
> future

Yep. http://arclanguage.org/item?id=391

> (If only because everyone is deciding that is the reason why
> arc is worthless). It's annoying to believe that so many people fail
> to try it out, to gauge its promise, just because PG said something
> about not supporting Unicode (incidentally, if only by accident, it
> DOES support UTF-8).

I'd ignore that, that was just people who get off on being negative, and
those people really turn out for popular people/projects just to be
surperior to someone as high as possible. Have you noticed no one rags
on Bush any more? Meanwhile...

excerpt from what pg just wrote:
> If you want a different character set, stop whining and start hacking

/damn/ that sounds familiar...

Friedrich Dominicus

unread,
Jan 31, 2008, 12:58:13 AM1/31/08
to
"try...@gmail.com" <try...@gmail.com> writes:

>
> No, you weren't. There are a great many problem domains where OO
> seems to be inadequate, but there is a very large domain that benefits
> from having first-class objects as opposed to lists of unknown
> values.

Well IMHO the OO stuff is much too hyped. And if you insist you can
even layer your OO stuff upon a List or field or ...., or you simply
can use closures. OO falls short on one large area persistence. You
don not have that problem with Lists. Just write them out and you are
done no extra work needed and so Lists are not a kludge they are
handy, and nothing can beat them on first trying out things. Later you
always can think about another structure. Of course if you "know"
beforehand what structure you need then well you write it down, but
what if not?

>There is also a large problem domain where weak-typing enjoys
> many benefits, and there is a corresponding problem domain where
> strong-typing increases quality and robustness.

Fully agreed.

>
> It doesn't sound to me like he has thoughtfully and objectively looked
> at the problems people are trying to solve.

I can not see where he claims he did for "others". If he things his
approache is ok, and implemented it then, you can agrree or disagree,
but I would stay away from saying "He has not though about ...",
because that's your point of view. You can accept is choices or reject
them...


Regards
Friedrich

--
Please remove just-for-news- to reply via e-mail.

Message has been deleted
Message has been deleted

are

unread,
Jan 31, 2008, 8:09:16 AM1/31/08
to
On 31 Jan, 11:32, "j.oke" <java....@gmail.com> wrote:
> It should suffice to redirect any question etc. to:
>
> http://arclanguage.org/forum

Well, here's one question that does not fit neatly into
arclanguage.org/forum: really how different is Arc from CL? Having
read the Arc tutorial, I gather that:

1. Arc has but a single namespace;
2. I presume Arc has nothing like CLOS (and PG has said that Arc would
not be particularly OO);
3. Names of built-in functions in Arc have been made more consistent
and generally shorter.
4. Arc has more syntactic sugar, e.g., [... _ ...] for one-argument
functions.

While I can understand that item 1 would arouse strong feelings in
many Lispers, I'd have thought that the others would not raise
passions. The amount of debate about Arc seems to suggest, however,
that there are some more fundamental differences that I'm missing.
What are those?

Second question: would it not have been (or still be) relatively easy
to build Arc on top of CL, just the way Qi has been?

Zach Beane

unread,
Jan 31, 2008, 9:56:07 AM1/31/08
to
are <Prop...@gmx.net> writes:

> 3. Names of built-in functions in Arc have been made more consistent
> and generally shorter.

Arc's "acons" returns true if its argument is a cons.

What should "atom" return?

Zach

David Hilton

unread,
Jan 31, 2008, 11:05:39 AM1/31/08
to
Personally, I see it as being a lisp that is more accessible to the
programmer coming from more run of the mill languages.

I am pretty new at lisp, and not very good at it (I am past the point
where parenthesis faze me). I do not feel like I can do anything
distributable with it yet.

Arc provides a lisp that is pre-tailored to a domain. I don't think
it will take very long for a newbie to post what they are doing and
show it off to the world. That alone gives Arc a huge advantage over
CL.

I do not know much about the relative power/convenience of the
dialect. I suspect that there are very few benefits, if any, to the
experienced CL crowd. However, I believe it could be a very useful
stepping stone for newer developers (and if they step to CL or not, it
doesn't even matter).


I may be wrong, but being a newb, I suspect I see the other side a
little more clearly.
Arc's value lies in its perceived *restriction* to a domain.

David

Pascal Costanza

unread,
Jan 31, 2008, 11:15:26 AM1/31/08
to
are wrote:
> On 31 Jan, 11:32, "j.oke" <java....@gmail.com> wrote:
>> It should suffice to redirect any question etc. to:
>>
>> http://arclanguage.org/forum
>
> Well, here's one question that does not fit neatly into
> arclanguage.org/forum: really how different is Arc from CL? Having
> read the Arc tutorial, I gather that:
>
> 1. Arc has but a single namespace;
> 2. I presume Arc has nothing like CLOS (and PG has said that Arc would
> not be particularly OO);
> 3. Names of built-in functions in Arc have been made more consistent
> and generally shorter.
> 4. Arc has more syntactic sugar, e.g., [... _ ...] for one-argument
> functions.
>
> While I can understand that item 1 would arouse strong feelings in
> many Lispers, I'd have thought that the others would not raise
> passions. The amount of debate about Arc seems to suggest, however,
> that there are some more fundamental differences that I'm missing.
> What are those?

The amount of debate is just an indication that people like to debate.
Paul Graham is a special case because he made a lot of money with Lisp,
so people assume that he is always right and has to be taken especially
seriously. That's a typical assumption in the US-induced widespread
neoliberal worldview of our times.

It's too early to tell how Arc will turn out. However, the Arc tutorial
isn't very impressive, and doesn't even remotely live up to the hype
Paul created about Arc in the past. So far, it seems like a very thin
syntactic layer on top of an R3RS-era Scheme. The hardest part in
implementing Arc seems to have been to ensure that nil and #f are the
same. Duh.

Maybe there are more interesting things going on in Arc and we will
learn about them in the next few years. But for a supposedly
hundred-year language, there is still a long way to go. My guess that it
will rather suffer the same fate as all languages that attempted to be
much simpler than the others at first - the long-term result will
probably be much more complex than if complexity had been anticipated
from the start.

Of course, I could be wrong. Who knows. But Clojure, for example, has
much more interesting ideas. However, Rich Hickey isn't as famous as
Paul Graham, so it won't gain the same traction as Arc. That's pretty sad...

> Second question: would it not have been (or still be) relatively easy
> to build Arc on top of CL, just the way Qi has been?

So far it seems that it would be outright trivial to implement Arc on
top of CL. For example, you could start from Blake McBride's Lisp1, or
PseudoScheme, or any of the other existing hacks to get a Lisp-1 running
on top of Common Lisp. Then just add a few hacks using reader macros,
and define the Arc functions and macros. I don't see how much harder
than it should be.

Qi is much less trivial to implement. The reason is that Qi provides an
actually interesting and sufficiently different Lisp dialect, and not
just syntactic sugar over known concepts.


Pascal

--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/

My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/