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?
On Jan 29, 10:55 pm, ······@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? What do you think will be the long
> term impact of Arc on CL?
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."
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.
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a0f3ad$0$25055$607ed4bc@cv.net>
·······@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.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Friedrich Dominicus
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <87myqmmt8q.fsf@q-software-solutions.de>
········@gmail.com" <·······@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.
On Jan 29, 2:55 pm, ······@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? What do you think will be the long
> term impact of Arc on CL?
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?
On 2008-01-30 00:40:06 +0000, Kaz Kylheku <········@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?
:-) :-)
On Jan 29, 6:40 pm, Kaz Kylheku <········@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?
:)
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <479fb935$0$6360$607ed4bc@cv.net>
······@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
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <479fbac4$0$6328$607ed4bc@cv.net>
Ken Tilton wrote:
>
>
> ······@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
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Edi Weitz
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <uprvk9r50.fsf@agharta.de>
On Tue, 29 Jan 2008 14:55:40 -0800 (PST), ······@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 ·········@agharta.de" 5) "edi")
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.
On Jan 29, 3:57 pm, Edi Weitz <········@agharta.de> wrote:
> On Tue, 29 Jan 2008 14:55:40 -0800 (PST), ······@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 ·········@agharta.de" 5) "edi")
On 31 Jan, 11:32, "j.oke" <········@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?
From: Zach Beane
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m3fxwe6o3c.fsf@unnamed.xach.com>
are <·········@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
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
On Jan 31, 8:56 am, Zach Beane <····@xach.com> wrote:
> are <·········@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?
It should return true if the object is a 'tom' hahahaha
In article
<····································@i3g2000hsf.googlegroups.com>,
Griff <·······@gmail.com> wrote:
> On Jan 31, 8:56 am, Zach Beane <····@xach.com> wrote:
> > are <·········@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?
>
> It should return true if the object is a 'tom' hahahaha
Obviously Paul has an argument that Common Lisp names are
a bit long.
It is well known that names are still recognizable when you
remove the vocals.
I'm now working on making the names of the built-in functions
for Common Lisp SGNFCNTLY shorter.
Here is a (partial) result of a first try:
...
MMBR-F MMBR-F-NT MN MNSP MP MP-NT MPC MPCN MPCN MPCR MPHSH
MPL MPLST MPRT MRG MRG-PTHNMS MSK-FLD MSMTCH MST-NGTV-DBL-FLT
MST-NGTV-FXNM MST-NGTV-LNG-FLT MST-NGTV-SHRT-FLT MST-NGTV-SNGL-FLT
MST-PSTV-DBL-FLT MST-PSTV-FXNM MST-PSTV-LNG-FLT MST-PSTV-SHRT-FLT
MST-PSTV-SNGL-FLT MTHD MTHD-CMBNTN MTHD-CMBNTN-RRR MTHD-QLFRS
MX N-NXT-MTHD N-PCKG N-PPLCBL-MTHD NBND-SLT NBND-SLT-NSTNC NBND-VRBL
NBTLST NCD-NVRSL-TM NCF NCNC ND ND-F-FL NDFND-FNCTN NDP NGH-NMSTRNG
NL NLL NLN NLSS NM-CHR NMBR NMBRP NMRTR NMSTRNG NN NNN NNTH
NNTRN NNTRSCTN NPT-STRM-P NRCNC NRD-CHR NRVRS NS-PCKG
NSBLS NSBST NSBST-F NSBST-F-NT NSBSTTT NSBSTTT-F NSBSTTT-F-NT
NSGND-BYT NSPCT NSR-DRCTRS-XST NSR-GNRC-FNCTN NST-DFFRNC
NST-XCLSV-R NSTRNG-CPTLZ NSTRNG-DWNCS NSTRNG-PCS NT NTGR
NTGR-DCD-FLT NTGR-LNGTH NTGRP NTH NTH-VL NTHCDR NTLZ-NSTNC
NTNLN NTNY NTRC NTRCTV-STRM-P NTRN NTRNL-TM-NTS-PR-SCND
NTRSCTN NTVRY NVK-DBGGR NVK-RSTRT NVK-RSTRT-NTRCTVLY
NVLD-MTHD-RRR NWND-PRTCT NXPRT NXT-MTHD-P P PCKG
PCKG-NCKNMS PCKG-NM PCKG-RRR PCKG-RRR-PCKG PCKG-S-LST
PCKG-SD-BY-LST PCKG-SHDWNG-SYMBLS PCKGP PDT-NSTNC-FR-DFFRNT-CLSS
PDT-NSTNC-FR-RDFND-CLSS PGRDD-CMPLX-PRT-TYP PGRDD-RRY-LMNT-TYP
PHS PK-CHR PLSP PN PN-STRM-P PP PPLY PPND PPR-CS-P
PPRNT PPRNT-DSPTCH PPRNT-FLL PPRNT-LGCL-BLCK PPRNT-LNR
PPRNT-NDNT PPRNT-NWLN PPRNT-PP PPRNT-TB PPRNT-TBLR
PPRNT-XT-F-LST-XHSTD PRB-FL PRCLM PRG PRG* PRG1 PRG2
PRGN PRGRM-RRR PRGV PRLS PRN1 PRN1-T-STRNG PRNC
PRNC-T-STRNG PRNT PRNT-BJCT PRNT-NRDBL-BJCT PRNT-NT-RDBL
PRNT-NT-RDBL-BJCT PRPS PRPS-LST PRS-NMSTRNG PRS-NTGR
PRS-RRR PRVD PSH PSHNW PSTF PSTN PSTN-F PSTN-F-NT PSTQ
PTHNM PTHNM-DRCTRY PTHNM-DVC PTHNM-HST PTHNM-MTCH-P
PTHNM-NM PTHNM-TY
...
I plan to get even more impressive results with the following
strategy:
* remove all double characters
* remove T and Y
* remove dashes and combine 4-2-letter subsequences
This would reduce UNWIND-PROTECT just to NWDPR.
DESTRUCTURING-BIND would be DSTRBN.
Another set of experiments will remove random symbols
and see if typical programs still run.
On Jan 31, 10:58 am, Rainer Joswig <······@lisp.de> wrote:
> It is well known that names are still recognizable when you
> remove the vocals.
DB2 shops have you beat on this one, at least when it comes to column
names!
Rainer Joswig wrote:
> Here is a (partial) result of a first try:
>
> NTGR-DCD-FLT NTGR-LNGTH NTGRP NTH NTH-VL NTHCDR NTLZ-NSTNC
> NTNLN NTNY NTRC NTRCTV-STRM-P NTRN NTRNL-TM-NTS-PR-SCND
> NTRSCTN NTVRY NVK-DBGGR NVK-RSTRT NVK-RSTRT-NTRCTVLY
It's the PPC instruction set ...
-dan
From: Duane Rettig
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <o063x9sr5q.fsf@gemini.franz.com>
···@telent.net writes:
> Rainer Joswig wrote:
>> Here is a (partial) result of a first try:
>> NTGR-DCD-FLT NTGR-LNGTH NTGRP NTH NTH-VL NTHCDR NTLZ-NSTNC
>> NTNLN NTNY NTRC NTRCTV-STRM-P NTRN NTRNL-TM-NTS-PR-SCND
>> NTRSCTN NTVRY NVK-DBGGR NVK-RSTRT NVK-RSTRT-NTRCTVLY
>
> It's the PPC instruction set ...
Nah; it's missing eieio and lfsux ...
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
On Jan 31, 8:09 am, are <·········@gmx.net> wrote:
> On 31 Jan, 11:32, "j.oke" <········@gmail.com> wrote:
[...]
> 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?
I think the problem with Arc isn't its fundamental differences from
existing Lisp dialects, but rather its fundamental sameness.
Cheers, Pillsy
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <60eaguF1pu64pU1@mid.individual.net>
are wrote:
> On 31 Jan, 11:32, "j.oke" <········@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/
From: [Invalid-From-Line]
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <MPG.220c384fac0304e6989681@news.t-com.hr>
>
> 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.
I agree with that. It is hard to see much purpose in designing
new dialect so similar to existing ones. Clojure is much
bolder, although author was bit too conservative with
evaluation of maps and vectors. It would be really nice if
(setf x 1) has equivalents in [setf x 1] and, say, {:main setf
:place x :value 1}.
a> While I can understand that item 1 would arouse strong feelings in
a> many Lispers, I'd have thought that the others would not raise
a> passions. The amount of debate about Arc seems to suggest, however,
a> that there are some more fundamental differences that I'm missing.
a> What are those?
i believe the only real difference is style.
certainly you can program in Common Lisp in this style, reproducing all
shortcuts and sugar, but barely anyone does so -- as there can be variations
in styles, people won't understand each other.
i.e. in a wild i've seen AIF, LET-IF and IF-BIND macros all serving same
purpose, and there's also Foderaro's IF* weirdness..
but Paul brands his language as totally new, and so he can promote his style
this way, and methodology/ideology too.
is it a good style? we'll see, but as for me it would be interesting to try
it (however, i suspect i just don't think fast enough for this language, but
OTOH traditional CL style annoys me from time to time..)
In article
<····································@i7g2000prf.googlegroups.com>,
······@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.
From: Maciej Katafiasz
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fnojec$4qp$1@news.net.uni-c.dk>
Den Tue, 29 Jan 2008 14:55:40 -0800 skrev usenet:
> 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?
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
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <479fd961$0$25024$607ed4bc@cv.net>
Maciej Katafiasz wrote:
> Den Tue, 29 Jan 2008 14:55:40 -0800 skrev usenet:
>
>
>>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?
>
>
> 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.
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.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <·········@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 <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Maciej Katafiasz
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fnprd6$4qp$8@news.net.uni-c.dk>
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
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
From: Joost Diepenmaat
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <874pcwm89x.fsf@zeekat.nl>
······@kfischer.com writes:
> 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?
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.
> 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
From: Paul Donnelly
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <878x275e3y.fsf@plap.localdomain>
··············@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.
From: John
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fnqi56$stq$7@aioe.org>
Paul Donnelly wrote:
>··············@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.
Shades of System.out.print/System.out.println
Perhaps I'm too used to printf.
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <60aqfeF1pu427U1@mid.individual.net>
······@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? What do you think will be the long
> term impact of Arc on CL?
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/
On Jan 29, 11:55 pm, ······@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? What do you think will be the long
> term impact of Arc on CL?
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.
······@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? What do you think will be the long
> term impact of Arc on CL?
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.
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a0e3f4$0$25065$607ed4bc@cv.net>
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?
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
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
From: John
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fnqnld$stq$9@aioe.org>
Thomas M. Hermann <········@centurytel.net> wrote:
>······@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? What do you think will be the long
>> term impact of Arc on CL?
>
>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.
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.
From: Espen Vestre
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m17ihrc8h2.fsf@vestre.net>
"Thomas M. Hermann" <········@centurytel.net> writes:
> Arc will establish CL as the language that saved the world.
Good one, thanks for the laugh :-)
--
(espen)
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t5qxjrscut4oq5@pandora.alfanett.no>
P� Tue, 29 Jan 2008 23:55:40 +0100, skrev <······@kfischer.com>:
> 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?
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
> »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.
From: ····@csplan9.rit.edu
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fnqfku$stq$6@aioe.org>
>> =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!
> 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
> 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).
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t5rg6bv5ut4oq5@pandora.alfanett.no>
P� Wed, 30 Jan 2008 20:42:31 +0100, skrev <··············@gmail.com>:
>> 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
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
> 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... :)
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t5rl1ydkut4oq5@pandora.alfanett.no>
P� Wed, 30 Jan 2008 23:43:15 +0100, skrev <··············@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
On Jan 30, 1:12 pm, "John Thingstad" <·······@online.no> wrote:
> På Wed, 30 Jan 2008 20:42:31 +0100, skrev <··············@gmail.com>:
>
> 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.
I've always hated it too. Try my version of the LET macro.
http://common-lisp.net/project/misc-extensions/
With it you can say
(let ((val1 val2 (form-returning-two-values)))
...)
-- Scott
On Feb 4, 6:53 am, Scott Burson <········@gmail.com> wrote:
> On Jan 30, 1:12 pm, "John Thingstad" <·······@online.no> wrote:
>
> > På Wed, 30 Jan 2008 20:42:31 +0100, skrev <··············@gmail.com>:
>
> > 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.
>
> I've always hated it too. Try my version of the LET macro.
>
> http://common-lisp.net/project/misc-extensions/
>
> With it you can say
>
> (let ((val1 val2 (form-returning-two-values)))
> ...)
>
> -- Scott
Redefining let, eh. Why not using a new name something like let+ or
whatever else?
BTW lisp is PITA when you want to do call be reference programming,
the C-ish styke with assignments.
cheers
Slobodan
On Feb 4, 2:59 am, Slobodan Blazeski
> Redefining let, eh. Why not using a new name something like let+ or
> whatever else?
let-values
let*-values
letrec-values
On Feb 4, 5:35 pm, Griff <·······@gmail.com> wrote:
> On Feb 4, 2:59 am, Slobodan Blazeski
>
> > Redefining let, eh. Why not using a new name something like let+ or
> > whatever else?
>
> letrec-values
Hey no scheming down here, this c.l.l. (common lisp language)
Slobodan
http://tourdelisp.blogspot.com/
From: Pascal J. Bourguignon
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <7ctzkp13qh.fsf@pbourguignon.anevia.com>
Slobodan Blazeski <·················@gmail.com> writes:
> BTW lisp is PITA when you want to do call be reference programming,
> the C-ish styke with assignments.
Not true.
It is trivial:
(defun f (*y)
(incf (ref *y)))
(let ((x 1)
(a (make-array 10 :initial-element 0)))
(f (& (aref a (incf x))))
a)
--> #(0 0 1 0 0 0 0 0 0 0)
.
.
.
.
.
.
.
.
.
.
.
With, for example, and out of the top of my hat:
(defmacro & (place &environment env)
(multiple-value-bind (vars vals store-vars writer-form reader-form)
(get-setf-expansion place env)
(when (cdr store-vars) (error "Can't expand this."))
`(let* (,@(mapcar (function list) vars vals))
(lambda (message &optional value)
(ecase message
((get) ,reader-form)
((set) (let ((,(car store-vars) value))
,writer-form)))))))
(defun ref (locative)
(funcall locative 'get))
(defun (setf ref) (value locative)
(funcall locative 'set value))
Also, you could have used group.google.com and found a lot of other
posts about it, using the 'reference' or 'locative' keywords.
--
__Pascal Bourguignon__
On Feb 4, 10:16 am, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
> > BTW lisp is PITA when you want to do call be reference programming,
> > the C-ish styke with assignments.
>
> Not true.
>
> It is trivial:
>
> (defun f (*y)
> (incf (ref *y)))
>
> (let ((x 1)
> (a (make-array 10 :initial-element 0)))
> (f (& (aref a (incf x))))
> a)
>
> --> #(0 0 1 0 0 0 0 0 0 0)
>
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
> .
>
> With, for example, and out of the top of my hat:
>
> (defmacro & (place &environment env)
> (multiple-value-bind (vars vals store-vars writer-form reader-form)
> (get-setf-expansion place env)
> (when (cdr store-vars) (error "Can't expand this."))
> `(let* (,@(mapcar (function list) vars vals))
> (lambda (message &optional value)
> (ecase message
> ((get) ,reader-form)
> ((set) (let ((,(car store-vars) value))
> ,writer-form)))))))
>
> (defun ref (locative)
> (funcall locative 'get))
>
> (defun (setf ref) (value locative)
> (funcall locative 'set value))
>
> Also, you could have used group.google.com and found a lot of other
> posts about it, using the 'reference' or 'locative' keywords.
>
> --
> __Pascal Bourguignon__
Cool thanks
Slobodan
From: Paul Donnelly
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <87sl08kcgh.fsf@plap.localdomain>
Slobodan Blazeski <·················@gmail.com> writes:
> On Feb 4, 6:53 am, Scott Burson <········@gmail.com> wrote:
>> On Jan 30, 1:12 pm, "John Thingstad" <·······@online.no> wrote:
>>
>> > På Wed, 30 Jan 2008 20:42:31 +0100, skrev <··············@gmail.com>:
>>
>> > 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.
>>
>> I've always hated it too. Try my version of the LET macro.
>>
>
> Redefining let, eh. Why not using a new name something like let+ or
> whatever else?
Or "bind", perhaps?
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <60oo2fF1s0nk3U1@mid.individual.net>
Paul Donnelly wrote:
> Slobodan Blazeski <·················@gmail.com> writes:
>
>> On Feb 4, 6:53 am, Scott Burson <········@gmail.com> wrote:
>>> On Jan 30, 1:12 pm, "John Thingstad" <·······@online.no> wrote:
>>>
>>>> På Wed, 30 Jan 2008 20:42:31 +0100, skrev <··············@gmail.com>:
>>>> 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.
>>> I've always hated it too. Try my version of the LET macro.
>>>
>> Redefining let, eh. Why not using a new name something like let+ or
>> whatever else?
>
> Or "bind", perhaps?
Hey, that's faaaaaar too long... :-P
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/
On Feb 4, 10:07 am, Pascal Costanza <····@p-cos.net> wrote:
> Paul Donnelly wrote:
> > Slobodan Blazeski <·················@gmail.com> writes:
[...]
> >> Redefining let, eh. Why not using a new name something like let+ or
> >> whatever else?
> > Or "bind", perhaps?
> Hey, that's faaaaaar too long... :-P
In honor of Arc, I think it should be called BND. :)
Cheers, Pillsy
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <60p2q4F1r262fU1@mid.individual.net>
Pillsy wrote:
> On Feb 4, 10:07 am, Pascal Costanza <····@p-cos.net> wrote:
>> Paul Donnelly wrote:
>>> Slobodan Blazeski <·················@gmail.com> writes:
> [...]
>>>> Redefining let, eh. Why not using a new name something like let+ or
>>>> whatever else?
>
>>> Or "bind", perhaps?
>
>> Hey, that's faaaaaar too long... :-P
>
> In honor of Arc, I think it should be called BND. :)
No, no, it should be called BN.
Or what about B? (I mean, without the question mark, of course...)
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/
On Feb 4, 12:59 am, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Feb 4, 6:53 am, Scott Burson <········@gmail.com> wrote:
> > Try my version of the LET macro.
>
> >http://common-lisp.net/project/misc-extensions/
>
> > With it you can say
>
> > (let ((val1 val2 (form-returning-two-values)))
> > ...)
>
> Redefining let, eh. Why not using a new name something like let+ or
> whatever else?
Because my version is completely upward-compatible.
-- Scott
On Feb 4, 6:31 pm, Scott Burson <········@gmail.com> wrote:
> On Feb 4, 12:59 am, Slobodan Blazeski <·················@gmail.com>
> wrote:
>
> > On Feb 4, 6:53 am, Scott Burson <········@gmail.com> wrote:
> > > Try my version of the LET macro.
>
> > >http://common-lisp.net/project/misc-extensions/
>
> > > With it you can say
>
> > > (let ((val1 val2 (form-returning-two-values)))
> > > ...)
>
> > Redefining let, eh. Why not using a new name something like let+ or
> > whatever else?
>
> Because my version is completely upward-compatible.
I should have added: the implementation also exports the same macro
under the name NLET, if you prefer that.
-- Scott
??>> 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.
> 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)
On Jan 30, 5:57 pm, ··············@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.
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a1541b$0$6344$607ed4bc@cv.net>
···········@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...
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Wed, 30 Jan 2008 23:52:50 -0500, Ken Tilton
<···········@optonline.net> wrote:
>Have you noticed no one rags on Bush any more?
Amazing since his approval rating is twice that of Congress. You'd
think the critics would want to go after the popular target.
George
--
for email reply remove "/" from address
On Jan 30, 8:08 am, "John Thingstad" <·······@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...
On Jan 29, 3:55 pm, ······@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? What do you think will be the long
> term impact of Arc on CL?
Sounds like an unfortunate waste of time to me. Instead of focusing on
CL and thinking about improving it this is yet another "Lisp inspired
but even better syntax" programming language experiment. Current CL
users are unlikely to perceive dropping a few "("s here and there to
be a real benefit. Potential users are more likely to go with
established languages that may be conceptually influenced by Lisp
including Ruby, Python and, yes, even Java.
I do thank Paul for writing inspiring stories about CL. They have
served a great value to the CL community. However, to call something
like ARC a language or a dialect sounds a bit grandiose to me. Is Arc
more than a collection of CL macros?
In the end all of this boils down into energy that is wasted.In my
mind CL does have a couple of real shortcomings. However these could
be fixed with writing extensions to Lisp in Lisp. We do not need
alternatives to CL, we need an improved CL. For instance, I would like
to see URL/URI in the language to replace the somewhat broken logical
pathnames; a portable process implementation supporting multicore
CPUs; portable non-clim GUI; ....
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a21750$0$25033$607ed4bc@cv.net>
··············@gmail.com wrote:
> On Jan 29, 3:55 pm, ······@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? What do you think will be the long
>>term impact of Arc on CL?
>
>
> Sounds like an unfortunate waste of time to me. Instead of focusing on
> CL and thinking about improving it this is yet another "Lisp inspired
> but even better syntax" programming language experiment.
OK, but don't forget, PG really does not like CL. And it looks like he
has the same problems I have with Scheme: no macros and distinguishing
nil and false.
> Current CL
> users are unlikely to perceive dropping a few "("s here and there to
> be a real benefit.
PG says he loves programming in Arc, maybe there is something there.
I'll know soon, I am going to be porting cells to arc for a few days.
Thank god this came along, I had already resumed work on the project I
am supposed to doe doing.
But the benefit to CLers is greater mindshare and popularity of Lisp.
Just think, in three years people will be demanding you port AgentSheets
to CL. Or Arc. :)
> Potential users are more likely to go with
> established languages that may be conceptually influenced by Lisp
> including Ruby, Python and, yes, even Java.
No, no, no. How did Ruby steal Python's lunch? Blocks. We are not wrong,
Lisp is insanely good, and people recognize it once they Actually Try
It. They will try Arc because of PG, or at least enough will to
kickstart The Second Coming of Lisp.
Didn't you people see the secret plans?
>
> I do thank Paul for writing inspiring stories about CL. They have
> served a great value to the CL community. However, to call something
> like ARC a language or a dialect sounds a bit grandiose to me. Is Arc
> more than a collection of CL macros?
That's very funny. We run around bragging about how macros let us build
new languages on Lisp and then when someone uses a whole lot of macros
to create a new dialect we say, Come on, it's just a bunch of macros.
Wait... I hear a "Turing equivalent" comment coming down the hall!
As for calling it a whole language, well, marketing has never been the
same since Cassius "I am the greatest!" Clay.
>
> In the end all of this boils down into energy that is wasted.In my
> mind CL does have a couple of real shortcomings. However these could
> be fixed with writing extensions to Lisp in Lisp. We do not need
> alternatives to CL, we need an improved CL.
Arc may just be vanity publishing for the computer age, or it could be
PGs continuing thank you note to Lisp for making him a millionaire, or
it could be PGs gift to mankind. Give the guy credit, he done good with
Lisp then turned around and wrote not one but two books on the subject,
never mind all those essays. Stop there he did not. Y-Combinator,
smiling on tho not demanding Lisp. Was he done? Nope, the books and
essays had helped lift Lisp from the AI winter (see RtL for proof) and
growth was steady and inevitable, but still going slower than it should.
So he* hunkered down and got Arc to where it could be released.
And Ron and other nutjobs were right: purely for marketing purposes,
Lisp needed a new name and a rock star BDFL. Arc will take five years
off the World Domination COuntdown.
> portable non-clim GUI; ....
http://common-lisp.net/project/cells-gtk/
http://common-lisp.net/project/cello/
...but the winner is:
http://common-lisp.net/cgi-bin/viewcvs.cgi/Celtk/?root=cells
No page yet.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a21b1b$0$25037$607ed4bc@cv.net>
Ken Tilton wrote:
> So he* hunkered down and got Arc to where it could be released.
* Robert Morris barely gets mentioned! He is the Woz of Arc.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a2236f$0$25027$607ed4bc@cv.net>
Ken Tilton wrote:
> No, no, no. How did Ruby steal Python's lunch? Blocks. We are not wrong,
> Lisp is insanely good, and people recognize it once they Actually Try
> It. They will try Arc because of PG, or at least enough will to
> kickstart The Second Coming of Lisp.
>
> Didn't you people see the secret plans?
From:
http://jfkbits.blogspot.com/2008/01/digging-into-arc-in-24-macros-or-less.html
"This Arc release actually got me moving from thinking about
Lisp/Scheme to actually using it, and appreciating macros. I do admit
that I enjoy the brevity of the keywords and design of the syntactic
forms, and if that's all Arc ever is it's still value-added."
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Jan 31, 11:45 am, Ken Tilton <···········@optonline.net> wrote:
> But the benefit to CLers is greater mindshare and popularity of Lisp.
> Just think, in three years people will be demanding you port AgentSheets
> to CL. Or Arc. :)
no need to port AgentSheets to CL. We already have a CL version.
For the Arc port we would have to wait for Arc with object
orientation; Arc++ ...
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a36ae3$0$6336$607ed4bc@cv.net>
··············@gmail.com wrote:
> On Jan 31, 11:45 am, Ken Tilton <···········@optonline.net> wrote:
>
>
>>But the benefit to CLers is greater mindshare and popularity of Lisp.
>>Just think, in three years people will be demanding you port AgentSheets
>>to CL. Or Arc. :)
>
>
> no need to port AgentSheets to CL. We already have a CL version.
Ah, you are maintaining both? You must be an expert on Lisp vs. Java by now.
>
> For the Arc port we would have to wait for Arc with object
> orientation; Arc++ ...
This seems to be where Arc is more Schemey: we each are supposed to roll
our own object systems so we cannot share code.
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Maciej Katafiasz
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fnvthl$bel$3@news.net.uni-c.dk>
Den Fri, 01 Feb 2008 13:54:26 -0500 skrev Ken Tilton:
>> For the Arc port we would have to wait for Arc with object orientation;
>> Arc++ ...
>
> This seems to be where Arc is more Schemey: we each are supposed to roll
> our own object systems so we cannot share code.
Don't be silly. Code reuse is a dumb corporate myth, clearly against the
spirit of exploratory programming.
Cheers,
Maciej
······@kfischer.com wrote:
> http://paulgraham.com/arc0.html
What do you think will be the long
> term impact of Arc on CL?
Maybe CL 2.0, but right now It reveales that Scheme is a great language
to build new systems atop and worth to emerge from primarily academia.
Johann
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <60hjpkF1qnejhU1@mid.individual.net>
······@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? What do you think will be the long
> term impact of Arc on CL?
The question is stated wrong. Arc won't have a direct impact on CL.
However, the long-term impact on Lisp in general may actually be a bad
one. Arc is likely to reinstate old prejudices against Lisp, especially
the one that it's all "just" lists. This won't have a direct impact on
Scheme and CL, though, because these are languages that are used mostly
only by self-motivated programmers anyway. The sad thing is that CL and
Scheme had somewhat of an increase in popularity in recent years, but
Arc may distract potentially interested users. It actually already did
so because some people decided to wait for Arc instead of looking at any
of the existing Lisps. "Newer is better", you know... :(
If Arc gets successful (which I don't think is likely) it will look like
a mix of several known Lisp dialects from the 80's and 90's within 10-15
years from now, but there won't be anything substantially new. It will
probably be worse than CL or Scheme. Paul Graham's version won't take
over (mostly because he won't spend enough time on developing Arc
further), but someone else may do a relatively successful fork that may
make Arc somewhat popular (somewhat below Python and Ruby).
Arc will have objects sooner or later. But it will be only
single-inheritance, single-dispatch crap. ("It's so much easier to get
this into your head.")
To take a somewhat positive spin: It doesn't really matter that much
whether Arc is successful or not. If it's not, all will be fine, and we
can continue to focus on more important things. If it is, we can expect
more people to have some basic knowledge of Lisp concepts, and can
describe the advantages of the better Lisp dialects by comparing them
with Arc. That may make our life somewhat easier than having to compare
Lisp with Java, Python, Ruby, etc., all the time... ;)
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/
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t5wcrclrut4oq5@pandora.alfanett.no>
P� Fri, 01 Feb 2008 23:12:03 +0100, skrev Pascal Costanza <··@p-cos.net>:
>
> To take a somewhat positive spin: It doesn't really matter that much
> whether Arc is successful or not. If it's not, all will be fine, and we
> can continue to focus on more important things. If it is, we can expect
> more people to have some basic knowledge of Lisp concepts, and can
> describe the advantages of the better Lisp dialects by comparing them
> with Arc. That may make our life somewhat easier than having to compare
> Lisp with Java, Python, Ruby, etc., all the time... ;)
I think you are overly negative about it. Paul Graham is primarily
concerned with web programming and Arc is more of a direct contender to
Ruby than Common Lisp. It will probably be neither as efficient or
generally applicable as CL.
Never the less it might some day make todays Perl, PHP, Python and Ruby
programmers consider Lisp.
As such it could actually draw people to Lisp the way elisp has in the
past.
I wouldn't be surprised to find people here in a few years whose first
experience with Lisp was Arc.
I see no reason why you would need anything revolutionary new to do do web
programming.
It exist primarily to make programming more enjoyable by wasting less time
on repetitive work.
What Arc has is a strong conviction about style and a underlying
philosophy behind his idea.
It might not be to your taste, but a strong underlying philosophy is
probably what made Emacs the success it is f.e.s. (Of cource there are
still people who hate Emacs..)
--------------
John Thingstad
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a4a3b6$0$25060$607ed4bc@cv.net>
John Thingstad wrote:
> P� Fri, 01 Feb 2008 23:12:03 +0100, skrev Pascal Costanza <··@p-cos.net>:
>
>>
>> To take a somewhat positive spin: It doesn't really matter that much
>> whether Arc is successful or not. If it's not, all will be fine, and
>> we can continue to focus on more important things. If it is, we can
>> expect more people to have some basic knowledge of Lisp concepts, and
>> can describe the advantages of the better Lisp dialects by comparing
>> them with Arc. That may make our life somewhat easier than having to
>> compare Lisp with Java, Python, Ruby, etc., all the time... ;)
>
>
> I think you are overly negative about it. Paul Graham is primarily
> concerned with web programming...
In designing a hundred year language? No, that is just good positioning
to jumpstart his language.
>... and Arc is more of a direct contender to
> Ruby than Common Lisp. It will probably be neither as efficient or
> generally applicable as CL.
Only in the short term on efficiency, and not now on the applicable.
>
> Never the less it might some day make todays Perl, PHP, Python and Ruby
> programmers consider Lisp.
? It already has, and they are blogging about it. You might want to
start following the forum to find out what is going on.
> As such it could actually draw people to Lisp the way elisp has in the
> past.
Done deal.
> I wouldn't be surprised to find people here in a few years whose first
> experience with Lisp was Arc.
Make that "in a few weeks". The language is great but the community has
already found a bunch of bugs and there is no documentation and no
mechanism for incorporating bug fixes into an official version and
anyway PG promises to change Arc in ways that will break all existing
code so here is what is going to happen. People will try Arc and fall in
love with Lisp and in three weeks get fed up and move to CL.
We're gonna need a bigger kennel.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: ozan s yigit
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <vi4bq6zf6be.fsf@red.cs.yorku.ca>
Ken Tilton <···········@optonline.net> writes in part:
> ... The language is great but the community
> has already found a bunch of bugs and there is no documentation and no
> mechanism for incorporating bug fixes into an official version and
> anyway PG promises to change Arc in ways that will break all existing
> code so here is what is going to happen. People will try Arc and fall
> in love with Lisp and in three weeks get fed up and move to CL.
um, how does one decide a language is "great" with so little?
is it obvious in a "zen and the art of motorcycle maintenance"
sort of way?
[i was a schemer once; i thought greatness took a lot of implementation
and argumentation... 8-]
oz
--
practically no other lisp in the language forest looked so
lisp-like as this lisp. -- with apologies to terry pratchett
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a5021d$0$25045$607ed4bc@cv.net>
ozan s yigit wrote:
> Ken Tilton <···········@optonline.net> writes in part:
>
>
>> ... The language is great but the community
>>has already found a bunch of bugs and there is no documentation and no
>>mechanism for incorporating bug fixes into an official version and
>>anyway PG promises to change Arc in ways that will break all existing
>>code so here is what is going to happen. People will try Arc and fall
>>in love with Lisp and in three weeks get fed up and move to CL.
>
>
> um, how does one decide a language is "great" with so little?
> is it obvious in a "zen and the art of motorcycle maintenance"
> sort of way?
Sorry, it's back to the temple for ten more years for you. Lisp was
great even before that grad student created an interpreter for it on his
abacus.
> [i was a schemer once; i thought greatness took a lot of implementation
> and argumentation... 8-]
You do not understand. PG started from the best of Scheme, CL, and K.
Talk about shoulder-standing. Mind you he reports also having to think
very hard, so if you have not seen the versions he threw out you do not
know how little is there. Remember also that before Lincoln gave his
Gettysburg Address a local politician did the expected thing and spoke
for two hours. Hell, even Lincoln felt bad about how short it was.
Something like that.
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: ozan s yigit
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <vi4hcgqir4d.fsf@red.cs.yorku.ca>
Ken Tilton <···········@optonline.net> writes:
> > um, how does one decide a language is "great" with so little?
> > is it obvious in a "zen and the art of motorcycle maintenance"
> > sort of way?
>
> Sorry, it's back to the temple for ten more years for you. Lisp was
> great even before that grad student created an interpreter for it on
> his abacus.
i don't do temples. there was a literary/philosophical allusion there
but perhaps long before your time. see robert m. pirsig.
>
> > [i was a schemer once; i thought greatness took a lot of implementation
> > and argumentation... 8-]
>
> You do not understand. PG started from the best of Scheme, CL, and
> K. Talk about shoulder-standing. [...]
i understand all too well. yes there is much shoulder standing amongst
lisp family of languages, nearly inevitable, and most of it eventually
horizontal. in any case, best wishes and have fun coding useful things.
oz
--
if you couldn't find any weirdness, maybe
we'll just have to make some! -- hobbes
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a56e50$0$15183$607ed4bc@cv.net>
ozan s yigit wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>>um, how does one decide a language is "great" with so little?
>>>is it obvious in a "zen and the art of motorcycle maintenance"
>>>sort of way?
>>
>>Sorry, it's back to the temple for ten more years for you. Lisp was
>>great even before that grad student created an interpreter for it on
>>his abacus.
>
>
> i don't do temples. there was a literary/philosophical allusion there
> but perhaps long before your time. see robert m. pirsig.
See "I already read it.". The guy has a mental breakdown and turns it
into a book, tries to save his soul with Quality. Only good part was the
bit where his kid had to find their way home because Dad had snapped one
day. I actually ported that to a day hike with some inner city kids,
pretended I was lost (conspicuously, but they still went into survival
mode) and they had to find our way back to civilization.
No, the point I was trying to make is that greatness must be there from
the beginning or not at all. One does not achieve greatness in the last
chapter of the dummies book or revision 12.183.37.
btw, you are not really so far off with zatamm. Had you stopped with z I
would have showered you with bouquets of roses. Zen rejects the mind and
embraces, er, I dunna know, but def letting go and letting the gut talk.
The arrow releases itself, and in boxing the punch throws itself. I just
hate to dress up my assessment in grandiosities like that, as much into
self-glorification as I am.
I've simply been programming for way too frickin long and (cue the Zen)
I learned a while ago to shut up and listen. To myself, of course, not
you yobbos. Generally this is called learning to trust one's instincts.
But this is Lisp, let's cut to the AI. Car and Driver will spend a week
testing a hot new car. Michael Schumacher could back it out of its
parking space and know. If it has a reverse. Kasparov looks at three
moves, his "conqueror" has to look at three kabillion moves. How the
hell do we do that? Zen, schmen, its lotsa experience. Everyone sees the
differences, the Master knows which differences matter, albeit via a
neuronal calculus the Master does not know. What separates the Master is
realizing that this unknowable calculus knows better and so to shut down
the mind so the calculus can Speak. Zen seeks improvement thru less mind.
>>>[i was a schemer once; i thought greatness took a lot of implementation
>>>and argumentation... 8-]
>>
>>You do not understand. PG started from the best of Scheme, CL, and
>>K. Talk about shoulder-standing. [...]
>
>
> i understand all too well. yes there is much shoulder standing amongst
> lisp family of languages, nearly inevitable, and most of it eventually
> horizontal.
Out! Out, damned pessimism! (Borrowing from Stephen King, I think.) Is
tersosity all that CL needs to rule the world? <gasp>
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: ozan s yigit
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <vi44pcqrp1a.fsf@red.cs.yorku.ca>
Ken Tilton <···········@optonline.net> on ZMM
> See "I already read it.". The guy has a mental breakdown and turns it
> into a book, tries to save his soul with Quality. Only good part was
> the bit where his kid had to find their way home because Dad had
> snapped one day. [...]
hmm, i did not realize there was a comic book edition.
> Is tersosity all that CL needs to rule the world? <gasp>
sure, something has to fill the vacuum perl 6 created... :-]
oz
---
don't count your chickens in glass houses until the cows come home.
-- david vestal
From: Maciej Katafiasz
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fo2dhh$dc0$4@news.net.uni-c.dk>
Den Sat, 02 Feb 2008 12:09:11 -0500 skrev Ken Tilton:
> Make that "in a few weeks". The language is great but the community has
> already found a bunch of bugs and there is no documentation and no
> mechanism for incorporating bug fixes into an official version and
> anyway PG promises to change Arc in ways that will break all existing
> code so here is what is going to happen. People will try Arc and fall in
> love with Lisp and in three weeks get fed up and move to CL.
One has to wonder if an influx of newbs bitching about CL not being like
Arc is better or worse than an influx of newbs bitching about CL not
being like Python/Ruby/C#/whatever. At least they won't be moaning about
lacking packages system :)
Cheers,
Maciej
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a4ff42$0$25028$607ed4bc@cv.net>
Maciej Katafiasz wrote:
> Den Sat, 02 Feb 2008 12:09:11 -0500 skrev Ken Tilton:
>
>
>>Make that "in a few weeks". The language is great but the community has
>>already found a bunch of bugs and there is no documentation and no
>>mechanism for incorporating bug fixes into an official version and
>>anyway PG promises to change Arc in ways that will break all existing
>>code so here is what is going to happen. People will try Arc and fall in
>>love with Lisp and in three weeks get fed up and move to CL.
>
>
> One has to wonder if an influx of newbs bitching about CL not being like
> Arc is better or worse than an influx of newbs bitching about CL not
> being like Python/Ruby/C#/whatever.
What part of "we are going to need a bigger kennel" did you notunderstand?
And don't forget, we just point to /the ANSI standard/ and say we agree
with them completely but our hands are tied.
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Edi Weitz
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <uejbvt9wu.fsf@agharta.de>
On Sat, 02 Feb 2008 12:09:11 -0500, Ken Tilton <···········@optonline.net> wrote:
>> I wouldn't be surprised to find people here in a few years whose
>> first experience with Lisp was Arc.
>
> Make that "in a few weeks". The language is great but the community
> has already found a bunch of bugs and there is no documentation and
> no mechanism for incorporating bug fixes into an official version
> and anyway PG promises to change Arc in ways that will break all
> existing code so here is what is going to happen. People will try
> Arc and fall in love with Lisp and in three weeks get fed up and
> move to CL.
Sounds good. Reading your postings from the last few days I became
scared you'd sooner or later propose to talk about Arc in Amsterdam.
(No way!)
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a500a4$0$25045$607ed4bc@cv.net>
Edi Weitz wrote:
> On Sat, 02 Feb 2008 12:09:11 -0500, Ken Tilton <···········@optonline.net> wrote:
>
>
>>>I wouldn't be surprised to find people here in a few years whose
>>>first experience with Lisp was Arc.
>>
>>Make that "in a few weeks". The language is great but the community
>>has already found a bunch of bugs and there is no documentation and
>>no mechanism for incorporating bug fixes into an official version
>>and anyway PG promises to change Arc in ways that will break all
>>existing code so here is what is going to happen. People will try
>>Arc and fall in love with Lisp and in three weeks get fed up and
>>move to CL.
>
>
> Sounds good. Reading your postings from the last few days I became
> scared you'd sooner or later propose to talk about Arc in Amsterdam.
> (No way!)
You lack imagination grasshopper. Where will Arc be in three months?
Returned to Earth, or happily in orbit readying itself for the next leg
to Mars? I'll be standing there trying to talk about Cells and Algebra
and even blinking my own damn cursor and you all will be yelling out "we
want Arc! we want Arc!". It will be pandemonium, I can see it now.
Well, Lisp-NYC and the tables that sit within fifty feet of us can tell
you I do not really need a script and I do not need a microphone once I
get going, my talk might just be "Ask me anything, His Kennyness is
taking questions. Please begin by stating what degree Yobbo you are.".
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <60je0gF1r4q73U1@mid.individual.net>
John Thingstad wrote:
> P� Fri, 01 Feb 2008 23:12:03 +0100, skrev Pascal Costanza <··@p-cos.net>:
>
>>
>> To take a somewhat positive spin: It doesn't really matter that much
>> whether Arc is successful or not. If it's not, all will be fine, and
>> we can continue to focus on more important things. If it is, we can
>> expect more people to have some basic knowledge of Lisp concepts, and
>> can describe the advantages of the better Lisp dialects by comparing
>> them with Arc. That may make our life somewhat easier than having to
>> compare Lisp with Java, Python, Ruby, etc., all the time... ;)
>
> I think you are overly negative about it. Paul Graham is primarily
> concerned with web programming and Arc is more of a direct contender to
> Ruby than Common Lisp. It will probably be neither as efficient or
> generally applicable as CL.
>
> Never the less it might some day make todays Perl, PHP, Python and Ruby
> programmers consider Lisp.
> As such it could actually draw people to Lisp the way elisp has in the
> past.
> I wouldn't be surprised to find people here in a few years whose first
> experience with Lisp was Arc.
>
> I see no reason why you would need anything revolutionary new to do do
> web programming.
> It exist primarily to make programming more enjoyable by wasting less
> time on repetitive work.
>
> What Arc has is a strong conviction about style and a underlying
> philosophy behind his idea.
> It might not be to your taste, but a strong underlying philosophy is
> probably what made Emacs the success it is f.e.s. (Of cource there are
> still people who hate Emacs..)
I don't care about style and philosophy. I think it's a good thing that
Lisp and Scheme allow you to have your own style and not care about the
rest of the world.
What I'm worried about is that people buy into Paul Graham's attempt to
sell this as a programming language, when in fact it's nothing more than
an extremely simple library for MzScheme. (And as such it's a category
error to say that it's a contender to Ruby, Python, PHP, whatever.)
Is this the kind of library Kenny has been asking for over all these years?
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/
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t5wkemqcut4oq5@pandora.alfanett.no>
P� Sat, 02 Feb 2008 15:45:35 +0100, skrev Pascal Costanza <··@p-cos.net>:
>
> What I'm worried about is that people buy into Paul Graham's attempt to
> sell this as a programming language, when in fact it's nothing more than
> an extremely simple library for MzScheme. (And as such it's a category
> error to say that it's a contender to Ruby, Python, PHP, whatever.)
>
This is a bit silly. What does it matter what it was written in?
For all practical purposes you get a Arc prompt and write the code in arc.
I'd say it is (or rather will be someday) a new lisp dialect.
I consider this prototype more as a proof of concept.
--------------
John Thingstad
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a4a5fb$0$25060$607ed4bc@cv.net>
John Thingstad wrote:
> P� Sat, 02 Feb 2008 15:45:35 +0100, skrev Pascal Costanza <··@p-cos.net>:
>
>>
>> What I'm worried about is that people buy into Paul Graham's attempt
>> to sell this as a programming language, when in fact it's nothing
>> more than an extremely simple library for MzScheme. (And as such it's
>> a category error to say that it's a contender to Ruby, Python, PHP,
>> whatever.)
>>
>
> This is a bit silly. What does it matter what it was written in?
> For all practical purposes you get a Arc prompt and write the code in arc.
> I'd say it is (or rather will be someday) a new lisp dialect.
> I consider this prototype more as a proof of concept.
Yep. What matters is that it has a sexy name, a rock star BDFL, and it
is has most of what matters in CL to make it great.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 2, 12:18 pm, Ken Tilton <···········@optonline.net> wrote:
> ..... and it is has most of what matters in CL to make it great.
... But it doesn't have LOOP Kenny! ;-)
"I consider Loop one of the worst flaws in CL, and an example to be
borne in mind by both macro writers and language designers". -- Paul
Graham
http://www.paulgraham.com/loop.html
agt
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a4feb9$0$25028$607ed4bc@cv.net>
viper-2 wrote:
> On Feb 2, 12:18 pm, Ken Tilton <···········@optonline.net> wrote:
>
>
>
>>..... and it is has most of what matters in CL to make it great.
>
>
> ... But it doesn't have LOOP Kenny! ;-)
Fortunately I have decided to get back to CL and stop having fun. As
soon as I flesh out my Arc STRUCT implementation, of course. Hmmm... OK,
it would be funny as hell to do Arc LOOP, drive PG nuts. :)
>
> "I consider Loop one of the worst flaws in CL, and an example to be
> borne in mind by both macro writers and language designers". -- Paul
> Graham
>
> http://www.paulgraham.com/loop.html
The funny thing is I have to stop calling PG a rock star BDFL because
when you give people MAC you cannot be a dictator. How about BCHFL? Cat
herder?
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Maciej Katafiasz
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fo351h$n7u$2@news.net.uni-c.dk>
Den Sat, 02 Feb 2008 18:37:29 -0500 skrev Ken Tilton:
> The funny thing is I have to stop calling PG a rock star BDFL because
> when you give people MAC you cannot be a dictator.
http://en.wikipedia.org/wiki/MAC_spoofing ?
Cheers,
Maciej
Maciej Katafiasz <········@gmail.com> wrote:
+---------------
| skrev Ken Tilton:
| > The funny thing is I have to stop calling PG a rock star BDFL because
| > when you give people MAC you cannot be a dictator.
|
| http://en.wikipedia.org/wiki/MAC_spoofing ?
+---------------
Uh... no. I think he meant <http://alu.org/HyperSpec/Body/mac_defmacro.html>,
since in Arc DEFMACRO is abbreviated [isn't everything?] to just MAC,
see <http://ycombinator.com/arc/tut.txt>.
And Kenny's point was that once you give people macros, you lose
the ability to be able to dictate to them what syntax they can use.
At best you can attempt to herd them (like cats -- ha! fat chance)
into staying near a local minimum of "good style". [Though the
danger persists they will find a *better* (for them) local minimum
somewhere far away from what *you* think is "good style". Tough.]
Hence the suggested replacement of BDFL by BCHFL.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a550e5$0$25045$607ed4bc@cv.net>
Rob Warnock wrote:
> Maciej Katafiasz <········@gmail.com> wrote:
> +---------------
> | skrev Ken Tilton:
> | > The funny thing is I have to stop calling PG a rock star BDFL because
> | > when you give people MAC you cannot be a dictator.
> |
> | http://en.wikipedia.org/wiki/MAC_spoofing ?
> +---------------
>
> Uh... no. I think he meant <http://alu.org/HyperSpec/Body/mac_defmacro.html>,
> since in Arc DEFMACRO is abbreviated [isn't everything?] to just MAC,
> see <http://ycombinator.com/arc/tut.txt>.
Not feeling so bad about plonking Maciej now. :) I think anyone yapping
on an Arc thread who has not programmed in Arc belongs in my killfile.
If they have not even read the tutorial... Tim, can I have the keys to
the helicopters tonight?
Meanwhile I am happily creating DEFUN, a def with optional and keyword
parameters. Of course I am using &k and &o instead. :)
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Maciej Katafiasz
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fo38te$n7u$3@news.net.uni-c.dk>
Den Sat, 02 Feb 2008 19:52:45 -0600 skrev Rob Warnock:
> Maciej Katafiasz <········@gmail.com> wrote:
> | http://en.wikipedia.org/wiki/MAC_spoofing ?
>
> Uh... no. I think he meant
> <http://alu.org/HyperSpec/Body/mac_defmacro.html>, since in Arc DEFMACRO
> is abbreviated [isn't everything?] to just MAC, see
> <http://ycombinator.com/arc/tut.txt>.
>
> And Kenny's point was that once you give people macros, you lose the
> ability to be able to dictate to them what syntax they can use. At best
> you can attempt to herd them (like cats -- ha! fat chance) into staying
> near a local minimum of "good style". [Though the danger persists they
> will find a *better* (for them) local minimum somewhere far away from
> what *you* think is "good style". Tough.] Hence the suggested
> replacement of BDFL by BCHFL.
Yes, I understood all that, I was being facetious. Guess I failed :).
Cheers,
Maciej
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a4f256$0$25059$607ed4bc@cv.net>
Ken Tilton wrote:
>
>
> John Thingstad wrote:
>
>> P� Sat, 02 Feb 2008 15:45:35 +0100, skrev Pascal Costanza <··@p-cos.net>:
>>
>>>
>>> What I'm worried about is that people buy into Paul Graham's attempt
>>> to sell this as a programming language, when in fact it's nothing
>>> more than an extremely simple library for MzScheme. (And as such
>>> it's a category error to say that it's a contender to Ruby, Python,
>>> PHP, whatever.)
>>>
>>
>> This is a bit silly. What does it matter what it was written in?
>> For all practical purposes you get a Arc prompt and write the code in
>> arc.
>> I'd say it is (or rather will be someday) a new lisp dialect.
>> I consider this prototype more as a proof of concept.
>
>
> Yep. What matters is that it has a sexy name, a rock star BDFL, and it
> is has most of what matters in CL to make it great.
btw, if someone has not installed Arc and programmed in it, I am not
sure what their opinion is worth on some questions illuminated only thru
use. meanwhile, here is defstruct lite (very lite):
(mac struct ((name (o pfx (string name "-"))) . slot-defs)
(with (maker (coerce (+ "mk-" (string name)) 'sym)
defmaker (coerce (+ "mk-def-" (string name)) 'sym)
fsd (map [if (acons _) _ (list _ nil)] slot-defs))
`(do
(def ,defmaker ()
(listtab ',fsd))
(def ,maker initargs
(aif (keep [~find _ ',(map carif slot-defs)]
(map car (pair initargs)))
(do (ero "Invalid initargs to " ',maker
" supplied: " it ". Allowed are " ',slot-defs) nil)
(let self (,defmaker)
(map [= (self (car _)) (cadr _)] (pair initargs))
self)))
,@(map (fn (sd)
`(def ,(coerce (+ (string pfx) (string sd)) 'sym) (self)
(self ',sd))) (map carif slot-defs)))))
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <60k6uqF1r9ldcU1@mid.individual.net>
John Thingstad wrote:
> P� Sat, 02 Feb 2008 15:45:35 +0100, skrev Pascal Costanza <··@p-cos.net>:
>
>>
>> What I'm worried about is that people buy into Paul Graham's attempt
>> to sell this as a programming language, when in fact it's nothing more
>> than an extremely simple library for MzScheme. (And as such it's a
>> category error to say that it's a contender to Ruby, Python, PHP,
>> whatever.)
>>
>
> This is a bit silly. What does it matter what it was written in?
It matters a lot.
A colleague of mine sometimes tells the story that when he was very
young (in his teens), he created a "new" programming language by taking
a BASIC interpreter and translating each command in it from English to
Dutch (because it was more "natural" for him to program in Dutch than in
English).
I find it very hard to see how Arc can be regarded as a greater leap of
innovation than that.
To put it differently: The introduction of a foreach statement to Java
was more interesting!
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/
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m37ihm95tm.fsf@winooski.ccs.neu.edu>
Pascal Costanza <··@p-cos.net> writes:
> John Thingstad wrote:
>> På Sat, 02 Feb 2008 15:45:35 +0100, skrev Pascal Costanza <··@p-cos.net>:
>>
>>> What I'm worried about is that people buy into Paul Graham's
>>> attempt to sell this as a programming language, when in fact it's
>>> nothing more than an extremely simple library for MzScheme. (And
>>> as such it's a category error to say that it's a contender to
>>> Ruby, Python, PHP, whatever.)
>>
>> This is a bit silly. What does it matter what it was written in?
>
> It matters a lot.
It matters a lot sometimes. When you create a language L on top of M,
you obviously skip a few things and just inherit M's behavior. For
example, PG would be crazy to implement a new numeric tower instead of
using mzscheme's -- and he did choose a "vm backend" that gives him
many features that he wants (either to use in the implementation, or
to make arc inherit). But calling the result "an extremely simple
library" is as misguided as saying that mzscheme itself is a library
for C. Arc doesn't share many features of mzscheme, for example: the
module system, function applications, hygienic macros or any other
kind of macros (eg, Arc does not have mzscheme's phase separation).
It doesn't even share mzscheme's namespaces -- in fact, if you look at
the arc compiler, you'll see that it's lisp-1-ness is not inherited
from mzscheme, and making it a lisp-2 would be a simple tweak. It
might not be as far from mzscheme as mzscheme is from C, but to
compare it to a translated-basic interpreter is ridiculous.
> I find it very hard to see how Arc can be regarded as a greater leap
> of innovation than that.
All of the above is unrelated to arc being innovative or not, but --
> To put it differently: The introduction of a foreach statement to
> Java was more interesting!
-- that's certainly a much smaller change to java than arc is to
mzscheme (or scheme, or cl, or any other lisp).
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Eli Barzilay <···@barzilay.org> wrote:
+---------------
| Arc doesn't share many features of mzscheme, for example: the
| module system, function applications, hygienic macros or any other
| kind of macros (eg, Arc does not have mzscheme's phase separation).
| It doesn't even share mzscheme's namespaces -- in fact, if you look at
| the arc compiler, you'll see that it's lisp-1-ness is not inherited
| from mzscheme, and making it a lisp-2 would be a simple tweak.
+---------------
Yeah, I was just musing about that -- not making Arc a Lisp-N, but
the other direction: using a Lisp-N (CL) as the backend target of
the Lisp-1 Arc compiler. If one didn't care about the differences
in the underlying semantics [e.g., a different numeric tower than
Scheme], it shouldn't be too hard to port "ac.scm" & "brackets.scm"
to CL, then use them to recompile all the ".arc" files.
Some work would also be needed to replace some of the MzScheme
libraries that get REQUIRE'd; the messiest of those would probably
be "process.ss".
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Sun, 03 Feb 2008 05:21:36 -0600, Rob Warnock wrote:
> Eli Barzilay <···@barzilay.org> wrote: +---------------
> | Arc doesn't share many features of mzscheme, for example: the | module
> system, function applications, hygienic macros or any other | kind of
> macros (eg, Arc does not have mzscheme's phase separation). | It doesn't
> even share mzscheme's namespaces -- in fact, if you look at | the arc
> compiler, you'll see that it's lisp-1-ness is not inherited | from
> mzscheme, and making it a lisp-2 would be a simple tweak.
> +---------------
>
> Yeah, I was just musing about that -- not making Arc a Lisp-N, but the
> other direction: using a Lisp-N (CL) as the backend target of the Lisp-1
> Arc compiler. If one didn't care about the differences in the underlying
> semantics [e.g., a different numeric tower than Scheme], it shouldn't be
> too hard to port "ac.scm" & "brackets.scm" to CL, then use them to
> recompile all the ".arc" files.
It only took about 6 hours to get to the point where arc.arc would
compile in my cl-arc. I gave up on it after this, as it was not much
fun :).
The biggest differences were, of course, lisp1 and call/cc. As luck would
have it, the arnesi library includes code-walkers and interpreters
implementing those two on CL, so it was really just s/fn/lambda +
QUASIQUOTE.
Cheers ,
drewc
>
> Some work would also be needed to replace some of the MzScheme libraries
> that get REQUIRE'd; the messiest of those would probably be
> "process.ss".
>
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/> San Mateo,
CA 94403
> (650)572-2607
--
Posted via a free Usenet account from http://www.teranews.com
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <60luukF1rj5tvU1@mid.individual.net>
Eli Barzilay wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> John Thingstad wrote:
>>> På Sat, 02 Feb 2008 15:45:35 +0100, skrev Pascal Costanza <··@p-cos.net>:
>>>
>>>> What I'm worried about is that people buy into Paul Graham's
>>>> attempt to sell this as a programming language, when in fact it's
>>>> nothing more than an extremely simple library for MzScheme. (And
>>>> as such it's a category error to say that it's a contender to
>>>> Ruby, Python, PHP, whatever.)
>>> This is a bit silly. What does it matter what it was written in?
>> It matters a lot.
>
> It matters a lot sometimes. When you create a language L on top of M,
> you obviously skip a few things and just inherit M's behavior. For
> example, PG would be crazy to implement a new numeric tower instead of
> using mzscheme's -- and he did choose a "vm backend" that gives him
> many features that he wants (either to use in the implementation, or
> to make arc inherit). But calling the result "an extremely simple
> library" is as misguided as saying that mzscheme itself is a library
> for C. Arc doesn't share many features of mzscheme, for example: the
> module system, function applications, hygienic macros or any other
> kind of macros (eg, Arc does not have mzscheme's phase separation).
> It doesn't even share mzscheme's namespaces -- in fact, if you look at
> the arc compiler, you'll see that it's lisp-1-ness is not inherited
> from mzscheme, and making it a lisp-2 would be a simple tweak. It
> might not be as far from mzscheme as mzscheme is from C, but to
> compare it to a translated-basic interpreter is ridiculous.
>
>
>> I find it very hard to see how Arc can be regarded as a greater leap
>> of innovation than that.
>
> All of the above is unrelated to arc being innovative or not, but --
>
>> To put it differently: The introduction of a foreach statement to
>> Java was more interesting!
>
> -- that's certainly a much smaller change to java than arc is to
> mzscheme (or scheme, or cl, or any other lisp).
I seem to be missing something very important, so let me try to rephrase
this as a question: Is there anything in Arc that can't be implemented
as a plain thin library on top of (sufficiently powerful) Scheme or CL
implementations?
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/
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m3lk62nmkz.fsf@winooski.ccs.neu.edu>
Pascal Costanza <··@p-cos.net> writes:
> I seem to be missing something very important,
I think that the best thing you should do is follow Kenny's advice and
use it (then look at the sources).
> so let me try to rephrase this as a question: Is there anything in
> Arc that can't be implemented as a plain thin library on top of
> (sufficiently powerful) Scheme or CL implementations?
At least with MzScheme, it is not implemented as a library, but rather
as a compiler. It reads each sexpr, translates it to MzScheme code,
then evaluate the result. You could probably argue that it can be
viewed as a library -- given a powerful enough language. For example,
when you write a macro in Scheme/CL you say that it's part of a
language -- but in (most) other languages that will be wrong since you
cannot extend the language in that way; when you add a new
concrete-level syntax through a reader macro you can claim that this
is a library in a very few number of languages (BTW, I consider naive
use of CL lacking in that aspect: to consider a reader macro as a
"library", I'd want it to not interfere with code that doesn't use
that library).
So, a few of the features that you'll need to implement arc as a
library are:
* tweak your namespace directly
* redefine the meaning of the function application form (eg, in
mzscheme that's `#%app')
* write symbol macros, and make them access the name of the symbol (eg
the `foo:bar' trick)
* add new special forms (= macros), including ones that are already
part of your core language like `if'
* extend the concrete syntax that gets used for code that uses this
library
Many Schemes fall short on several items, CL too (the first and last),
but I'm sure that you'll squint hard enough to argue that (which will
push this thread down an irrelevant flamewar).
MzScheme does have all of these features, but PG and RTM did not use
them and chose to implement a (to-mzscheme) compiler instead (so the
current implementation is *not* a library). In any case, innovative
or not -- this is far from the standard notion of a library, or from
implementing a new language by translating strings in its
implementation.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <60m2ogF1rmm5nU1@mid.individual.net>
Eli Barzilay wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> I seem to be missing something very important,
>
> I think that the best thing you should do is follow Kenny's advice and
> use it (then look at the sources).
>
>
>> so let me try to rephrase this as a question: Is there anything in
>> Arc that can't be implemented as a plain thin library on top of
>> (sufficiently powerful) Scheme or CL implementations?
>
> At least with MzScheme, it is not implemented as a library, but rather
> as a compiler. It reads each sexpr, translates it to MzScheme code,
> then evaluate the result.
I wasn't interested in how they implemented the syntactic sugar. I was
interested in whether it is more than syntactic sugar.
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/
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m3ir16ozdz.fsf@winooski.ccs.neu.edu>
Pascal Costanza <··@p-cos.net> writes:
> Eli Barzilay wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>> I seem to be missing something very important,
>>
>> I think that the best thing you should do is follow Kenny's advice and
>> use it (then look at the sources).
>>
>>
>>> so let me try to rephrase this as a question: Is there anything in
>>> Arc that can't be implemented as a plain thin library on top of
>>> (sufficiently powerful) Scheme or CL implementations?
>>
>> At least with MzScheme, it is not implemented as a library, but rather
>> as a compiler. It reads each sexpr, translates it to MzScheme code,
>> then evaluate the result.
>
> I wasn't interested in how they implemented the syntactic sugar. I was
> interested in whether it is more than syntactic sugar.
No, you weren't intersted in anything, you just claimed (falsely) that
arc is "nothing more than an extremely simple library for MzScheme".
I explained why this is false. If you choose to ignore my
explanation, then either take the time to produce better claims than
the translated BASIC story, or to demonstrate how you implement it as
"an extremely simple library".
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
>> Pascal C. writes:
>>> I seem to be missing something very important,
>>> so let me try to rephrase this as a question:
>>> Is there anything in Arc that can't be implemented as
>>> a plain thin library on top of (sufficiently powerful)
>>> Scheme or CL implementations?
> Eli wrote:
>> At least with MzScheme, it is not implemented as a library,
>> but rather as a compiler.
Pascal C. writes:
> I wasn't interested in how they implemented the syntactic sugar.
> I was interested in whether it is more than syntactic sugar.
Eli wrote:
> No, you weren't intersted in anything,
He most certainly was. He was interested in the answer to
this question:
>>> Is there anything in Arc that can't be implemented as
>>> a plain thin library on top of (sufficiently powerful)
>>> Scheme or CL implementations?
Eli wrote:
> you just claimed (falsely) that arc is "nothing more than
> an extremely simple library for MzScheme".
That post is a week old, and was replaced by the *question*
above, along with these clarifications:
>>> I seem to be missing something very important,
>>> so let me try to rephrase this as a question:
Eli wrote:
> I explained why this is false.
You explained nothing about anything except the current
implementation:
>> it is not implemented as a library
The question was not about the current implementation,
it was about the nature of the language itself.
> If you choose to ignore my explanation, then either
> take the time to produce better claims than the
> translated BASIC story, or to demonstrate how you
> implement it as "an extremely simple library".
If you choose to ignore people's questions, they may choose
to ignore your responses. Pascal invited you to specify which
features would be too complex to implement as a library, and
I would like to know that as well.
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47ac778f$0$25056$607ed4bc@cv.net>
danb wrote:
>>>Pascal C. writes:
>>>
>>>>I seem to be missing something very important,
>>>>so let me try to rephrase this as a question:
>>>>Is there anything in Arc that can't be implemented as
>>>>a plain thin library on top of (sufficiently powerful)
>>>>Scheme or CL implementations?
>
>
>>Eli wrote:
>>
>>>At least with MzScheme, it is not implemented as a library,
>>>but rather as a compiler.
>
>
> Pascal C. writes:
>
>>I wasn't interested in how they implemented the syntactic sugar.
>>I was interested in whether it is more than syntactic sugar.
>
>
> Eli wrote:
>
>>No, you weren't intersted in anything,
>
>
> He most certainly was. He was interested in the answer to
> this question:
>
>>>>Is there anything in Arc that can't be implemented as
>>>>a plain thin library on top of (sufficiently powerful)
>>>>Scheme or CL implementations?
Point of information: if I write a C++ compiler using Scheme, is C++ a
plain thin library on top of Scheme? Because up above I see "It's a
compiler, not a library" brushed aside as an implementation detail of
syntactic sugar.
So C++ is syntactic sugar (or vinegar) for Scheme when I write a
compiler for it? Is this like saying, hey, they are both Turing equivalent?
You know, we have the precedent of IF* and LOOP -- oh, but people
complain that they are not Lispy. Hmmm... why are we splitting these
hairs again?
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m3odar1kwk.fsf@winooski.ccs.neu.edu>
Ken Tilton <···········@optonline.net> writes:
> So C++ is syntactic sugar (or vinegar) for Scheme when I write a
> compiler for it? Is this like saying, hey, they are both Turing
> equivalent?
Zactly. This is why I said that you can always squint hard enough and
see C++^H^H^Harc like that. The real bogosity started with "plain
thin".
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <6144diF1t8d4bU1@mid.individual.net>
Ken Tilton wrote:
>
>
> danb wrote:
>>>> Pascal C. writes:
>>>>
>>>>> I seem to be missing something very important,
>>>>> so let me try to rephrase this as a question:
>>>>> Is there anything in Arc that can't be implemented as
>>>>> a plain thin library on top of (sufficiently powerful)
>>>>> Scheme or CL implementations?
>>
>>
>>> Eli wrote:
>>>
>>>> At least with MzScheme, it is not implemented as a library,
>>>> but rather as a compiler.
>>
>>
>> Pascal C. writes:
>>
>>> I wasn't interested in how they implemented the syntactic sugar.
>>> I was interested in whether it is more than syntactic sugar.
>>
>>
>> Eli wrote:
>>
>>> No, you weren't intersted in anything,
>>
>>
>> He most certainly was. He was interested in the answer to
>> this question:
>>
>>>>> Is there anything in Arc that can't be implemented as
>>>>> a plain thin library on top of (sufficiently powerful)
>>>>> Scheme or CL implementations?
>
> Point of information: if I write a C++ compiler using Scheme, is C++ a
> plain thin library on top of Scheme? Because up above I see "It's a
> compiler, not a library" brushed aside as an implementation detail of
> syntactic sugar.
It's true that Arc is implemented as a separate language on top of
Scheme. But that doesn't mean that it has to be that way.
For example, Cells is a library for Common Lisp - basically a set of
macros plus a runtime library where the macros expand into plain Common
Lisp forms. Now if you took Cells, added some syntactic sugar, and used
a compiler written in Common Lisp that you have to invoke separately,
but which wouldn't differ in functionality, would you then claim that
you have made a major breakthrough that brings you closer to a
hundred-year language?!?
BTW, I wouldn't have any problems with Arc if Paul Graham just said what
it is: A neat scripting language, without substantially new ideas, like
most other neat scripting languages. But he promises much more, and
doesn't seem to deliver...
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/
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m3odaquayb.fsf@winooski.ccs.neu.edu>
I'll answer in a single post. Pardon the references mess.
Pascal Costanza <··@p-cos.net> writes:
> Eli Barzilay wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>> Eli Barzilay wrote:
>>>> Pascal Costanza <··@p-cos.net> writes:
>>>>
>>>>> so let me try to rephrase this as a question: Is there anything
>>>>> in Arc that can't be implemented as a plain thin library on top
>>>>> of (sufficiently powerful) Scheme or CL implementations?
>>
>> No, you weren't intersted in anything, you just claimed (falsely) that
>> arc is "nothing more than an extremely simple library for MzScheme".
>> I explained why this is false. If you choose to ignore my
>> explanation, then either take the time to produce better claims than
>> the translated BASIC story, or to demonstrate how you implement it as
>> "an extremely simple library".
>
> I don't need to demonstrate anything.
>
> Paul Graham makes quite a few very strong claims, and they need
> stronger backing than just mere hand-waving.
>
> Here are just two citations from his articles: [...]
>
> If somebody brings out a new programming language, and claims that
> it will bring us even closer to what a programming language would
> look like 100 years from now, and even implicitly claims that it
> will be much better than anything (!) we have today, including
> existing Lisp dialects, then I expect something fundamentally
> different than a syntactically slightly different variation of R3RS
> Scheme, with some neat minor extensions on top.
This was your major gripe with arc -- and something that I never
talked about. I even said that explicitly at some point. The only
point which I claimed is false (and still do) is that you can view arc
as "a plain thin library". That's all. I swear. And this falsehood
claim is not tied in any way to being innovative -- it is perfectly
reasonable to expect libraries that are true innovations and
non-Lisp-family-languages that are truly not.
Now, if you still claim that are *can* be *implemented* as a plain
thin library, then you definitely need to have a better backup than
"this guy I know translated Basic and claimed that it was a new
language". If your only point is that arc is boring/disappointing/etc
then please don't post that as a reply to what I write, since it
cannot be a reply to something I wrote.
Pascal Costanza <··@p-cos.net> writes:
>
> I didn't want to respond to that originally, but it seems to be
> necessary: It doesn't matter whether a language has macros or
> not. Even in languages without macro systems, there is the notion of
> syntactic sugar, and people typically don't consider syntactic sugar
> as major breakthroughs.
I just left this to point out again at the fact that this has nothing
to do with what I wrote. To clarify further, whether Arc is a
breakthrough or not, is something that is pretty hard to predict, and
the tools you (or me, at least) have for this are mostly subjective
opinions -- so arguing about it, to me, is a boring waste of time.
For all I know, I may be a huge breakthrough in that in two years
everyone will use it, or it might be a complete flop that nobody will
talk about in two years, or maybe someone will find that some neat
hack in Arc corresponds to Modal Zumbarovian Logic and a whole new CS
field will spring out. You can speculate all you want, but again,
please don't do this as a reply to my post. I'm not interested. At
all.
>> (BTW, I consider naive use of CL lacking in that aspect: to
>> consider a reader macro as a "library", I'd want it to not
>> interfere with code that doesn't use that library).
>
> That's already there: compile-file binds *readtable* and *package*
> to the values they held before processing a file. So you can change
> the syntax per source file, without interfering with the syntax with
> other files. [...]
That's not enough, in a similar way that macros can mess things up.
But did I mention that I don't want to get into a CL--(PLT)Scheme
pissing contest? Oh yes, I did. Keeping this in mind, I'll have a
few brief comments on the following, keeping my zipper closed:
>> * redefine the meaning of the function application form (eg, in
>> mzscheme that's `#%app')
>
> If the CLOS MOP is available, you can get there with funcallable
> objects.
...which will make it very hard to still pretend that the result is a
library. For example, in arc lists are applicable. If you'll
implement this with CLOS objects, then you'll need to tranlsate them
to lists -- which makes it a foreign interface, which makes it not be
a plain thin library.
>> * write symbol macros, and make them access the name of the symbol (eg
>> the `foo:bar' trick)
>
> ':' cannot be redefined, but if you can live with other special
> characters in its place, that's also not problematic in CL.
Sure it can, here's a start:
(let* ((rt (copy-readtable *readtable*))
(symread (get-macro-character #\a rt)))
(defun symbol-charp (ch)
(or (eq #\: ch)
(eq symread (get-macro-character ch rt))))
(defun colon-reader (s ch)
(let ((chars (list ch)) ch2)
(loop do (setf ch2 (read-char s))
while (symbol-charp ch2)
do (push ch2 chars))
(unread-char ch2 s)
(intern (coerce (nreverse chars) 'string))))
(loop for i from 0 to 255
do (let ((ch (code-char i)))
(when (symbol-charp ch)
(set-macro-character ch #'colon-reader nil)))))
>> * extend the concrete syntax that gets used for code that uses this
>> library
>
> Relatively easy.
Just make sure it does something like the above, and that the result
can be used from plain Lisp code, as a library.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47ad2fe7$0$25040$607ed4bc@cv.net>
Eli Barzilay wrote:
> I'll answer in a single post. Pardon the references mess.
Dude, you need to read your antagonist's RtL. A pattern emerges.
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Eli Barzilay <···@barzilay.org> writes:
>>> * write symbol macros, and make them access the name of the symbol (eg
>>> the `foo:bar' trick)
>>
>> ':' cannot be redefined, but if you can live with other special
>> characters in its place, that's also not problematic in CL.
>
> Sure it can, here's a start:
>
> (let* ((rt (copy-readtable *readtable*))
> (symread (get-macro-character #\a rt)))
> (defun symbol-charp (ch)
> (or (eq #\: ch)
> (eq symread (get-macro-character ch rt))))
> (defun colon-reader (s ch)
> (let ((chars (list ch)) ch2)
> (loop do (setf ch2 (read-char s))
> while (symbol-charp ch2)
> do (push ch2 chars))
> (unread-char ch2 s)
> (intern (coerce (nreverse chars) 'string))))
> (loop for i from 0 to 255
> do (let ((ch (code-char i)))
> (when (symbol-charp ch)
> (set-macro-character ch #'colon-reader nil)))))
Better:
C/USER[10]> (let ((*readtable* (let* ((rt (copy-readtable nil)))
(defun symbol-charp (ch)
;; A better Q&D implementation, for testing.
;; Actually, you'd need to check for constituent characters,
;; and determine in colon-reader what kind of token you have.
(or (eq #\: ch)
(find ch "abcdefghijklmnopqrstuvwxyz" :test (function char-equal))))
(defun colon-reader (s ch)
(let ((chars (list ch)) ch2)
(loop do (setf ch2 (read-char s))
while (symbol-charp ch2)
do (push ch2 chars))
(unread-char ch2 s)
;; Of course, string-upcase should depend on READTABLE-CASE.
(values (intern (string-upcase (coerce (nreverse chars) 'string))))))
(loop for i from 0 to 255
do (let ((ch (code-char i)))
(when (symbol-charp ch)
(set-macro-character ch #'colon-reader nil rt))))
rt)))
(read-from-string "( abc \"string\" def:ghi ; comment
klm::opq 123 123e4 )"))
(ABC "string" |DEF:GHI| |KLM::OPQ| 123 123 E 4) ;
55
C/USER[11]>
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m3ir0ywj3d.fsf@winooski.ccs.neu.edu>
Pascal Bourguignon <···@informatimago.com> writes:
> [...]
I did both things intentionally: defer to whatever is considered a
symbol since I'm too lazy to find out, and leave it case-sensitive
since that's what arc is doing.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Eli Barzilay <···@barzilay.org> writes:
> >>> * write symbol macros, and make them access the name of the symbol (eg
> >>> the `foo:bar' trick)
> >>
> >> ':' cannot be redefined, but if you can live with other special
> >> characters in its place, that's also not problematic in CL.
> >
> > Sure it can, here's a start:
> >
> > (let* ((rt (copy-readtable *readtable*))
> > (symread (get-macro-character #\a rt)))
> > (defun symbol-charp (ch)
> > (or (eq #\: ch)
> > (eq symread (get-macro-character ch rt))))
> > (defun colon-reader (s ch)
> > (let ((chars (list ch)) ch2)
> > (loop do (setf ch2 (read-char s))
> > while (symbol-charp ch2)
> > do (push ch2 chars))
> > (unread-char ch2 s)
> > (intern (coerce (nreverse chars) 'string))))
> > (loop for i from 0 to 255
> > do (let ((ch (code-char i)))
> > (when (symbol-charp ch)
> > (set-macro-character ch #'colon-reader nil)))))
>
> Better:
>
> C/USER[10]> (let ((*readtable* (let* ((rt (copy-readtable nil)))
> (defun symbol-charp (ch)
> ;; A better Q&D implementation, for
> testing.
> ;; Actually, you'd need to check for
> constituent characters,
> ;; and determine in colon-reader what kind
> of token you have.
> (or (eq #\: ch)
> (find ch "abcdefghijklmnopqrstuvwxyz"
> :test (function char-equal))))
> (defun colon-reader (s ch)
> (let ((chars (list ch)) ch2)
> (loop do (setf ch2 (read-char s))
> while (symbol-charp ch2)
> do (push ch2 chars))
> (unread-char ch2 s)
> ;; Of course, string-upcase should
> depend on READTABLE-CASE.
> (values (intern (string-upcase (coerce
> (nreverse chars) 'string))))))
> (loop for i from 0 to 255
> do (let ((ch (code-char i)))
> (when (symbol-charp ch)
> (set-macro-character ch
> #'colon-reader nil rt))))
> rt)))
> (read-from-string "( abc \"string\" def:ghi ; comment
> klm::opq 123 123e4 )"))
> (ABC "string" |DEF:GHI| |KLM::OPQ| 123 123 E 4) ;
> 55
> C/USER[11]>
It's not so easy to get this right. In particular, this approach fails
for e.g.:
-1+:1+
which should be the identity function.
It's really not so easy to get Common Lisp to emulate Arc's infix colon
operator. You pretty much have to rewrite the entire reader to really
get it right. Colon-as-package-indicator is woven quite deeply into
CL's symbol syntax.
rg
Ron Garret <·········@flownet.com> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> Eli Barzilay <···@barzilay.org> writes:
>> >>> * write symbol macros, and make them access the name of the symbol (eg
>> >>> the `foo:bar' trick)
>> >>
>> >> ':' cannot be redefined, but if you can live with other special
>> >> characters in its place, that's also not problematic in CL.
> [...]
> It's not so easy to get this right. In particular, this approach fails
> for e.g.:
>
> -1+:1+
>
> which should be the identity function.
>
> It's really not so easy to get Common Lisp to emulate Arc's infix colon
> operator. You pretty much have to rewrite the entire reader to really
> get it right. Colon-as-package-indicator is woven quite deeply into
> CL's symbol syntax.
Of course. What Eli showed however is that you can get hold of the
colon from the reader macros, so you don't need any other hook in the
Common Lisp reader. Of course this means that you have to reimplement
the whole tokenizer, and to put reader macros on all the characters
too.
But I agree, I too prefer to write a reader from scratch rather than
setting reader macros on all the characters.
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Logiciels libres : nourris au code source sans farine animale."
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> >> Eli Barzilay <···@barzilay.org> writes:
> >> >>> * write symbol macros, and make them access the name of the symbol (eg
> >> >>> the `foo:bar' trick)
> >> >>
> >> >> ':' cannot be redefined, but if you can live with other special
> >> >> characters in its place, that's also not problematic in CL.
> > [...]
> > It's not so easy to get this right. In particular, this approach fails
> > for e.g.:
> >
> > -1+:1+
> >
> > which should be the identity function.
> >
> > It's really not so easy to get Common Lisp to emulate Arc's infix colon
> > operator. You pretty much have to rewrite the entire reader to really
> > get it right. Colon-as-package-indicator is woven quite deeply into
> > CL's symbol syntax.
>
> Of course. What Eli showed however is that you can get hold of the
> colon from the reader macros, so you don't need any other hook in the
> Common Lisp reader. Of course this means that you have to reimplement
> the whole tokenizer, and to put reader macros on all the characters
> too.
>
> But I agree, I too prefer to write a reader from scratch rather than
> setting reader macros on all the characters.
It is not at all clear that Eli's "solution" is all that much different
from writing a reader from scratch if you really want to make it work
right.
Personally, I would prefer to have a user-modifiable "token hook"
function that would post-process strings that are intended to name
symbols. (But that would require a change to the standard, so that's
not likely to happen in this century.)
rg
From: Pascal J. Bourguignon
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <7cprv2pcc8.fsf@pbourguignon.anevia.com>
Ron Garret <·········@flownet.com> writes:
> In article <··············@thalassa.informatimago.com>,
> Pascal Bourguignon <···@informatimago.com> wrote:
>
>> Ron Garret <·········@flownet.com> writes:
>>
>> > In article <··············@thalassa.informatimago.com>,
>> > Pascal Bourguignon <···@informatimago.com> wrote:
>> >
>> >> Eli Barzilay <···@barzilay.org> writes:
>> >> >>> * write symbol macros, and make them access the name of the symbol (eg
>> >> >>> the `foo:bar' trick)
>> >> >>
>> >> >> ':' cannot be redefined, but if you can live with other special
>> >> >> characters in its place, that's also not problematic in CL.
>> > [...]
>> > It's not so easy to get this right. In particular, this approach fails
>> > for e.g.:
>> >
>> > -1+:1+
>> >
>> > which should be the identity function.
>> >
>> > It's really not so easy to get Common Lisp to emulate Arc's infix colon
>> > operator. You pretty much have to rewrite the entire reader to really
>> > get it right. Colon-as-package-indicator is woven quite deeply into
>> > CL's symbol syntax.
>>
>> Of course. What Eli showed however is that you can get hold of the
>> colon from the reader macros, so you don't need any other hook in the
>> Common Lisp reader. Of course this means that you have to reimplement
>> the whole tokenizer, and to put reader macros on all the characters
>> too.
>>
>> But I agree, I too prefer to write a reader from scratch rather than
>> setting reader macros on all the characters.
>
> It is not at all clear that Eli's "solution" is all that much different
> from writing a reader from scratch if you really want to make it work
> right.
>
> Personally, I would prefer to have a user-modifiable "token hook"
> function that would post-process strings that are intended to name
> symbols. (But that would require a change to the standard, so that's
> not likely to happen in this century.)
Well it happened one year ago.
http://darcs.informatimago.com/lisp/common-lisp/reader.lisp
See (defclass readtable ...), accessor READTABLE-PARSE-TOKEN.
If you want this kind of hook to spread over more implementations, I
guess you could write a CLRFI.
--
__Pascal Bourguignon__
In article <··············@pbourguignon.anevia.com>,
···@informatimago.com (Pascal J. Bourguignon) wrote:
> Ron Garret <·········@flownet.com> writes:
>
> > In article <··············@thalassa.informatimago.com>,
> > Pascal Bourguignon <···@informatimago.com> wrote:
> >
> >> Ron Garret <·········@flownet.com> writes:
> >>
> >> > In article <··············@thalassa.informatimago.com>,
> >> > Pascal Bourguignon <···@informatimago.com> wrote:
> >> >
> >> >> Eli Barzilay <···@barzilay.org> writes:
> >> >> >>> * write symbol macros, and make them access the name of the symbol
> >> >> >>> (eg
> >> >> >>> the `foo:bar' trick)
> >> >> >>
> >> >> >> ':' cannot be redefined, but if you can live with other special
> >> >> >> characters in its place, that's also not problematic in CL.
> >> > [...]
> >> > It's not so easy to get this right. In particular, this approach fails
> >> > for e.g.:
> >> >
> >> > -1+:1+
> >> >
> >> > which should be the identity function.
> >> >
> >> > It's really not so easy to get Common Lisp to emulate Arc's infix colon
> >> > operator. You pretty much have to rewrite the entire reader to really
> >> > get it right. Colon-as-package-indicator is woven quite deeply into
> >> > CL's symbol syntax.
> >>
> >> Of course. What Eli showed however is that you can get hold of the
> >> colon from the reader macros, so you don't need any other hook in the
> >> Common Lisp reader. Of course this means that you have to reimplement
> >> the whole tokenizer, and to put reader macros on all the characters
> >> too.
> >>
> >> But I agree, I too prefer to write a reader from scratch rather than
> >> setting reader macros on all the characters.
> >
> > It is not at all clear that Eli's "solution" is all that much different
> > from writing a reader from scratch if you really want to make it work
> > right.
> >
> > Personally, I would prefer to have a user-modifiable "token hook"
> > function that would post-process strings that are intended to name
> > symbols. (But that would require a change to the standard, so that's
> > not likely to happen in this century.)
>
> Well it happened one year ago.
> http://darcs.informatimago.com/lisp/common-lisp/reader.lisp
> See (defclass readtable ...), accessor READTABLE-PARSE-TOKEN.
>
> If you want this kind of hook to spread over more implementations, I
> guess you could write a CLRFI.
Re-implementing part of the standard is not the same as changing the
standard, but your point is well taken. Thanks for the reference.
I'll give the CLRFI thing a whirl too.
Out of curiosity, what motivated you to write this thing? It seems like
a lot of work to implement something that you get for free in every CL
implementation.
rg
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <618vadF1u5i1jU1@mid.individual.net>
Eli Barzilay wrote:
>>> Pascal Costanza <··@p-cos.net> writes:
>>
>> Here are just two citations from his articles: [...]
>>
>> If somebody brings out a new programming language, and claims that
>> it will bring us even closer to what a programming language would
>> look like 100 years from now, and even implicitly claims that it
>> will be much better than anything (!) we have today, including
>> existing Lisp dialects, then I expect something fundamentally
>> different than a syntactically slightly different variation of R3RS
>> Scheme, with some neat minor extensions on top.
>
> This was your major gripe with arc -- and something that I never
> talked about. I even said that explicitly at some point. The only
> point which I claimed is false (and still do) is that you can view arc
> as "a plain thin library". That's all. I swear. And this falsehood
> claim is not tied in any way to being innovative -- it is perfectly
> reasonable to expect libraries that are true innovations and
> non-Lisp-family-languages that are truly not.
OK, fine by me.
> Now, if you still claim that are *can* be *implemented* as a plain
> thin library, then you definitely need to have a better backup than
> "this guy I know translated Basic and claimed that it was a new
> language".
This was clearly meant as tongue-in-cheek analogy. My hope was that this
would be obvious: You don't even need macros for the kind of translation
that guy did.
> If your only point is that arc is boring/disappointing/etc
> then please don't post that as a reply to what I write, since it
> cannot be a reply to something I wrote.
It's related. Even if you cannot get 100% of the design of Arc with any
of the existing Lisp dialects, but only 99% or 98%, I would still stick
to my claim. It cannot possibly be that such nuances make a difference
in a hundred-year perspective.
>>> (BTW, I consider naive use of CL lacking in that aspect: to
>>> consider a reader macro as a "library", I'd want it to not
>>> interfere with code that doesn't use that library).
>> That's already there: compile-file binds *readtable* and *package*
>> to the values they held before processing a file. So you can change
>> the syntax per source file, without interfering with the syntax with
>> other files. [...]
>
> That's not enough, in a similar way that macros can mess things up.
> But did I mention that I don't want to get into a CL--(PLT)Scheme
> pissing contest? Oh yes, I did.
Sorry, I'm lost. I didn't mean this as a CL-vs.-Scheme pissing contest
either. Either I am allowed to talk about technical aspects, or I'm not.
It can't be both. Please make up your mind.
For the records, if you can't implement Arc as a plain library in CL,
but only in some Scheme implementation, this would still support my
position.
> Keeping this in mind, I'll have a
> few brief comments on the following, keeping my zipper closed:
>
>>> * redefine the meaning of the function application form (eg, in
>>> mzscheme that's `#%app')
>> If the CLOS MOP is available, you can get there with funcallable
>> objects.
>
> ...which will make it very hard to still pretend that the result is a
> library. For example, in arc lists are applicable. If you'll
> implement this with CLOS objects, then you'll need to tranlsate them
> to lists -- which makes it a foreign interface, which makes it not be
> a plain thin library.
Since when is it a requirement that a library seamlessly interacts with
everything else in a language?
If you insist on that, well yes, I think that can work as well.
>>> * write symbol macros, and make them access the name of the symbol (eg
>>> the `foo:bar' trick)
>> ':' cannot be redefined, but if you can live with other special
>> characters in its place, that's also not problematic in CL.
>
> Sure it can
[...]
Even better.
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/
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m33as0609l.fsf@winooski.ccs.neu.edu>
Pascal Costanza <··@p-cos.net> writes:
>>> That's already there: compile-file binds *readtable* and *package*
>>> to the values they held before processing a file. So you can change
>>> the syntax per source file, without interfering with the syntax with
>>> other files. [...]
>>
>> That's not enough, in a similar way that macros can mess things up.
>> But did I mention that I don't want to get into a CL--(PLT)Scheme
>> pissing contest? Oh yes, I did.
>
> Sorry, I'm lost. I didn't mean this as a CL-vs.-Scheme pissing
> contest either. Either I am allowed to talk about technical aspects,
> or I'm not. It can't be both. Please make up your mind.
>
> For the records, if you can't implement Arc as a plain library in
> CL, but only in some Scheme implementation, this would still support
> my position.
(At the technical level, you'll need to have reader macros that allow
colons in symbols, and use square brackets for the function shorthad
thing, and you'll need that enabled at runtime inside arc code only.
(The arc implementation is intended to be used dynamically, I think.))
>> ...which will make it very hard to still pretend that the result is
>> a library. For example, in arc lists are applicable. If you'll
>> implement this with CLOS objects, then you'll need to tranlsate
>> them to lists -- which makes it a foreign interface, which makes it
>> not be a plain thin library.
>
> Since when is it a requirement that a library seamlessly interacts
> with everything else in a language?
I take that as a fundamental requirement from something that is "a
library". If you drop that, then you can probably also view C++ as a
library, as mentioned earlier.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <619iriF1u4o06U2@mid.individual.net>
Eli Barzilay wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>>> That's already there: compile-file binds *readtable* and *package*
>>>> to the values they held before processing a file. So you can change
>>>> the syntax per source file, without interfering with the syntax with
>>>> other files. [...]
>>> That's not enough, in a similar way that macros can mess things up.
>>> But did I mention that I don't want to get into a CL--(PLT)Scheme
>>> pissing contest? Oh yes, I did.
>> Sorry, I'm lost. I didn't mean this as a CL-vs.-Scheme pissing
>> contest either. Either I am allowed to talk about technical aspects,
>> or I'm not. It can't be both. Please make up your mind.
>>
>> For the records, if you can't implement Arc as a plain library in
>> CL, but only in some Scheme implementation, this would still support
>> my position.
>
> (At the technical level, you'll need to have reader macros that allow
> colons in symbols, and use square brackets for the function shorthad
> thing, and you'll need that enabled at runtime inside arc code only.
> (The arc implementation is intended to be used dynamically, I think.))
Why would that affect the parsing process. Parsing is always "static".
>>> ...which will make it very hard to still pretend that the result is
>>> a library. For example, in arc lists are applicable. If you'll
>>> implement this with CLOS objects, then you'll need to tranlsate
>>> them to lists -- which makes it a foreign interface, which makes it
>>> not be a plain thin library.
>> Since when is it a requirement that a library seamlessly interacts
>> with everything else in a language?
>
> I take that as a fundamental requirement from something that is "a
> library". If you drop that, then you can probably also view C++ as a
> library, as mentioned earlier.
Huh?
I have a math library. For example it supports addition of numbers.
However, if I call (+ '(foo bar) "blubb"), I get an error.
So is the math library a new language, because it doesn't know how to
add lists to strings?!?
Of course, you cannot possibly mean that. So what do you mean?
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/
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m3prv4i9w5.fsf@winooski.ccs.neu.edu>
Pascal Costanza <··@p-cos.net> writes:
> Eli Barzilay wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>>>> That's already there: compile-file binds *readtable* and *package*
>>>>> to the values they held before processing a file. So you can change
>>>>> the syntax per source file, without interfering with the syntax with
>>>>> other files. [...]
>>>> That's not enough, in a similar way that macros can mess things up.
>>>> But did I mention that I don't want to get into a CL--(PLT)Scheme
>>>> pissing contest? Oh yes, I did.
>>> Sorry, I'm lost. I didn't mean this as a CL-vs.-Scheme pissing
>>> contest either. Either I am allowed to talk about technical aspects,
>>> or I'm not. It can't be both. Please make up your mind.
>>>
>>> For the records, if you can't implement Arc as a plain library in
>>> CL, but only in some Scheme implementation, this would still support
>>> my position.
>>
>> (At the technical level, you'll need to have reader macros that allow
>> colons in symbols, and use square brackets for the function shorthad
>> thing, and you'll need that enabled at runtime inside arc code only.
>> (The arc implementation is intended to be used dynamically, I think.))
>
> Why would that affect the parsing process. Parsing is always "static".
Evaluating forms at run-time (for example, a repl) is supposed to be
an integral part of the language.
>>>> ...which will make it very hard to still pretend that the result is
>>>> a library. For example, in arc lists are applicable. If you'll
>>>> implement this with CLOS objects, then you'll need to tranlsate
>>>> them to lists -- which makes it a foreign interface, which makes it
>>>> not be a plain thin library.
>>> Since when is it a requirement that a library seamlessly interacts
>>> with everything else in a language?
>>
>> I take that as a fundamental requirement from something that is "a
>> library". If you drop that, then you can probably also view C++ as a
>> library, as mentioned earlier.
>
> Huh?
>
> I have a math library. For example it supports addition of
> numbers. However, if I call (+ '(foo bar) "blubb"), I get an error.
>
> So is the math library a new language, because it doesn't know how to
> add lists to strings?!?
>
> Of course, you cannot possibly mean that. So what do you mean?
Yes, a library can define a new type and operations on that type. Arc
goes beyond that to having a different syntax and semantics.
(As a meta comment, the reason I went into this thread is the claim
that arc can be implemented as a plain thin library. Since you
clarified that this was not a serious claim I'll go away now.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <61ahheF1teal7U1@mid.individual.net>
Eli Barzilay wrote:
>>> (At the technical level, you'll need to have reader macros that allow
>>> colons in symbols, and use square brackets for the function shorthad
>>> thing, and you'll need that enabled at runtime inside arc code only.
>>> (The arc implementation is intended to be used dynamically, I think.))
>> Why would that affect the parsing process. Parsing is always "static".
>
> Evaluating forms at run-time (for example, a repl) is supposed to be
> an integral part of the language.
So?
>>>>> ...which will make it very hard to still pretend that the result is
>>>>> a library. For example, in arc lists are applicable. If you'll
>>>>> implement this with CLOS objects, then you'll need to tranlsate
>>>>> them to lists -- which makes it a foreign interface, which makes it
>>>>> not be a plain thin library.
>>>> Since when is it a requirement that a library seamlessly interacts
>>>> with everything else in a language?
>>> I take that as a fundamental requirement from something that is "a
>>> library". If you drop that, then you can probably also view C++ as a
>>> library, as mentioned earlier.
>> Huh?
>>
>> I have a math library. For example it supports addition of
>> numbers. However, if I call (+ '(foo bar) "blubb"), I get an error.
>>
>> So is the math library a new language, because it doesn't know how to
>> add lists to strings?!?
>>
>> Of course, you cannot possibly mean that. So what do you mean?
>
> Yes, a library can define a new type and operations on that type. Arc
> goes beyond that to having a different syntax and semantics.
That's one of the nice features of Lisp that you can define syntax and
their semantics as libraries, as long as they can be expressed in terms
of locally expanded macros (and reader macros).
> (As a meta comment, the reason I went into this thread is the claim
> that arc can be implemented as a plain thin library. Since you
> clarified that this was not a serious claim I'll go away now.)
It was a serious claim.
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/
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m3zlu77t4e.fsf@winooski.ccs.neu.edu>
Pascal Costanza <··@p-cos.net> writes:
>> (As a meta comment, the reason I went into this thread is the claim
>> that arc can be implemented as a plain thin library. Since you
>> clarified that this was not a serious claim I'll go away now.)
>
> It was a serious claim.
This is seriously annoying. I'll be waiting for your code.
Now imagine a "#0=" at the beginning of my first post.
#0#
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <61amo3F1ug233U1@mid.individual.net>
Eli Barzilay wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>>> (As a meta comment, the reason I went into this thread is the claim
>>> that arc can be implemented as a plain thin library. Since you
>>> clarified that this was not a serious claim I'll go away now.)
>> It was a serious claim.
>
> This is seriously annoying.
Yes. Let's leave it at that.
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/
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m3sl031l2t.fsf@winooski.ccs.neu.edu>
danb <·········@gmail.com> writes:
>>> Pascal C. writes:
>>>> I seem to be missing something very important, so let me try to
>>>> rephrase this as a question: Is there anything in Arc that can't
>>>> be implemented as a plain thin library on top of (sufficiently
>>>> powerful) Scheme or CL implementations?
>
>> Eli wrote:
>>> At least with MzScheme, it is not implemented as a library,
>>> but rather as a compiler.
Please refer to the original post where I wrote this sentence. You'll
see that I didn't just ended the non-argument with that -- I listed a
bunch of features that arc uses that make considering arc as "a plain
thin library" wrong.
> Pascal C. writes:
>> I wasn't interested in how they implemented the syntactic sugar.
>> I was interested in whether it is more than syntactic sugar.
>
> Eli wrote:
>> No, you weren't intersted in anything,
>
> He most certainly was.
Pascal chose to ignore all that in his reply (which, I guess, is why
you omitted it too). So he asked a technical question, I answered
with technical details, which he completely ignored. To me, this is a
clear signal that he was not interested in the reply. The fact that
he repeated the question to which I had a detailed posted reply
further led me to believe that he was not interested in any answer.
If this conclusion is wrong, I'll be happy to clarify my original
post, when it is questioned.
> [...snip irrelevant flaming...]
>
> The question was not about the current implementation, it was about
> the nature of the language itself.
The "nature" of the language is irrelevant -- the question was whether
it can be *implemented* as "a plain thin library". But having me
point out the problems and have an abstract discussion about that is
not going to be fruitful. So here's an alternative: if it is possible
to implement arc that way (plain+thin) then just go ahead and do it --
it's reasonable to assume that plain+thin means that it won't take
long. Make sure that the result is a *library* though -- that you can
freely use arc code from mzscheme and mzscheme code from arc, just
like with any other mzscheme library (eg, (require "foo.arc") in
mzscheme and just use whatever it defines, or exposing mzscheme
functions to arc an use them). (You'll need to do this without a
foreign interface to translate back and forth.)
> [...] Pascal invited you to specify which features would be too
> complex to implement as a library, and I would like to know that as
> well.
Then please refer to that post. I'll make it easier by copying that
text:
* tweak your namespace directly
* redefine the meaning of the function application form (eg, in
mzscheme that's `#%app')
* write symbol macros, and make them access the name of the symbol (eg
the `foo:bar' trick)
* add new special forms (= macros), including ones that are already
part of your core language like `if'
* extend the concrete syntax that gets used for code that uses this
library
One additional point in the context of mzscheme: mzscheme has separate
phases for syntax expansion and runtime. This is a very intentional
restriction that makes it possible to make compilation saner. (Not
having such separation is one of the major reasons why dealing with
macros in CL can become so difficult, especially with large systems.)
As I posted in a different reply just now, Arc does not have that
separation, which immediately rules out using arc macros from
mzscheme. But the original question was "on top of [...] Scheme or
CL implementations?", so feel free to implement your arc library on
top of a different CL/Scheme if you think that it will help.
I'm looking forward to see your code.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
Pascal C. writes:
> Is there anything in Arc that can't be implemented as
> a plain thin library on top of (sufficiently powerful)
> Scheme or CL implementations?
Eli wrote:
> At least with MzScheme, it is not implemented as a library,
> but rather as a compiler.
Eli wrote:
> Please refer to the original post where I wrote this sentence.
You probably mean this:
> Arc doesn't share many features of mzscheme, for example: the
> module system, function applications, hygienic macros or any other
> kind of macros (eg, Arc does not have mzscheme's phase separation).
> It doesn't even share mzscheme's namespaces -- in fact, if you look at
> the arc compiler, you'll see that it's lisp-1-ness is not inherited
> from mzscheme, and making it a lisp-2 would be a simple tweak. It
> might not be as far from mzscheme as mzscheme is from C, but to
> compare it to a translated-basic interpreter is ridiculous.
Eli wrote:
> You'll see that I didn't just ended the non-argument with that --
> I listed a bunch of features that arc uses that make considering
> arc as "a plain thin library" wrong. Pascal chose to ignore all that
> in his reply (which, I guess, is why you omitted it too).
Fair enough, except no, I wasn't intentionally ignoring it.
> So he asked a technical question, I answered with technical
> details, which he completely ignored. To me, this is a clear
> signal that he was not interested in the reply.
So you were both ignoring each other. Please feel free to chastise
Pascal when he does that, instead of just fanning the flames.
> danb <·········@gmail.com> writes:
> > The question was not about the current implementation,
> > it was about the nature of the language itself.
Eli wrote:
> The "nature" of the language is irrelevant -- the question was
> whether it can be *implemented* as "a plain thin library".
No, Eli. The question was whether it ***CAN*** be implemented as
a (simple) library. That's a property of the language itself, or
at least a relationship between the source and target languages.
Dan wrote:
> > [...] Pascal invited you to specify which features would be too
> > complex to implement as a library
Eli wrote:
> * tweak your namespace directly
> * redefine the meaning of the function application form (eg, in
> mzscheme that's `#%app')
> * write symbol macros, and make them access the name of the symbol
> (eg the `foo:bar' trick)
> * add new special forms (= macros), including ones that are already
> part of your core language like `if'
> * extend the concrete syntax that gets used for code that uses
> this library
Excellent. That's way better than a flame war. I hope Pascal
responds
constructively.
--Dan
www.prairienet.org/~dsb/
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m363wzqnrp.fsf@winooski.ccs.neu.edu>
danb <·········@gmail.com> writes:
> Pascal C. writes:
>> Is there anything in Arc that can't be implemented as
>> a plain thin library on top of (sufficiently powerful)
>> Scheme or CL implementations?
>
> Eli wrote:
>> At least with MzScheme, it is not implemented as a library,
>> but rather as a compiler.
>
> Eli wrote:
>> Please refer to the original post where I wrote this sentence.
>
> You probably mean this:
>> Arc doesn't share many features of mzscheme, for example: the
>> module system, function applications, hygienic macros or any other
>> kind of macros (eg, Arc does not have mzscheme's phase separation).
>> It doesn't even share mzscheme's namespaces -- in fact, if you look at
>> the arc compiler, you'll see that it's lisp-1-ness is not inherited
>> from mzscheme, and making it a lisp-2 would be a simple tweak. It
>> might not be as far from mzscheme as mzscheme is from C, but to
>> compare it to a translated-basic interpreter is ridiculous.
>
> Eli wrote:
>> You'll see that I didn't just ended the non-argument with that --
>> I listed a bunch of features that arc uses that make considering
>> arc as "a plain thin library" wrong. Pascal chose to ignore all that
>> in his reply (which, I guess, is why you omitted it too).
>
> Fair enough, except no, I wasn't intentionally ignoring it.
(Yes, that was my guess.)
>> So he asked a technical question, I answered with technical
>> details, which he completely ignored. To me, this is a clear
>> signal that he was not interested in the reply.
>
> So you were both ignoring each other. Please feel free to chastise
> Pascal when he does that, instead of just fanning the flames.
(a) I don't see what I ignored; (b) no fanning intended, I apologize
if I did.
>> danb <·········@gmail.com> writes:
>> > The question was not about the current implementation,
>> > it was about the nature of the language itself.
>
> Eli wrote:
>> The "nature" of the language is irrelevant -- the question was
>> whether it can be *implemented* as "a plain thin library".
>
> No, Eli. The question was whether it ***CAN*** be implemented as
> a (simple) library.
Exactly.
> That's a property of the language itself, or at least a relationship
> between the source and target languages.
(Well, *that's* much clearer than "the nature of the language", and I
completely agree.)
> Dan wrote:
>> > [...] Pascal invited you to specify which features would be too
>> > complex to implement as a library
>
> Eli wrote:
>> * tweak your namespace directly
>> * redefine the meaning of the function application form (eg, in
>> mzscheme that's `#%app')
>> * write symbol macros, and make them access the name of the symbol
>> (eg the `foo:bar' trick)
>> * add new special forms (= macros), including ones that are already
>> part of your core language like `if'
>> * extend the concrete syntax that gets used for code that uses
>> this library
>
> Excellent. That's way better than a flame war. I hope Pascal
> responds constructively.
(The best answer would take the form of some code.)
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Andrew Reilly
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <612u7kF1svdsjU3@mid.individual.net>
On Sun, 03 Feb 2008 10:03:52 -0500, Eli Barzilay wrote:
> No, you weren't intersted in anything, you just claimed (falsely) that
> arc is "nothing more than an extremely simple library for MzScheme". I
> explained why this is false. If you choose to ignore my explanation,
> then either take the time to produce better claims than the translated
> BASIC story, or to demonstrate how you implement it as "an extremely
> simple library".
(Mz)Scheme libraries include macros, and macros translate forms into
other forms: where's the catch/disconnect? Maybe not simple, but I'm
betting that someone will have translated the arc compiler into an
MzScheme #lang inside of a month. Then you'll get to mix arc modules
with existing mzscheme libraries and code (presumably). Maybe you can do
that with arc already, though? [Yes, I'm bad. I haven't had time to
play with arc myself, yet.]
Cheers,
--
Andrew
From: Eli Barzilay
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m3tzkj1l2x.fsf@winooski.ccs.neu.edu>
Andrew Reilly <···············@areilly.bpc-users.org> writes:
> On Sun, 03 Feb 2008 10:03:52 -0500, Eli Barzilay wrote:
>
>> No, you weren't intersted in anything, you just claimed (falsely)
>> that arc is "nothing more than an extremely simple library for
>> MzScheme". I explained why this is false. If you choose to ignore
>> my explanation, then either take the time to produce better claims
>> than the translated BASIC story, or to demonstrate how you
>> implement it as "an extremely simple library".
>
> (Mz)Scheme libraries include macros, and macros translate forms into
> other forms: where's the catch/disconnect? Maybe not simple, but
> I'm betting that someone will have translated the arc compiler into
> an MzScheme #lang inside of a month. Then you'll get to mix arc
> modules with existing mzscheme libraries and code (presumably).
> Maybe you can do that with arc already, though? [Yes, I'm bad. I
> haven't had time to play with arc myself, yet.]
* If you want #lang in PLT v4, then you'll also need a "foreign
interface" to translate immutable lists on the mzscheme side and
mutable ones on the arc side.
* Like I said, to implement arc as a library you'll need several
things that do not fit the usual definition of a "library". For a
#lang module, making it talk to mzscheme will have to go through an
indirect layer (again) of interaction because arc doesn't use the
mzscheme module system -- just one flat namespace. So this is also
doable, but not a "library" in the usual sense.
* There some other issues like the reader extension that you'll need
to deal with.
* The fact that you can still shove the above into a #lang but not
consider the result a library shouldn't be surprising, because
mzscheme's module and syntax system are powerful enough to implement
not only modules that are used as libraries, but modules that are
used as languages. The latter ones tend to have a much stronger
effect on the resulting language -- and it is a language. (For
example, the main swindle module can be used as a language for other
modules, but not as a library in plain mzscheme code.)
* Finally, note that arc's macros do not have phase separation:
arc> (= x 1)
1
arc> (mac foo () x)
#3(tagged mac #<procedure>)
arc> (foo)
1
arc> (= x 2)
2
arc> (foo)
2
This is implemented by using `eval' directly (in that single arc
namespace), and it makes the resulting language diverge
significantly from mzscheme. You could implement the #lang version
using the same eval trick, but the result will be farther away from
mzscheme, which means that you will not be able to use it as a
library.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <6143ufF1tq1b7U1@mid.individual.net>
Eli Barzilay wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> Eli Barzilay wrote:
>>> Pascal Costanza <··@p-cos.net> writes:
>>>
>>>> I seem to be missing something very important,
>>> I think that the best thing you should do is follow Kenny's advice and
>>> use it (then look at the sources).
>>>
>>>
>>>> so let me try to rephrase this as a question: Is there anything in
>>>> Arc that can't be implemented as a plain thin library on top of
>>>> (sufficiently powerful) Scheme or CL implementations?
>>> At least with MzScheme, it is not implemented as a library, but rather
>>> as a compiler. It reads each sexpr, translates it to MzScheme code,
>>> then evaluate the result.
>> I wasn't interested in how they implemented the syntactic sugar. I was
>> interested in whether it is more than syntactic sugar.
>
> No, you weren't intersted in anything, you just claimed (falsely) that
> arc is "nothing more than an extremely simple library for MzScheme".
> I explained why this is false. If you choose to ignore my
> explanation, then either take the time to produce better claims than
> the translated BASIC story, or to demonstrate how you implement it as
> "an extremely simple library".
I don't need to demonstrate anything.
Paul Graham makes quite a few very strong claims, and they need stronger
backing than just mere hand-waving.
Here are just two citations from his articles:
"[John McCarthy's Lisp] passed into the hands of his grad students, who
at the time were more worried about the exigencies of making an
interpreter run on the IBM 704 than continuing McCarthy's axiomatic
approach. We've been living with their hacks ever since. Steele and
Sussman tried to start over when they first began working on Scheme, but
they seem to have been practically the only ones."
- http://paulgraham.com/arcchallenge.html
"Now we have two ideas that, if you combine them, suggest interesting
possibilities: (1) the hundred-year language could, in principle, be
designed today, and (2) such a language, if it existed, might be good to
program in today. When you see these ideas laid out like that, it's hard
not to think, why not try writing the hundred-year language now?"
- http://paulgraham.com/hundred.html
Now, Scheme has been a major breakthrough, in the Lisp arena and beyond:
It got lexical scoping right, it established the idea of being able to
introduce local functions, it established some good arguments to retain
dynamic scoping nonetheless, and it supported a first-class
representation of the control flow of a program. These things were
possible to different degrees in previous Lisp dialects, but it was
impossible to get them right within their frameworks in the same way
that a completely new implementation of Scheme did, and especially not
by mere syntactic tweaks. In terms of making progress towards getting
language constructs "right" and bringing us closer to creating the
"right" language that will pass the test of time, this was an important
milestone. [1]
If somebody brings out a new programming language, and claims that it
will bring us even closer to what a programming language would look like
100 years from now, and even implicitly claims that it will be much
better than anything (!) we have today, including existing Lisp
dialects, then I expect something fundamentally different than a
syntactically slightly different variation of R3RS Scheme, with some
neat minor extensions on top.
Pascal
[1] And, no, Steele and Sussman weren't the only ones. Smith and des
Rivieres made similar breakthroughs, for example, which still exist in
various forms. There were probably more.
--
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/
On Sun, 03 Feb 2008 15:51:59 +0100, Pascal Costanza wrote:
> Eli Barzilay wrote:
>> Pascal Costanza <··@p-cos.net> writes:
>>
>>> I seem to be missing something very important,
>>
>> I think that the best thing you should do is follow Kenny's advice and
>> use it (then look at the sources).
>>
>>
>>> so let me try to rephrase this as a question: Is there anything in Arc
>>> that can't be implemented as a plain thin library on top of
>>> (sufficiently powerful) Scheme or CL implementations?
>>
>> At least with MzScheme, it is not implemented as a library, but rather
>> as a compiler. It reads each sexpr, translates it to MzScheme code,
>> then evaluate the result.
>
> I wasn't interested in how they implemented the syntactic sugar. I was
> interested in whether it is more than syntactic sugar.
Arc has a couple of neat ideas (the building of the language from
'axioms' and funcallable containers), and the type system and building
the language/library up using set+annotate is kind of fun (arc.arc). My
personal preferences aside, it's a capable lisp, it's fun to use, but
there's nothing innovative or earth-shattering.
As an aside, i've never really been a fan of pg's style, but this is just
horrible imo:
(define (ac-mac-call m args env)
(let ((x1 (apply m (map ac-niltree args))))
(let ((x2 (ac (ac-denil x1) env)))
x2)))
That's the code to call a macro-function and compile the expansion. For
someone who goes on about brevity this and concise that .. WTF! Drop
those lets!
(define (ac-mac-call m args env)
(ac (ac-denil (apply m (map ac-niltree args)) env))
Cheers,
drewc
>
>
> Pascal
--
Posted via a free Usenet account from http://www.teranews.com
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <6142hhF1spa2uU1@mid.individual.net>
Eli Barzilay wrote:
> Pascal Costanza <··@p-cos.net> writes:
>
>> I seem to be missing something very important,
>
> I think that the best thing you should do is follow Kenny's advice and
> use it (then look at the sources).
>
>> so let me try to rephrase this as a question: Is there anything in
>> Arc that can't be implemented as a plain thin library on top of
>> (sufficiently powerful) Scheme or CL implementations?
>
> At least with MzScheme, it is not implemented as a library, but rather
> as a compiler. It reads each sexpr, translates it to MzScheme code,
> then evaluate the result. You could probably argue that it can be
> viewed as a library -- given a powerful enough language. For example,
> when you write a macro in Scheme/CL you say that it's part of a
> language -- but in (most) other languages that will be wrong since you
> cannot extend the language in that way; when you add a new
> concrete-level syntax through a reader macro you can claim that this
> is a library in a very few number of languages
I didn't want to respond to that originally, but it seems to be
necessary: It doesn't matter whether a language has macros or not. Even
in languages without macro systems, there is the notion of syntactic
sugar, and people typically don't consider syntactic sugar as major
breakthroughs.
I specifically mentioned Java's foreach statement as an example of a
language extension that is more interesting than Arc. This is a good
example because Schemers and Lispers typically make fun of such
"innovations." However, Java's foreach requires a protocal that is
followed in several parts of the language and Java's collection
framework. In other words, it's not a purely local syntactic program
transformation.
I don't see anything like that in Arc, and nobody has been able to point
out anything like that in Arc yet.
> (BTW, I consider naive
> use of CL lacking in that aspect: to consider a reader macro as a
> "library", I'd want it to not interfere with code that doesn't use
> that library).
That's already there: compile-file binds *readtable* and *package* to
the values they held before processing a file. So you can change the
syntax per source file, without interfering with the syntax with other
files. That's rudimentary, but works. (IIRC, Tobias Rittweiler is
working on a more complete framework to better handle syntax tweaks - in
portable Common Lisp!)
> So, a few of the features that you'll need to implement arc as a
> library are:
>
> * tweak your namespace directly
I don't know exactly what you mean by this. Creating a Lisp-1 in Common
Lisp is relatively straightforward, especially when it only needs to be
enforced in your own binding constructs.
> * redefine the meaning of the function application form (eg, in
> mzscheme that's `#%app')
If the CLOS MOP is available, you can get there with funcallable objects.
> * write symbol macros, and make them access the name of the symbol (eg
> the `foo:bar' trick)
':' cannot be redefined, but if you can live with other special
characters in its place, that's also not problematic in CL.
> * add new special forms (= macros), including ones that are already
> part of your core language like `if'
Straightforward.
> * extend the concrete syntax that gets used for code that uses this
> library
Relatively easy.
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/
> I didn't want to respond to that originally, but it seems to be
> necessary: It doesn't matter whether a language has macros or not. Even
> in languages without macro systems, there is the notion of syntactic
> sugar, and people typically don't consider syntactic sugar as major
> breakthroughs.
It'd be silly to consider syntactic sugar a major breakthrough, but
that doesn't mean noone appreciates it.
> I specifically mentioned Java's foreach statement as an example of a
> language extension that is more interesting than Arc. This is a good
> example because Schemers and Lispers typically make fun of such
> "innovations." However, Java's foreach requires a protocal that is
> followed in several parts of the language and Java's collection
> framework. In other words, it's not a purely local syntactic program
> transformation.
>
> I don't see anything like that in Arc, and nobody has been able to point
> out anything like that in Arc yet.
Oddly, the number one thing about Arc that you dislike about it seems
to be that it isn't innovated by your definition of innovative. Why
does it have to be innovative? Common Lisp wasn't innovative. If I'm
not mistaken Common Lisp was just a mash-up of many other lisps. While
some things may have been added which weren't originally there,
nothing was a spectacular change which couldn't have been easily
implemented as a "plain thin library" on top of some other lisp.
Honestly, Pascal, Arc's biggest draw isn't what's different from
scheme or common lisp, it's how it combines the best of both languages
(at least I think it does). I'm sure you'll disagree on some points,
like it's lisp-1-ness and various other choices it made, but the idea
was to combine the two languages. Like how Common Lisp was meant to
combine the lisps which were available when it was made. I know you
disagree with a lot about Arc, but to me it's Common Lisp 2, because
it was designed with the same idea in mind as CL was (despite what pg
may say).
Now, you never said you think CL is the hundred year language, so this
doesn't really prove anything; but what leads you to believe that the
next 100 year language must necessarily be innovative?
Consider some of the most popular programming languages right now:
Java, C, C++. Were they innovative? No, not really.
> BTW, I wouldn't have any problems with Arc if Paul Graham just said what
> it is: A neat scripting language, without substantially new ideas, like
> most other neat scripting languages. But he promises much more, and
> doesn't seem to deliver...
Please ignore everything PG says about Arc. Arc is the programming
language; Arc is what we are discussing here, not our personal
feelings toward Mr. Graham, or what kind of ceremony it was released
with. If you have no problems with Arc, why complain about it so
avidly? What Arc is, is a fun programming language to use. It's not
really USEFUL at the moment, but it has promise for the future.
From: Kent M Pitman
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <utzkiwl5r.fsf@nhplace.com>
···········@gmail.com writes:
> Common Lisp wasn't innovative.
In CLTL1, just the core notion that you could make a single dialect
that ported across many different hardware types, and where the
implementation did the same thing compiled as well as interpreted, was
enormously innovative. And CLTL borrowed ideas from Scheme in terms
of lexical scoping that had not previously been used in the MACLISP
family and were highly controversial in that world. The CL package
system built on the ideas of other package systems (MACLISP didn't
have packages, btw, it had obarrays; the LispM had packages, but they
were structured quite differently). Common Lisp notion of exported
symbols which hadn't been tried before. The array type system and the
whole notion of upgraded array element types were innovations. I'm
sure if I thought for a while I could come up with more. There was a
LOT of stuff that was brand new in CL, and not easily accessible in
other dialects.
Again with ANSI, the amount of innovative design it did was pushing
the limit of what was reasonable for a standards group. There were
four major areas of redesign of the language embodied in that
standard: CLOS was quite innovative, for example. It was similar to
New Flavors, but it merged ideas from Common Loops. The condition
system was new. It borrowed from the LispM's New Error System, but it
changed that design in some substantive ways. The LOOP iteration
facility was a new version of an old design, seeking to repair most of
the things people had hated about LOOP. The pretty printer used new
ideas and techniques not present in previous implementations. And
there was a fifth major area that was backed out of, the fleshing out
of the environment access stuff, because the degree of recent
innovation meant it wasn't yet stable. [This facility is reflected,
in partial form, in CLTL2.]
> If I'm
> not mistaken Common Lisp was just a mash-up of many other lisps.
Well, that pretty much means all of the music industry is not
innovative. Once you start saying that to borrow from good ideas and
reassemble them in other ways is to do nothing, you've pretty much
defined everything as uninteresting.
I don't think there is a fair definition of "innovative" that will
work at all with broad brush terms like this.
> While some things may have been added which weren't originally
> there, nothing was a spectacular change which couldn't have been
> easily implemented as a "plain thin library" on top of some other
> lisp.
You must not have used other Lisps at the time. The whole point of the
time before CL was that there was not any ability to make any kind of
plain, thin library. If there were, I think DARPA would have just used
them as-is.
To take an example, certainly by no stretch of the imagination could
you layer lexical scoping in as a "thin library" over MACLISP's
dynamic scoping.
Neither could you achieve consistent interpreter/compiler semantics
as an add-on library.
> Honestly, Pascal, Arc's biggest draw isn't what's different from
> scheme or common lisp, it's how it combines the best of both languages
> (at least I think it does).
I haven't looked at Arc recently so I have no position on whether it
does or does not combine the best of both languages. I will say, though,
that I'd rather read about what people like about it than read about how
people answer claims of "don't like" with pot shots at CL.
This is not, I hope, defensiveness on my part. I was part of the CL
process, so it could seem that way. But I think it's just an objective
truth that CL had a number of new things... to the extent anything ever
does. We all stand on the shoulders of giants, and all that...
> Now, you never said you think CL is the hundred year language, so this
> doesn't really prove anything; but what leads you to believe that the
> next 100 year language must necessarily be innovative?
(I'll be pleased if there's programming at all in 100 years. Or 50.
Global warming is really worrying me.)
> Please ignore everything PG says about Arc. Arc is the programming
> language; Arc is what we are discussing here, not our personal
> feelings toward Mr. Graham, or what kind of ceremony it was released
> with. If you have no problems with Arc, why complain about it so
> avidly? What Arc is, is a fun programming language to use. It's not
> really USEFUL at the moment, but it has promise for the future.
I'll hold judgment on the language until I've seen it. I mostly
concur with the notion that the language needn't be judged by judging
its creator.
Although, on the other hand, there is some reason to think PG's
personality does matter if he's the one who decides what it will be next.
See:
http://www.nhplace.com/kent/PS/Lambda.html#thought_experiment
In the history of languages, it has mattered which were controlled by whom.
So it only matters about PG if PG controls it, not because he made it.
I don't happen to know what the politics are for evolving Arc--maybe someone
who does will chime in here.
From: Lars Brinkhoff
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <85y79q36mh.fsf@junk.nocrew.org>
Kent M Pitman <······@nhplace.com> writes:
> Again with ANSI, the amount of innovative design it did was pushing
> the limit of what was reasonable for a standards group. [...] The
> LOOP iteration facility was a new version of an old design, seeking
> to repair most of the things people had hated about LOOP.
Wow, people hated LOOP even more before the ANSI version?! They must
have, like, really really hated it, a lot.
From: Lars Brinkhoff
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <85tzke35uj.fsf@junk.nocrew.org>
Kent M Pitman <······@nhplace.com> writes:
> I'll be pleased if there's programming at all in 100 years. Or 50.
> Global warming is really worrying me.
Maybe we should carve the ANSI CL document in stone for the next
civilization to rediscover.
In article
<····································@s8g2000prg.googlegroups.com>,
···········@gmail.com wrote:
...
> Oddly, the number one thing about Arc that you dislike about it seems
> to be that it isn't innovated by your definition of innovative.
> Why does it have to be innovative?
It doesn't. For me 'Arc' is a 'domain specific language'
for a certain type of programmer. Not more.
> Common Lisp wasn't innovative. If I'm
> not mistaken Common Lisp was just a mash-up of many other lisps.
You are mistaken.
Did you use the other Lisps before? I have. I can tell you
that Common Lisp was both innovative (CLOS) and a huge
improvement over languages like Standard Lisp, UCI Lisp,
Lisp Machine Lisp.
> While
> some things may have been added which weren't originally there,
> nothing was a spectacular change which couldn't have been easily
> implemented as a "plain thin library" on top of some other lisp.
Really? You should try to read a bit into the history
of Common Lisp and the tremendous amount of work to
get things working in a large programming language. Before
Common Lisp most Lisps got much the basic language model
wrong or confused. For example in Portable Standard Lisp
the Lisp worked differently when compiled or interpreted.
Scheme was doing fine, but it wasn't providing much
(no error handling, no dynamic variables, no namespaces, ...).
Common Lisp decribes a language with higher-order functions,
compilation/interpretation, macros, a full error handling system,
and so on. All had to work together and it does.
> Honestly, Pascal, Arc's biggest draw isn't what's different from
> scheme or common lisp, it's how it combines the best of both languages
> (at least I think it does).
Honestly, it does not even try to do that.
> I'm sure you'll disagree on some points,
> like it's lisp-1-ness and various other choices it made, but the idea
> was to combine the two languages.
That was a non-goal. Where did you read that?
> Like how Common Lisp was meant to
> combine the lisps which were available when it was made.
Wrong. That was no goal for Common Lisp. Not even near.
I'll list the goals here for you (from CLtL2):
http://lispm.dyndns.org/documentation/cltl2/clm/node6.html#SECTION00510000000000000000
Commonality
Common Lisp originated in an attempt to focus the work of several
implementation groups, each of which was constructing successor
implementations of MacLisp for different computers. These
implementations had begun to diverge because of the differences in
the implementation environments: microcoded personal computers
(Zetalisp, Spice Lisp), commercial timeshared computers (NIL-the
``New Implementation of Lisp''), and supercomputers (S-1
Lisp). While the differences among the several implementation
environments of necessity will continue to force certain
incompatibilities among the implementations, Common Lisp serves as a
common dialect to which each implementation makes any necessary
extensions.
Portability
Common Lisp intentionally excludes features that cannot be implemented
easily on a broad class of machines. On the one hand, features that
are difficult or expensive to implement on hardware without special
microcode are avoided or provided in a more abstract and efficiently
implementable form. (Examples of this are the invisible forwarding
pointers and locatives of Zetalisp. Some of the problems that they
solve are addressed in different ways in Common Lisp.) On the other
hand, features that are useful only on certain ``ordinary'' or
``commercial'' processors are avoided or made optional. (An example of
this is the type declaration facility, which is useful in some
implementations and completely ignored in others. Type declarations
are completely optional and for correct programs affect only
efficiency, not semantics.) Common Lisp is designed to make it easy to
write programs that depend as little as possible on machine-specific
characteristics, such as word length, while allowing some variety of
implementation techniques.
Consistency
Most Lisp implementations are internally inconsistent in that by
default the interpreter and compiler may assign different semantics to
correct programs. This semantic difference stems primarily from the
fact that the interpreter assumes all variables to be dynamically
scoped, whereas the compiler assumes all variables to be local unless
explicitly directed otherwise. This difference has been the usual
practice in Lisp for the sake of convenience and efficiency but can
lead to very subtle bugs. The definition of Common Lisp avoids such
anomalies by explicitly requiring the interpreter and compiler to
impose identical semantics on correct programs so far as possible.
Expressiveness
Common Lisp culls what experience has shown to be the most useful and
understandable constructs from not only MacLisp but also Interlisp,
other Lisp dialects, and other programming languages. Constructs
judged to be awkward or less useful have been excluded. (An example is
the store construct of MacLisp.)
Compatibility
Unless there is a good reason to the contrary, Common Lisp strives to
be compatible with Lisp Machine Lisp, MacLisp, and Interlisp, roughly
in that order.
Efficiency
Common Lisp has a number of features designed to facilitate the
production of high-quality compiled code in those implementations
whose developers care to invest effort in an optimizing compiler. One
implementation of Common Lisp, namely S-1 Lisp, already has a compiler
that produces code for numerical computations that is competitive in
execution speed to that produced by a Fortran compiler [11]. The S-1
Lisp compiler extends the work done in MacLisp to produce extremely
efficient numerical code [19].
Power
Common Lisp is a descendant of MacLisp, which has traditionally placed
emphasis on providing system-building tools. Such tools may in turn be
used to build the user-level packages such as Interlisp provides;
these packages are not, however, part of the Common Lisp core
specification. It is expected such packages will be built on top of
the Common Lisp core.
Stability
It is intended that Common Lisp will change only slowly and with due
deliberation. The various dialects that are supersets of Common Lisp
may serve as laboratories within which to test language extensions,
but such extensions will be added to Common Lisp only after careful
examination and experimentation.
> I know you
> disagree with a lot about Arc, but to me it's Common Lisp 2, because
> it was designed with the same idea in mind as CL was (despite what pg
> may say).
>
> Now, you never said you think CL is the hundred year language, so this
> doesn't really prove anything; but what leads you to believe that the
> next 100 year language must necessarily be innovative?
>
> Consider some of the most popular programming languages right now:
> Java, C, C++. Were they innovative? No, not really.
>
> > BTW, I wouldn't have any problems with Arc if Paul Graham just said what
> > it is: A neat scripting language, without substantially new ideas, like
> > most other neat scripting languages. But he promises much more, and
> > doesn't seem to deliver...
>
> Please ignore everything PG says about Arc. Arc is the programming
> language; Arc is what we are discussing here, not our personal
> feelings toward Mr. Graham, or what kind of ceremony it was released
> with. If you have no problems with Arc, why complain about it so
> avidly? What Arc is, is a fun programming language to use. It's not
> really USEFUL at the moment, but it has promise for the future.
> You are mistaken.
>
> Did you use the other Lisps before? I have. I can tell you
> that Common Lisp was both innovative (CLOS) and a huge
> improvement over languages like Standard Lisp, UCI Lisp,
> Lisp Machine Lisp.
No, I never used them, I figured things like macros and such were
standard in all lisps. I have been thoroughly corrected.
> > I'm sure you'll disagree on some points,
> > like it's lisp-1-ness and various other choices it made, but the idea
> > was to combine the two languages.
>
> That was a non-goal. Where did you read that?
I didn't read it anywhere; I just looked at what Arc looked like, its
general design. As Tilton wrote:
" I for one get that feeling from the fact that he believes in small
(Scheme) but kept CL macros and NIL-is-false. But then we see the
syntax
introduced to achieve brevity and that breaks with Lisp... "
My favorite thing about scheme is lisp-1; my favorite thing about CL
is unhygienic macros. Arc combines them whether it was a design goal
or not.
> > Like how Common Lisp was meant to
> > combine the lisps which were available when it was made.
>
> Wrong. That was no goal for Common Lisp. Not even near.
Sorry, apparently I was misinformed, much of the information you
provided could easily lead one to believe that it was meant for that:
> Commonality
>
> Common Lisp originated in an attempt to focus the work of several
> implementation groups, each of which was constructing successor
> implementations of MacLisp for different computers. These
> implementations had begun to diverge because of the differences in
> the implementation environments: microcoded personal computers
> (Zetalisp, Spice Lisp), commercial timeshared computers (NIL-the
> ``New Implementation of Lisp''), and supercomputers (S-1
> Lisp). While the differences among the several implementation
> environments of necessity will continue to force certain
> incompatibilities among the implementations, Common Lisp serves as a
> common dialect to which each implementation makes any necessary
> extensions.
Commonality, suggests that it was meant to combine several different
lisps because they "had begun to diverge" and where is the innovation
in combining things?
> Compatibility
>
> Unless there is a good reason to the contrary, Common Lisp strives to
> be compatible with Lisp Machine Lisp, MacLisp, and Interlisp, roughly
> in that order.
Compatibility here is exactly what gave me the impression that Common
Lisp wasn't innovative. I have been thoroughly corrected on that
matter as well.
> Power
>
> Common Lisp is a descendant of MacLisp, which has traditionally placed
> emphasis on providing system-building tools. Such tools may in turn be
> used to build the user-level packages such as Interlisp provides;
> these packages are not, however, part of the Common Lisp core
> specification. It is expected such packages will be built on top of
> the Common Lisp core.
Here it states quite clearly that CL is a descendant of MacLisp,
though it provides an example of where it diverges from it. This is
another reason which drove me to my impression.
> I will say, though,
> that I'd rather read about what people like about it than read about how
> people answer claims of "don't like" with pot shots at CL.
It was not my intention to take a pot shot at CL, CL is my favorite
programming language at this moment. I had erronously been under the
impression that it was not innovative for the reasons listed above and
I wasn't using that false belief to condemn CL, I was trying to use
that fact to defend Arc. Taking a shot at CL in c.l.l. would be the
first moniker of lunacy.
> This is not, I hope, defensiveness on my part. I was part of the CL
> process, so it could seem that way. But I think it's just an objective
> truth that CL had a number of new things... to the extent anything ever
> does. We all stand on the shoulders of giants, and all that...
No, you are right. I spoke mainly out of ignorance.
> Well, that pretty much means all of the music industry is not
> innovative. Once you start saying that to borrow from good ideas and
> reassemble them in other ways is to do nothing, you've pretty much
> defined everything as uninteresting.
Yes, I know. It's a depressing state of mind, yet some people
apparently take that point of view. Arc reassembles old ideas, this
doesn't mean it should be considered useless because it isn't
particularly innovative.
In article
<····································@d21g2000prf.googlegroups.com>,
···········@gmail.com wrote:
> > Commonality
> >
> > Common Lisp originated in an attempt to focus the work of several
> > implementation groups, each of which was constructing successor
> > implementations of MacLisp for different computers. These
> > implementations had begun to diverge because of the differences in
> > the implementation environments: microcoded personal computers
> > (Zetalisp, Spice Lisp), commercial timeshared computers (NIL-the
> > ``New Implementation of Lisp''), and supercomputers (S-1
> > Lisp). While the differences among the several implementation
> > environments of necessity will continue to force certain
> > incompatibilities among the implementations, Common Lisp serves as a
> > common dialect to which each implementation makes any necessary
> > extensions.
>
> Commonality, suggests that it was meant to combine several different
> lisps because they "had begun to diverge" and where is the innovation
> in combining things?
Read careful: Common Lisp was helping several groups,
which were working on successors to MacLisp, to work
together on a single new language.
Common Lisp was not meant to combine old dialects, say, MacLisp and
Standard Lisp. Common Lisp was meant to be a successor
to MacLisp and to prevent that work on several
successors created several non-compatible dialects.
So, Common Lisp was about moving forward, but with a single
language and not four (or more) different languages.
On 2008-02-09 16:21:39 -0500, ···········@gmail.com said:
> My favorite thing about scheme is lisp-1; my favorite thing about CL
> is unhygienic macros. Arc combines them whether it was a design goal
> or not.
there are already several scheme implementations that have a
common-lisp style defmacro available.
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
+---------------
| ···········@gmail.com said:
| > My favorite thing about scheme is lisp-1; my favorite thing about CL
| > is unhygienic macros. Arc combines them whether it was a design goal
| > or not.
|
| there are already several scheme implementations that have a
| common-lisp style defmacro available.
+---------------
*Including* MzScheme, Arc's current host, which for some reason I'm
finding increadibly funny at the moment, given that the following have
existed in my personal MzScheme init file for almost a decade: ;-} ;-}
;;;; rpw3-hacks.scm -- 980718 ····@sgi.com
;;;; The "usual suspects" I like to have around when writing
;;;; one-off scripts and doing interactive hacking.
...[other stuff]...
; I'm sorry, I got spoiled from using P'Lite...
(defmacro def (name . value)
`(define ,name ,@value))
(defmacro fn (args . body)
`(lambda ,args ,@body))
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Harald Hanche-Olsen
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <pco3as0u2i2.fsf@shuttle.math.ntnu.no>
+ ····@rpw3.org (Rob Warnock):
> (defmacro fn (args . body)
> `(lambda ,args ,@body))
I always wanted to call it �� myself. 8-)
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47af5bf2$0$15196$607ed4bc@cv.net>
Harald Hanche-Olsen wrote:
> + ····@rpw3.org (Rob Warnock):
>
>
>> (defmacro fn (args . body)
>> `(lambda ,args ,@body))
Aaaaauurrrghhhh! I learned loop so I would not have to type L-A-M-B-D-A!
> I always wanted to call it �� myself. 8-)
Lessee, c-q, searching...searching...
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Kent M Pitman
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <uodaoczks.fsf@nhplace.com>
Harald Hanche-Olsen <······@math.ntnu.no> writes:
> + ····@rpw3.org (Rob Warnock):
>
> > (defmacro fn (args . body)
> > `(lambda ,args ,@body))
>
> I always wanted to call it �� myself. 8-)
The Lisp Machine used the SAIL (Stanford AI Lab) character set, which
had Lambda allocated on code 008, and which aligned with BS
(backspace) in ASCII. In MACLISP code (sometimes with help from #+/#-
compatibility), you could write such a compatibility macro. But this
meant that on "glass" displays (CRT displays that were not bitmapped
and could not overstrike), it had a delete effect; on paper terminals
and some display terminals, it backed up and overstruck; and in EMACS
it displayed as ^H ...
Some people used it anyway, and it just looked very weird.
Kent M Pitman <······@nhplace.com> writes:
> Harald Hanche-Olsen <······@math.ntnu.no> writes:
>
>> + ····@rpw3.org (Rob Warnock):
>>
>> > (defmacro fn (args . body)
>> > `(lambda ,args ,@body))
>>
>> I always wanted to call it λ myself. 8-)
>
> The Lisp Machine used the SAIL (Stanford AI Lab) character set, which
> had Lambda allocated on code 008, and which aligned with BS
> (backspace) in ASCII. In MACLISP code (sometimes with help from #+/#-
> compatibility), you could write such a compatibility macro. But this
> meant that on "glass" displays (CRT displays that were not bitmapped
> and could not overstrike), it had a delete effect; on paper terminals
> and some display terminals, it backed up and overstruck; and in EMACS
> it displayed as ^H ...
>
> Some people used it anyway, and it just looked very weird.
Nowadays, one can easily bind in emacs a key to any character.
There are a lot of useless keys on a PC-105 keyboard...
--
__Pascal Bourguignon__ http://www.informatimago.com/
Our enemies are innovative and resourceful, and so are we. They never
stop thinking about new ways to harm our country and our people, and
neither do we. -- Georges W. Bush
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t6bx4vwyut4oq5@pandora.alfanett.no>
P� Sun, 10 Feb 2008 22:54:09 +0100, skrev Pascal Bourguignon
<···@informatimago.com>:
>>
>> Some people used it anyway, and it just looked very weird.
>
> Nowadays, one can easily bind in emacs a key to any character.
> There are a lot of useless keys on a PC-105 keyboard...
>
>
And have people wonder how to get that key. And what key's are 'useless'
depends on the language. and..
I think it's just as well to stick with ASCII..
--------------
John Thingstad
"John Thingstad" <·······@online.no> writes:
> På Sun, 10 Feb 2008 22:54:09 +0100, skrev Pascal Bourguignon
> <···@informatimago.com>:
>
>>>
>>> Some people used it anyway, and it just looked very weird.
>>
>> Nowadays, one can easily bind in emacs a key to any character.
>> There are a lot of useless keys on a PC-105 keyboard...
>>
>>
>
> And have people wonder how to get that key. And what key's are
> useless' depends on the language. and..
> I think it's just as well to stick with ASCII..
Not that key, that character. You cannot worry about other people's
keyboards. Some use French AZERTY, some Greek keyboards, some Russian
or Hebrew, etc. Let them worry about how to find a λ character.
Any lisp programmer using emacs can put something like:
(global-set-key (kbd "A-l") (lambda () (interactive) (insert "λ")))
in his ~/.emacs file.
On the other hand, emacs has various input methods, including a greek
one, so you can get λ just switching to the greep input method, and
typing l.
I bind C-f11 to (lambda nil (interactive) (set-input-method (quote greek)))
and use C-\ to switch between greek and the current input method.
But this is just me. You may prefer to use a different keyboard
layout and place λ on some other more practical key.
--
__Pascal Bourguignon__ http://www.informatimago.com/
In a World without Walls and Fences,
who needs Windows and Gates?
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t6bz8ovwut4oq5@pandora.alfanett.no>
På Sun, 10 Feb 2008 23:41:12 +0100, skrev Pascal Bourguignon
<···@informatimago.com>:
>>
>> And have people wonder how to get that key. And what key's are
>> useless' depends on the language. and..
>> I think it's just as well to stick with ASCII..
>
> Not that key, that character. You cannot worry about other people's
> keyboards. Some use French AZERTY, some Greek keyboards, some Russian
> or Hebrew, etc. Let them worry about how to find a λ character.
>
>
> Any lisp programmer using emacs can put something like:
> (global-set-key (kbd "A-l") (lambda () (interactive) (insert "λ")))
> in his ~/.emacs file.
>
> On the other hand, emacs has various input methods, including a greek
> one, so you can get λ just switching to the greep input method, and
> typing l.
>
> I bind C-f11 to (lambda nil (interactive) (set-input-method (quote
> greek)))
> and use C-\ to switch between greek and the current input method.
>
> But this is just me. You may prefer to use a different keyboard
> layout and place λ on some other more practical key.
>
Yeah. I used to have a few of those to support Norwegian characters ÆØÅæøå.
As for using λ for lambda. I'd just use a modify the reader syntax.
But following Rob Warnock's £ readmacro syntax idea.
(mapcar λ(format "~A:~A" λ1 λ2) list)
--------------
John Thingstad
From: Kent M Pitman
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <u63wwrqbr.fsf@nhplace.com>
"John Thingstad" <·······@online.no> writes:
> As for using � for lambda. I'd just use a modify the reader syntax.
> But following Rob Warnock's � readmacro syntax idea.
British-pounds-sterling-sign readmacro? (That's what I see in my Emacs
newsreader.)
> (mapcar �(format "~A:~A" �1 �2) list)
Here, by contrast, I see lambdas.
But I'm curious: how does the nesting of this macro work? What does
(lambda (x)
(lambda (y z)
(f x y z)))
look like in this shorthand format?
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t6cmjchfut4oq5@pandora.alfanett.no>
På Mon, 11 Feb 2008 06:54:00 +0100, skrev Kent M Pitman
<······@nhplace.com>:
> "John Thingstad" <·······@online.no> writes:
>
>> As for using λ for lambda. I'd just use a modify the reader syntax.
>> But following Rob Warnock's £ readmacro syntax idea.
Typo: should be $ readmacro.
>
> British-pounds-sterling-sign readmacro? (That's what I see in my Emacs
> newsreader.)
>
>> (mapcar λ(format "~A:~A" λ1 λ2) list)
>
> Here, by contrast, I see lambdas.
>
> But I'm curious: how does the nesting of this macro work? What does
>
> (lambda (x)
> (lambda (y z)
> (f x y z)))
>
> look like in this shorthand format?
λ(λ1 λ(f λ1 λ2 λ3))
--------------
John Thingstad
[Hope I've untangled/attributed the quotes correctly...]
John Thingstad <·······@online.no> wrote:
+---------------
| > "John Thingstad" <·······@online.no> writes:
| >> But following Rob Warnock's £ readmacro syntax idea.
|
| Typo: should be $ readmacro.
+---------------
Actually, should be #$ readmacro. It's too minor to eat all of $.
Kent M Pitman <······@nhplace.com>:
+---------------
| > (mapcar λ(format "~A:~A" λ1 λ2) list)
| Here, by contrast, I see lambdas.
+---------------
I don't, I just see weird two- or three- characters sequences.
Must be some UTF-8 or ISO-8859 thingies I can't see.
But here's a really twisted one for those with "dumb" terminals:
Instead of using FN to abbreviate LAMBDA, we can use /. which
kinda looks like a lambda is you squint: ;-}
> (defmacro /. (args &body body) `(lambda ,args ,@body))
/.
> (mapcar (/. (x) (* 3 x)) (iota 5))
(0 3 6 9 12)
>
Kent M Pitman <······@nhplace.com> asked:
+---------------
| But I'm curious: how does the nesting of this macro work? What does
| (lambda (x)
| (lambda (y z)
| (f x y z)))
| look like in this shorthand format?
+---------------
With /. it's easy:
(/. (x)
(/. (y z)
(f x y z)))
but of course with #$ you can't do it without introducing
a renaming variable [just like with nested shell functions]:
#$(let ((x $1))
#$(f x $1 $2))
But how often do you need to type that at the REPL? ...which is
where #$ was intended to be used, *NOT EVER* in coding source files!
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Joost Diepenmaat
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <8763wvd6p6.fsf@zeekat.nl>
····@rpw3.org (Rob Warnock) writes:
> But here's a really twisted one for those with "dumb" terminals:
> Instead of using FN to abbreviate LAMBDA, we can use /. which
> kinda looks like a lambda is you squint: ;-}
>
> > (defmacro /. (args &body body) `(lambda ,args ,@body))
>
> /.
> > (mapcar (/. (x) (* 3 x)) (iota 5))
I like that; it's short, it looks kinda nice and it's only 2 keystrokes.
Joost.
In article <··············@zeekat.nl>,
Joost Diepenmaat <·····@zeekat.nl> wrote:
> ····@rpw3.org (Rob Warnock) writes:
>
> > But here's a really twisted one for those with "dumb" terminals:
> > Instead of using FN to abbreviate LAMBDA, we can use /. which
> > kinda looks like a lambda is you squint: ;-}
> >
> > > (defmacro /. (args &body body) `(lambda ,args ,@body))
> >
> > /.
> > > (mapcar (/. (x) (* 3 x)) (iota 5))
>
> I like that; it's short, it looks kinda nice and it's only 2 keystrokes.
"fn" is only two keystrokes too, and IMHO looks a lot better (and is
much more reminiscent of "function") than /. (which really ought to be
.\ if you want it to look like a lambda).
rg
On Feb 11, 5:56 pm, Ron Garret <·········@flownet.com> wrote:
> In article <··············@zeekat.nl>,
> Joost Diepenmaat <·····@zeekat.nl> wrote:
>
> > ····@rpw3.org (Rob Warnock) writes:
>
> > > But here's a really twisted one for those with "dumb" terminals:
> > > Instead of using FN to abbreviate LAMBDA, we can use /. which
> > > kinda looks like a lambda is you squint: ;-}
>
> > > > (defmacro /. (args &body body) `(lambda ,args ,@body))
>
> > > /.
> > > > (mapcar (/. (x) (* 3 x)) (iota 5))
>
> > I like that; it's short, it looks kinda nice and it's only 2 keystrokes.
>
> "fn" is only two keystrokes too, and IMHO looks a lot better (and is
> much more reminiscent of "function") than /. (which really ought to be
> .\ if you want it to look like a lambda).
>
> rg
Yes, but /. or /_ (looks like an L) are much mure Perlish! Which is
one of the driving forces of programming today.
Cheers
--
Marco
"Perl is the programming language whose design goal is to increase a
programmer's self-esteem" (paraphrase of a Steele-Gosling exchange at
OOPSLA 2007)
On Feb 12, 11:02 am, Marco Antoniotti <·······@gmail.com> wrote:
> On Feb 11, 5:56 pm, Ron Garret <·········@flownet.com> wrote:
>
> > "fn" is only two keystrokes too, and IMHO looks a lot better (and is
> > much more reminiscent of "function") than /. (which really ought to be
> > .\ if you want it to look like a lambda).
>
> > rg
>
> Yes, but /. or /_ (looks like an L) are much mure Perlish! Which is
> one of the driving forces of programming today[*].
You forgot the footnote:
[*] For values of "today" between 1996 and 2001
From: Espen Vestre
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m1myq61ih5.fsf@vestre.net>
"Thomas F. Burdick" <········@gmail.com> writes:
> You forgot the footnote:
>
> [*] For values of "today" between 1996 and 2001
No, that's wrong. It should be "For values of 'today' between
September 1st, 1993 and September 1352nd, 1993".
I don't understand all this hostility to lambda. Be happy, enjoy your
language while you can, while you're debating this instead of hacking
lisp, evildoers may already be at work writing a 32456 page
specification of New World Order Lisp, with /this/ lambda:
<ansi.lisp.common.core.special-forms.lambda>
<ansi.lisp.common.core.special-forms.lambda.arglist>
....
</ansi.lisp.common.core.special-forms.lambda.arglist>
<ansi.lisp.common.core.special-forms.lambda.body>
....
</ansi.lisp.common.core.special-forms.lambda.body>
</ansi.lisp.common.core.special-forms.lambda>
--
(espen)
On Feb 12, 6:12 am, Espen Vestre <·····@vestre.net> wrote:
> I don't understand all this hostility to lambda.
The name "lambda" is terrifying to newbies. "ZOMG, what
is that??? You mean it's not a regular function? I can
hardly understand macros and now there's a THIRD kind of
function-like thingy? With a name from a language I don't
even know, this must be some kind of bizarre hyper-function
or something!"
--Dan
www.prairienet.org/~dsb/
On Feb 12, 3:17 pm, danb <·········@gmail.com> wrote:
> On Feb 12, 6:12 am, Espen Vestre <·····@vestre.net> wrote:
>
> > I don't understand all this hostility to lambda.
>
> The name "lambda" is terrifying to newbies. "ZOMG, what
> is that???
Good point. Instead of scaring noobs with greek and removing their
fun ("DE-fun?!?! AAAA!"), we should dedicate one day a week
(Noobsday?) to making things easier for them. Here's my attempt at
addressing the above issues:
(extra-fun alist->plist (alist)
(mapcan (kittehs! (pair) (list (car pair) (cdr pair)))
alist))
Note how the ! marks the exciting part of the code. Maybe we could
rename LOOP to WHEE! as well...
> > On Feb 12, 6:12 am, Espen Vestre wrote:
> > > I don't understand all this hostility to lambda.
> On Feb 12, 3:17 pm, danb wrote:
> > The name "lambda" is terrifying to newbies.
> > "ZOMG, what is that???
On Feb 12, 8:30 am, "Thomas F. Burdick" wrote:
> ("DE-fun?!?! AAAA!"),
I've never heard complaints about defun.
> Maybe we could rename LOOP to WHEE! as well...
Very entertaining. Are you aware that "loop" is English?
If part of the goal is to intentionally create stumbling
blocks that weed out less adept individuals, then "lambda"
is fine. Haskell seems ideal for that purpose. I'm not
even saying that doesn't have its merits. The more I hang
out here, learn Lisp, and hear about patterns in the Java
community, the more I see how one might want to discourage
people who really would hurt themselves using Lisp. Person-
ally, I'd rather do user filtering in a more substantive way,
by adding features to the language that intimidate noobs
because the features are so abstract (but not gratuitous),
instead of because their names are greek. "lambda" is
gratuitous obfuscation, and it doesn't even reduce the
character count.
--Dan
www.prairienet.org/~dsb/
danb wrote:
>>>On Feb 12, 6:12 am, Espen Vestre wrote:
>>>
>>>>I don't understand all this hostility to lambda.
>
>
>>On Feb 12, 3:17 pm, danb wrote:
>>
>>>The name "lambda" is terrifying to newbies.
>>>"ZOMG, what is that???
>
>
> On Feb 12, 8:30 am, "Thomas F. Burdick" wrote:
>
>>("DE-fun?!?! AAAA!"),
>
>
> I've never heard complaints about defun.
>
>
>>Maybe we could rename LOOP to WHEE! as well...
>
>
> Very entertaining. Are you aware that "loop" is English?
Ah, but is the sound we make when we go shooting round one. Well, one
the creaky wooden ones I usually go "Aaaaaaaaaaaaarrrrgggghhhh!", but
that would wreak havoc with the indentation.
> I'd rather do user filtering in a more substantive way,
> by adding features to the language that intimidate noobs
> because the features are so abstract
I've done my part. Hell, even the veterans cannot deal with:
http://smuglispweeny.blogspot.com/2008/02/cells-manifesto.html
Wimps!
kenny
ps. Doing ArcCellsLite today. k
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
> danb wrote:
> > Very entertaining. Are you aware that "loop" is English?
Kenny wrote:
> Ah, but is the sound we make when we go shooting round one.
> Well, one the creaky wooden ones I usually go
> "Aaaaaaaaaaaaarrrrgggghhhh!", but that would wreak havoc with
> the indentation.
Suit yourself. I'll take ITER, please.
> I've done my part. Hell, even the veterans cannot deal with:
> http://smuglispweeny.blogspot.com/2008/02/cells-manifesto.html
It's parenthesIs, Kenny. Singular.
ALL YOUR PARENTHESIS ARE BELONG TO US
http://en.wikipedia.org/wiki/All_your_base_are_belong_to_us
> Wimps!
N000b
--Dan
www.prairienet.org/~dsb/
danb wrote:
> It's parenthesIs, Kenny. Singular.
> ALL YOUR PARENTHESIS ARE BELONG TO US
> http://en.wikipedia.org/wiki/All_your_base_are_belong_to_us
That's the first damn useful bit of information I have seen in this NG
all year!!!
Thanks!!!
Kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 12, 11:44 am, Ken Tilton <···········@optonline.net> wrote:
>
> ps. Doing ArcCellsLite today. k
>
Neat! Be sure to post your progress on your blog. BTW, Arc1 is out
today:
http://arclanguage.org/item?id=2166
John Stoneham wrote:
> On Feb 12, 11:44 am, Ken Tilton <···········@optonline.net> wrote:
>
>>ps. Doing ArcCellsLite today. k
>>
>
>
> Neat! Be sure to post your progress on your blog.
Yeah, good call, my next blog entry will be its development, I'll just
keep editing it as I go. Don't know if that's bloglegal...
> BTW, Arc1 is out
Thx, it will be interesting to see what changed. I am pretty sure
nothing that would affect me.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On 13 Feb, 09:04, Ken Tilton <···········@optonline.net> wrote:
> John Stoneham wrote:
> > On Feb 12, 11:44 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>ps. Doing ArcCellsLite today. k
>
> > Neat! Be sure to post your progress on your blog.
>
> Yeah, good call, my next blog entry will be its development, I'll just
> keep editing it as I go. Don't know if that's bloglegal...
>
> > BTW, Arc1 is out
>
> Thx, it will be interesting to see what changed. I am pretty sure
> nothing that would affect me.
>
> kenny
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
Instead of investing so much effort in coding in a dialect of
MzScheme;
why don't you document some incarnation of Cells in (e.g.) a book
together with lots of nice examples for people to learn from? You can
then sell it and avoid Starbucks ;) I think documentation is one area
which would help Cells a lot.
Mark
Mark Tarver <··········@ukonline.co.uk> writes:
> On 13 Feb, 09:04, Ken Tilton <···········@optonline.net> wrote:
>> John Stoneham wrote:
>> > BTW, Arc1 is out
>>
>> Thx, it will be interesting to see what changed. I am pretty sure
>> nothing that would affect me.
>
> Instead of investing so much effort in coding in a dialect of
> MzScheme;
Arc is not a dialect of MzScheme.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://www.barzilay.org/ Maze is Life!
On Feb 13, 9:20 am, Eli Barzilay <····@barzilay.org> wrote:
> Arc is not a dialect of MzScheme.
He might not have meant that literally. AAR, why do you love Arc so
much? Are you also a fan of Alan Turing? It all seems _rather_
suspicious to me.
> Instead of investing so much effort...
Effort? Cells Lite is trivial.
> I think documentation is one area
> which would help Cells a lot.
I doubt it. I did this and no one asked any questions.
http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?rev=1.11&root=cells&view=log
"There is no doc!" is just what people say so they do not have to learn
something new -- create the doc and they will find another reason.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 13, 10:58 am, Ken Tilton <···········@optonline.net> wrote:
> > Instead of investing so much effort...
>
> Effort? Cells Lite is trivial.
>
> > I think documentation is one area
> > which would help Cells a lot.
>
> I doubt it. I did this and no one asked any questions.
>
> http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?...
>
> "There is no doc!" is just what people say so they do not have to learn
> something new -- create the doc and they will find another reason.
Well, Cells solves the wrong problem, if popularity is your priority.
To hit the top of the pops you must give a nod to the nods on the
docks. Cells doesn't, immediately, solve any problems. I mean, if
Cells provided database access, or sent mail, or provided sexual
favors (perhaps with a Turing-equivalent mode, for those so
inclined)... then you would see popularity. And then docs would be
really useful.
On Feb 14, 2:06 am, Campo <··········@yahoo.com> wrote:
> Cells doesn't, immediately, solve any problems.
The same could be said for CLOS itself, for someone who doesn't intend
to use OOP. This is an extremely closed minded statement and says more
about how you view your own problems than it does about Cells.
On Feb 14, 6:52 am, John Stoneham <··············@gmail.com> wrote:
> On Feb 14, 2:06 am,Campo<··········@yahoo.com> wrote:
>
> > Cells doesn't, immediately, solve any problems.
>
> The same could be said for CLOS itself, for someone who doesn't intend
> to use OOP. This is an extremely closed minded statement and says more
> about how you view your own problems than it does about Cells.
On Feb 14, 6:52 am, John Stoneham <··············@gmail.com> wrote:
> On Feb 14, 2:06 am,Campo<··········@yahoo.com> wrote:
>
> > Cells doesn't, immediately, solve any problems.
>
> The same could be said for CLOS itself, for someone who doesn't intend
> to use OOP.
It could actually be said of CLOS even for someone who does intend to
use OOP. CLOS hasn't, itself, set the world on fire, y'know.
>This is an extremely closed minded statement and says more
> about how you view your own problems than it does about Cells.
You assume too much, Sir! Pistols at dawn ;). Seriously though, your
talents are wasted here- I recently found a blog where I think you
could do more good. http://brucio.blogspot.com/2007/03/why-lisp.html#comments
is crying out for your input. Well, assuming you're not "anonymous" in
that thread.
Anyway, I don't think I said much about the merits of Cells. I didn't
say that Cells was not the best thing since sliced bread, for
instance. I just offered an explanation for why it hasn't caught on as
well as sliced bread has. (nota bene: sliced bread is actually a very
bad idea.) I wouldn't normally volunteer that sort of explanation, but
since Cells's originator was complaining that Cells was not yet in
every toaster in the land, I thought I'd, uselessly, chime in (nota
gratis: chimes are not necessarily as good an idea as they seem at
first, though it's possible that that says more about my problems than
it does about chimes). I was just following a simple lisp axiom I once
heard about concision and powerfulness, and how they relate.
My main point is this: it's very difficult to get a lot of people to
pick up a new abstraction quickly, no matter how useful it is, if the
abstraction is all that's on offer. Cells isn't actually an entirely
new abstraction, of course. I used to work with a C++ library for 3D
graphics in which one was supposed to hook together a whole bunch of
spreadsheet-like components and then watch as one's creations
quivered, lifted themselves off the floor in an eerie semblance of
life, and staggered about for a while before becoming a zombie version
of the lineup at Radio City Music Hall. That might sound kind of bad,
but at the time it was considered a fairly successful C++ library.
Unfortunately, it did not have an smpt component, so it returned to
its maker, which was promptly bought out by a webmail company and
dissolved (in a vat of silver chloride. At least I like to imagine
that it happened that way).
Now, I assume that Kenny's version has no whiff of the grave about it
(which is fair- it isn't C++). That said, the number of times I've
been writing some code and said to myself "You know what I need here?
Cells!" can be counted on no fingers. If I were writing a spreadsheet
program I might look at it, because it has been described as having
something to do with a spreadsheet-like mechanism, so who knows
(though I have to admit that my instinct is that most things that are
spreadsheet-like are not useful for writing a spreadsheet program). If
I were writing a scenegraph API I would definitely look at it, because
I already know how that sort of abstraction can be used in writing
scenegraph APIs. But for most things I am not going to grab Cells,
even if it would write my code for me while blowing me, because I have
no idea that that is the case. It's a sort of chicken and egg problem.
That's not fair, and it's in no way a reflection on the sliced-
breadness of Cells, but it is ineluctably the case. I suppose after
posting this I'll have to go learn Cells just to feel a bit better
about myself, but...
Now, if I were sucked into using it because it was the basis of
something I couldn't live without, I would learn it and then- well I
imagine I would be sitting around one day writing some imap code and
it would be like a bolt from the blue: Cells! It sends mail! It lays
the chicken _and_ the egg!
Now, to be fair, Kenny set out to create a killer app, or at least a
killer lib. A portable GUI library was looking pretty sexy at that
time. But there was a bit of GUI muddle at that point, and then it
turned out that his gui wasn't very useful for writing reddit (I think
it actually made the top 5 things they didn't even mention about why
they didn't write reddit in lisp), so...
Anyway, I have no idea how you could have come to the conclusion that
you had any idea about how I view my problems from what I posted, or
whether or not that post revealed less or more about that than about
Cells. I certainly didn't want to run the risk that you might, on your
deathbed, sit bolt upright and yell out "I was horribly, horribly
wrong in that usenet post." So I had to sit down and write a post
about which your post would be retroactively true.
Campo wrote:
> Now, I assume that Kenny's version has no whiff of the grave about it
> (which is fair- it isn't C++). That said, the number of times I've
> been writing some code and said to myself "You know what I need here?
> Cells!" can be counted on no fingers.
That could say more about you than either Cells or its doc, I think I
motivated Cells well enough for bright people anyway:
http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?root=cells&view=markup
> If I were writing a spreadsheet
> program I might look at it, because it has been described as having
> something to do with a spreadsheet-like mechanism,...
You have all the AI of Google Adsense, which took a look at:
> As our 'application pushing down on the core' we'll use my favorite, a furnace boiler.
>
>
> (= b* (obj outside-temp 72
> on? [< _!outside-temp 50])))
from here:
http://smuglispweeny.blogspot.com/2008/02/arc-cells-baby-steps_14.html
and started running furnace installation ads on my blog.
When one uses an analogy between X and Y one is not saying X and Y are
the same, one is saying they in some respect work the same so if I tell
you you need to let off a little steam please don't go drilling holes in
your skull.
> I were writing a scenegraph API I would definitely look at it, because
> I already know how that sort of abstraction can be used in writing
> scenegraph APIs.
So you /do/ know what Cells does. Hmmm.
> But for most things I am not going to grab Cells,
> even if it would write my code for me while blowing me, because I have
> no idea that that is the case.
So you know what Cells does and you look at your code and you cannot
even tell if it applies? Oh, my.
> It's a sort of chicken and egg problem.
> That's not fair, and it's in no way a reflection on the sliced-
> breadness of Cells, but it is ineluctably the case.
"Not fair"? To Cells? Please, it is just a little software hack with
lots and lots of company. See the above manifesto for a good sampling of
similar art (you want a Web thingy, try Flapjax) and let's save "unfair"
for the IRS persecution of Joe Louis.
> I suppose after
> posting this I'll have to go learn Cells just to feel a bit better
> about myself, but...
No, don't bother. There is nothing there you do not already understand,
and you are right: the light will not go on until you have something
real worldy into which you have sunk your teeth and banged away for a
while and /then/ the light will go on.
It's all well and good for me to mock you for not being able to work
from first principles and your experience coding to realize how much
manual state management you do, but hey, not every application requires
interesting state management, the last I worked on did not and I did not
use Cells so maybe you do not have the experience after all, but that's
not how people work is it? I confess I do not work that way. OO was an
exception because when I heard about it I recognized at once all my C
switch statements off the "typ" attribute of my structures, but then
maybe what we are saying is that OO was not the paradigm shift that
dataflow is. Which is right, we need a new killer app.
Thanks, I was almost about to start working on Algebra again.
>
> Now, if I were sucked into using it because it was the basis of
> something I couldn't live without, I would learn it and then- well I
> imagine I would be sitting around one day writing some imap code and
> it would be like a bolt from the blue: Cells! It sends mail! It lays
> the chicken _and_ the egg!
Oh, sure, this is not a scoop. I knew on day one people would not get it
without an application. I just thought a GUI would do it, I am a desktop
dinosaur.
One person got it pretty quickly because he had been a KR fan (more
Cells prior art) so he knew the paradigm.
>
> Now, to be fair, Kenny set out to create a killer app, or at least a
> killer lib. A portable GUI library was looking pretty sexy at that
> time. But there was a bit of GUI muddle at that point, and then it
> turned out that his gui wasn't very useful for writing reddit (I think
> it actually made the top 5 things they didn't even mention about why
> they didn't write reddit in lisp), so...
I would have done something with Cells and the Arc server lib if it did
not take 30 seconds to serve a page (if it felt like it, which was about
50% of the time in the small sample size I collected before getting
disgusted with the FSF zombies (yes, sad to say pg and company included)
who think no one uses Windows because Bill Gates is evil so let's burn a
quarter of our lives on OS maintenance, that'll teach him!)
Then I started to build Hunch but got exhausted after about ten
prerequisite libraries. I suppose I should have used ASDF-install. But
it was not much worse than cl-s3, I'll try again.
Help a dinosaur, people. Will Hunch be like Arc, meaning I can just
develop on my desktop with that localhost url thingy? Maybe I should do
that as a retraining exercise so I can find some paying work.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton wrote:
> Then I started to build Hunch but got exhausted after about ten
> prerequisite libraries. I suppose I should have used ASDF-install.
"Windows note: If you want to use ASDF-INSTALL on Windows you must
install Cygwin first. "
There is so little hope for You People.
<sigh>
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sun, 24 Feb 2008 11:53:57 -0500, Ken Tilton <···········@optonline.net> wrote:
> Will Hunch be like Arc, meaning I can just develop on my desktop
> with that localhost url thingy?
Assuming you mean Hunchentoot, the answer is yes. That's what I'm
doing all the time.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Sun, 24 Feb 2008 11:53:57 -0500, Ken Tilton <···········@optonline.net> wrote:
>
>
>>Will Hunch be like Arc, meaning I can just develop on my desktop
>>with that localhost url thingy?
>
>
> Assuming you mean Hunchentoot, the answer is yes. That's what I'm
> doing all the time.
Coolio. Add Hunch-o-cells to my ECLM 2008 Kennynote Address TOC.
I have actually been toying with an idea for a truly bizarro social web
site -- snagged a decent domain name a couple of weeks ago I was so
pumped, no clue if the idea will work so the Web site is an experiment
on and of itself -- and it will be DB intensive so I can roll it all up
(Cells, Hunch, AllegroGraph) and have a ball.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sun, 24 Feb 2008 13:48:08 -0500, Ken Tilton <···········@optonline.net> wrote:
> Add Hunch-o-cells to my ECLM 2008 Kennynote Address TOC.
Good... :)
> I have actually been toying with an idea for a truly bizarro social
> web site -- snagged a decent domain name a couple of weeks ago I was
> so pumped, no clue if the idea will work so the Web site is an
> experiment on and of itself -- and it will be DB intensive so I can
> roll it all up (Cells, Hunch, AllegroGraph) and have a ball.
Not trying to denigrate my own stuff, but wouldn't AllegroServe be the
more natural choice for you?
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz wrote:
> On Sun, 24 Feb 2008 13:48:08 -0500, Ken Tilton <···········@optonline.net> wrote:
>
>
>>Add Hunch-o-cells to my ECLM 2008 Kennynote Address TOC.
>
>
> Good... :)
>
>
>>I have actually been toying with an idea for a truly bizarro social
>>web site -- snagged a decent domain name a couple of weeks ago I was
>>so pumped, no clue if the idea will work so the Web site is an
>>experiment on and of itself -- and it will be DB intensive so I can
>>roll it all up (Cells, Hunch, AllegroGraph) and have a ball.
>
>
> Not trying to denigrate my own stuff, but wouldn't AllegroServe be the
> more natural choice for you?
>
Mindreader! Yeah, the light went on*, already playing with that now,
came back to ask if you thought Hunch and/or cl-who have any advantage
over the Franz stuff. cl-who should be easy enough to explore if I do
not like Franz's html genner, I think I got that one built already.
kenny
* I keep forgetting that I have given up on saving You People. Ports to
Hunch/Redland/cl-who will be left as an exercise. k
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sun, 24 Feb 2008 14:47:13 -0500, Ken Tilton <···········@optonline.net> wrote:
> came back to ask if you thought Hunch and/or cl-who have any
> advantage over the Franz stuff.
They work with the Lisp I am using. And they don't use IF*... :)
AllegroServe is probably fine if you're on AllegroCL, but Portable
AllegroServe never looked like a viable alternative to me.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Feb 24, 11:53 am, Ken Tilton <···········@optonline.net> wrote:
> Campo wrote:
> > Now, I assume that Kenny's version has no whiff of the grave about it
> > (which is fair- it isn't C++). That said, the number of times I've
> > been writing some code and said to myself "You know what I need here?
> > Cells!" can be counted on no fingers.
>
> That could say more about you than either Cells or its doc,
I tried to make it clear that I wasn't criticizing Cells or its doc. I
suppose I am the only variable left in the equation. I think that if
you read carefully you'll find that "what that says about me" was the
entire point, though I don't use the phrase in a pejorative sense.
> I think I
> motivated Cells well enough for bright people anyway:
>
> http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?...
Well, I won't make any direct claims about my wattage. That would be
either unseemly or far too modest ;). But, I never said you hadn't
motivated Cells well enough in your docs.
> > If I were writing a spreadsheet
> > program I might look at it, because it has been described as having
> > something to do with a spreadsheet-like mechanism,...
>
> You have all the AI of Google Adsense, which took a look at:
>
> > As our 'application pushing down on the core' we'll use my favorite, a furnace boiler.
>
> > (= b* (obj outside-temp 72
> > on? [< _!outside-temp 50])))
>
> from here:
>
> http://smuglispweeny.blogspot.com/2008/02/arc-cells-baby-steps_14.html
>
> and started running furnace installation ads on my blog.
I'll take that as a compliment. Adsense is enormously successful,
after all. If I had that kind of "artificial intelligence" (read: net
worth) I would buy a small American city, retire there as King, and
lead a Beeblebroxian lifestyle. I do have to point out that you elided
the part where I pointed out that I was joking, or at least that the
fact that you called it "spreadsheet-like" didn't mean that it was
meant for writing spreadsheets.
> > I were writing a scenegraph API I would definitely look at it, because
> > I already know how that sort of abstraction can be used in writing
> > scenegraph APIs.
>
> So you /do/ know what Cells does. Hmmm.
Well- I know how to use that sort of abstraction in one context (a
context for which it is particularly well-suited). I can generalize it
to similar contexts. I can do this because I have seen it similarly
generalized. The more I have used a particular abstraction, the more
likely I am to find it applicable to a particular domain. Is that a
surprise?
> > But for most things I am not going to grab Cells,
> > even if it would write my code for me while blowing me, because I have
> > no idea that that is the case.
>
> So you know what Cells does and you look at your code and you cannot
> even tell if it applies? Oh, my.
I look at a problem and think... there are a number of ways I could go
with this. I could organize it thus and so, or thus and so. Some
abstractions spring to mind, and some don't (I imagine that it is rare
that I find a solution that could be called optimal, in cases where
optimal can't be precisely defined). This necessarily says a lot about
me. I have to admit that I don't approach every problem thinking
"Cells". So.. oh my ;).
> No, don't bother. There is nothing there you do not already understand,
> and you are right: the light will not go on until you have something
> real worldy into which you have sunk your teeth and banged away for a
> while and /then/ the light will go on.
Well, that's all I was saying ;). I think I do actually have a pretty
good idea of what Cells does. But I won't _really_ have it as part of
my toolkit until I do actually use it for something. This despite the
fact that I've done quite a lot of programming in libraries with a
very similar view of the world (and abandoned them, but that was more
about implementations and hardware issues than anything else). I'm not
criticizing Cells- I'm saying that people are more likely to pick up
something written in Cells than they are to pick up Cells.
> It's all well and good for me to mock you for not being able to work
> from first principles and your experience coding to realize how much
> manual state management you do, but hey, not every application requires
> interesting state management, the last I worked on did not and I did not
> use Cells so maybe you do not have the experience after all, but that's
> not how people work is it? I confess I do not work that way. OO was an
> exception because when I heard about it I recognized at once all my C
> switch statements off the "typ" attribute of my structures, but then
> maybe what we are saying is that OO was not the paradigm shift that
> dataflow is. Which is right, we need a new killer app.
This was to some extent my point, though I'm not sure that dataflow is
going to be as big a paradigm shift as OO was. At the moment the kind
of state management I need is not easily addressed by existing models,
and I can't see how Cells would help me. I'm basically building lots
of state and then tearing it down, over and over- in some cases I am
doing some ad hoc caching, and I'm hoping that a pattern emerges. At
any rate, you can feel free to mock me, but I'm not sure that Cells
would solve my problems- OO doesn't.
But yeah- things get adopted because of killer apps. That was mostly
my point. "New" abstractions are a dime a dozen. People "like to stay
current", but that usually means something like.. I think the new word
is "behavior driven design", or something. (I'm working on my own
consulting paradigm. I call it syntax-driven design. It has the virtue
of being entirely unoriginal, thus tried and true. Look for it at
kolmogorovwasfullofit.com.)
> Thanks, I was almost about to start working on Algebra again.
Well, anything to keep you from work.
>
> > Now, if I were sucked into using it because it was the basis of
> > something I couldn't live without, I would learn it and then- well I
> > imagine I would be sitting around one day writing some imap code and
> > it would be like a bolt from the blue: Cells! It sends mail! It lays
> > the chicken _and_ the egg!
>
> Oh, sure, this is not a scoop. I knew on day one people would not get it
> without an application. I just thought a GUI would do it, I am a desktop
> dinosaur.
>
> One person got it pretty quickly because he had been a KR fan (more
> Cells prior art) so he knew the paradigm.
Well- I think you were right about GUIs in a way. Let's put it this
way: the lack of a universal GUI system will be the big problem with
Lisp until one appears. That universal GUI will have almost zero
adoption, and the big problem will move on.
> > Now, to be fair, Kenny set out to create a killer app, or at least a
> > killer lib. A portable GUI library was looking pretty sexy at that
> > time. But there was a bit of GUI muddle at that point, and then it
> > turned out that his gui wasn't very useful for writing reddit (I think
> > it actually made the top 5 things they didn't even mention about why
> > they didn't write reddit in lisp), so...
> Then I started to build Hunch but got exhausted after about ten
> prerequisite libraries. I suppose I should have used ASDF-install. But
> it was not much worse than cl-s3, I'll try again.
Hmm- have you seen http://www.youtube.com/watch?v=VVp8UGjECt4 ? It's
been making the rounds for a while, and I think that url should be the
default response to "if X is so great, why doesn't everyone use it?"
Anyway, choices are bad ;). That said, hunchentoot works well, in my
experience (I assume you mean hunchentoot when you say hunch). It
helps if you have a Debian based system, as you can get most of the
prerequisites through the package system, and then install specific
newer versions by hand. I know that's a bit evil, but it works.
Anyway, if you're having problems installing it, I think that probably
says more about you than about hunchentoot ;).
> Help a dinosaur, people. Will Hunch be like Arc, meaning I can just
> develop on my desktop with that localhost url thingy? Maybe I should do
> that as a retraining exercise so I can find some paying work.
I don't quite know what you mean by that- I haven't used arc.
Hunchentoot is more a toolkit for building webservers than a webserver
(the same could be said of Apache, actually, but it has been built
into a pretty standard system; still, having written some custom
Apache modules the hunchentoot model seems easier to work with). Until
you need the apparatus of a browser you can develop however you wish,
including at the REPL.
Campo wrote:
>>>I were writing a scenegraph API I would definitely look at it, because
>>>I already know how that sort of abstraction can be used in writing
>>>scenegraph APIs.
>>
>>So you /do/ know what Cells does. Hmmm.
>
>
> Well- I know how to use that sort of abstraction in one context (a
> context for which it is particularly well-suited). I can generalize it
> to similar contexts. I can do this because I have seen it similarly
> generalized. The more I have used a particular abstraction, the more
> likely I am to find it applicable to a particular domain. Is that a
> surprise?
Yeah, it sounds like you understand Cells better than I. Except you said
OO was a bigger paradigm shift. OO partitions the flow according to
type <yawn>, dataflow reverses it. Ten more years in the temple for you.
> At the moment the kind
> of state management I need is not easily addressed by existing models,
> and I can't see how Cells would help me. I'm basically building lots
> of state and then tearing it down, over and over- in some cases I am
> doing some ad hoc caching, and I'm hoping that a pattern emerges. At
> any rate, you can feel free to mock me, but I'm not sure that Cells
> would solve my problems- OO doesn't.
We are starting to agree: OO is merely stackable containers for code
which is nice but nothing world-changing. Anywho...
Your inner language prevents you from finding a declarative dataflow
solution: "[I am] basically building lots of state and [I am] then
tearing it down... /I am/ doing some ad hoc caching..."
Me, me, me! Your mindset has you at the center of the algorithm, the
dataflow paradigm forces you to state rules, a process which --- look
just go back and read the bit about my father doing spreadsheet analysis
when spreadsheets were sheets. I have a slide in my Cells talk showing
the pained face of a puppeteer struggling with the strings of the
marionette... I think you'd recognize the feeling.
kenny
ps. That stand up economist was awesome. Thx, never saw that. k
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 1, 8:43 am, Ken Tilton <···········@optonline.net> wrote:
> Campo wrote:
>
> Except you said OO was a bigger paradigm shift.
I didn't say that. I said that I did not think it would be a bigger
paradigm shift. If I had been speaking of the intrinsic merits of the
approaches I would have used the present tense. By using a future
tense I indicated that I do not think it will have as large an impact
on programmers as OO has had. I would yawn if I had not transcended
yawning. All your attention is on Zen- the Tao brushes your shoulder
and you cringe, anticipating the roshi's stick. Well, I honor the
place where your Zen becomes my Tao.
> We are starting to agree: OO is merely stackable containers for code
> which is nice but nothing world-changing. Anywho...
I'm beginning to wonder if anything (continental drift aside) is
really world-changing. The abstractions pile high, but the Tao is low,
like the sea to which all rivers run. Perhaps the root of all evil is
premature abstraction (see Gamma, Vlissides et al)... or perhaps not.
I am but a simple aphorist. Or maybe an anaphorist. Either way. When I
was a child I programmed as a child, and I actually got a lot done
back then. Now I dick around with libraries.
> just go back and read the bit about my father doing spreadsheet analysis
> when spreadsheets were sheets. I have a slide in my Cells talk showing
> the pained face of a puppeteer struggling with the strings of the
> marionette... I think you'd recognize the feeling.
Well- it's a tricky thing. The more you buy in, the more you get
pwned.
> ps. That stand up economist was awesome. Thx, never saw that. k
Yeah, I just liked how he summed up everything in 5 minutes.
Economists are great at that but they aren't usually very funny.
Anyway, I have to wonder- do most abstractions live in the space
between "People are stupid" and "People aren't _that_ stupid"?
Campo wrote:
> On Mar 1, 8:43 am, Ken Tilton <···········@optonline.net> wrote:
>
>>Campo wrote:
>>
>> Except you said OO was a bigger paradigm shift.
>
>
> I didn't say that. I said that I did not think it would be a bigger
> paradigm shift. If I had been speaking of the intrinsic merits of the
> approaches I would have used the present tense. By using a future
> tense I indicated that I do not think it will have as large an impact
> on programmers as OO has had. I would yawn if I had not transcended
> yawning. All your attention is on Zen- the Tao brushes your shoulder
> and you cringe, anticipating the roshi's stick. Well, I honor the
> place where your Zen becomes my Tao.
I know exactly what you said. The translation I did was for the
amplitude-impaired. But that was a nice long paragraph you wrote!
>
>
>>We are starting to agree: OO is merely stackable containers for code
>>which is nice but nothing world-changing. Anywho...
>
>
> I'm beginning to wonder if anything (continental drift aside) is
> really world-changing.
I doubt anything will make software easy.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 1, 2:37 pm, Ken Tilton <···········@optonline.net> wrote:
> Campo wrote:
> > On Mar 1, 8:43 am, Ken Tilton <···········@optonline.net> wrote:
>
> >>Campo wrote:
>
> >> Except you said OO was a bigger paradigm shift.
> > All your attention is on Zen- the Tao brushes your shoulder
> > and you cringe, anticipating the roshi's stick. Well, I honor the
> > place where your Zen becomes my Tao.
>
> I know exactly what you said. The translation I did was for the
> amplitude-impaired. But that was a nice long paragraph you wrote!
>
Thanks! I should point out that obsession with length is a bourgeois
affectation- that's what I tell the ladies, anyway. The real question
is: was my paragraph of sufficient girth?
> I doubt anything will make software easy.
We are led, ineluctably, to Brooks's corollary: there are werewolves.
Campo wrote:
>>I doubt anything will make software easy.
>
>
> We are led, ineluctably, to Brooks's corollary: there are werewolves.
No, Cells and what folks nowadays call functional reactive programming
does constitute a silver bullet, directly addressing what Brooks thought
intractable: complexity arising from the interdependence of a
multiplicity of states.
I would recommend you read the Cells Manifesto where that is covered,
but....
kenny
ps. TISLHFYP
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Mar 1, 6:05 pm, Ken Tilton <···········@optonline.net> wrote:
> Campo wrote:
> >>I doubt anything will make software easy.
>
> > We are led, ineluctably, to Brooks's corollary: there are werewolves.
>
> No, Cells and what folks nowadays call functional reactive programming
> does constitute a silver bullet, directly addressing what Brooks thought
> intractable: complexity arising from the interdependence of a
> multiplicity of states.
>
> I would recommend you read the Cells Manifesto where that is covered,
> but....
>
> kenny
>
> ps. TISLHFYP
"there is so little hope for you pal"
"... yobbo programmers"
"Tilton is Lisp helper for yobbo programmers"
I give up...
Brian Adkins wrote:
> On Mar 1, 6:05 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Campo wrote:
>>
>>>>I doubt anything will make software easy.
>>
>>>We are led, ineluctably, to Brooks's corollary: there are werewolves.
>>
>>No, Cells and what folks nowadays call functional reactive programming
>>does constitute a silver bullet, directly addressing what Brooks thought
>>intractable: complexity arising from the interdependence of a
>>multiplicity of states.
>>
>>I would recommend you read the Cells Manifesto where that is covered,
>>but....
>>
>>kenny
>>
>>ps. TISLHFYP
>
>
> "there is so little hope for you ..."
...people! Hasn't anyone started a reference page for me on Wkipedia?
:)
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
> I doubt it. I did this and no one asked any questions.
>
> http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?...
>
That really is not documentation. Its a collection of scattered code,
comments and advertising.
You should understand that people will not struggle with your stuff
unless you document it properly. The attitude is going to be 'Well if
he doesn't care enough to write it up, why should I waste BPU* time
trying to figure it out?". An undocumented pile of code is not
vapourware but in some ways it is observationally equivalent to it.
If you want Cells to catch on beyond the few staunch believers who are
willing to persevere despite all odds then invest time in writing
Cells up properly. If you want to know what I mean by 'properly' see
my remarks in
http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/26cb4488ac0b69ec/d5f9144257325cbf?hl=en&lnk=gst&q=Tarver#d5f9144257325cbf
Don't be the BiPolar Lisp Programmer who dwells in his own space ;)
http://www.lambdassociates.org/Blog/bipolar.htm
QUOTE
Lisp allows you to just chuck things off so easily, and it is easy to
take this for granted. I saw this 10 years ago when looking for a GUI
to my Lisp (Garnet had just gone West then). No problem, there were 9
different offerings. The trouble was that none of the 9 were properly
documented and none were bug free. Basically each person had
implemented his own solution and it worked for him so that was fine.
This is a BBM attitude; it works for me and I understand it.
UNQUOTE
Mark
* Brain Processing Unit
Mark Tarver wrote:
>>I doubt it. I did this and no one asked any questions.
>>
>>http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?...
>>
>
>
> That really is not documentation. Its a collection of scattered code,
> comments and advertising.
Thanks!
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On 25 Feb, 22:44, Ken Tilton <···········@optonline.net> wrote:
> Mark Tarver wrote:
> >>I doubt it. I did this and no one asked any questions.
>
> >>http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?...
>
> > That really is not documentation. Its a collection of scattered code,
> > comments and advertising.
>
> Thanks!
>
> kenny
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
Well if I didn't think it was worth documenting I would not have
bothered to tell you to document it. Undocumented bad software is no
loss.
Mark
On 25 Feb, 22:44, Ken Tilton <···········@optonline.net> wrote:
> Mark Tarver wrote:
> >>I doubt it. I did this and no one asked any questions.
>
> >>http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?...
>
> > That really is not documentation. Its a collection of scattered code,
> > comments and advertising.
>
> Thanks!
>
> kenny
>
> --http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
OK; one last try. I rarely repeat myself so often but here goes.
I think Cells is interesting and I've been interested in a type secure
version which would interface with Qi. Its obvious to me that
constraint propagation is the way to go with GUILs and you've been
there and done that. This might save me reinventing the wheel.
But the lack of documentation prevents me from making a proper
assessment of Cells. In order to do that I'd have to put in XXX hours
with no predictable end result. Alternatively I can go my own way and
arrive at a predictable place. The first pass may be sub-Cells but
eventually I'll get there. I always do.
Integrating Cells with Qi requires understanding the datatypes
involved,
the selectors, recognisors and constructors and how they work. From
that the type theory of Cells will emerge.
Doing that not only makes Cells type secure, it enormously clarifies
what the system is about. But - no documentation, so nada.
Having Cells properly integrated with Qi might create very potent
system. It would help you blast away the rubble surrounding Theory Y
algebra and generally make your life easier. However no
documentation .... you get the picture.
A lot of open sourcers regard docs as a sort of footnote or aperitif
to
the main business of writing code. This is one reason why so many
apps are in software cemeteries. But as a rule of thumb you should
expect to spend an hour of writing documentation for every hour of
coding you do.
Mark
Mark Tarver wrote:
> On 25 Feb, 22:44, Ken Tilton <···········@optonline.net> wrote:
>
>>Mark Tarver wrote:
>>
>>>>I doubt it. I did this and no one asked any questions.
>>
>>>>http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?...
>>
>>>That really is not documentation. Its a collection of scattered code,
>>>comments and advertising.
>>
>>Thanks!
>>
>>kenny
>>
>>--http://smuglispweeny.blogspot.com/http://www.theoryyalgebra.com/
>>
>>"In the morning, hear the Way;
>> in the evening, die content!"
>> -- Confucius
>
>
> OK; one last try. I rarely repeat myself so often but here goes.
>
> I think Cells is interesting and I've been interested in a type secure
Well here's the problem. You don't seem very strong on types yourself,
so you have no chance of getting any traction with me. Especially now
that you have revealed that your fascination with seeing Cells
documented by me is to avoid work by you. :)
Your first attempt was a ghastly backtrace of a post in which you argued
at length that I should write a research paper before the inetrpreter thru:
<Error: Mark Tarver is not a valid type for recommending academic
pursuits. The valid types are...>
There would be some solace in knowing something deep inside you managed
to throw that error had your upper cortex and/or pushiness not
overridden your sacred type theory and posted anyway as if:
(subtypep 'something-I-disagree-with 'something-I-should-post)
Not.
Now we have you recommending that an application programmer in love with
an untyped language should create documentation that would satisfy a
theoretical computer science type pie in the sky nutjob:
(coerce kenny (type-of marktarver))
-> <Error: Moscow has been destroyed>
This all starts from you thinking I will listen to you because you think
I care if anyone else uses Cells. The bad news being:
(subtypep 'yobbo-abuse 'marketing)
-> nil
Now this is quite a lengthy post I have written here and I *am* trying
to wean myself of c.l.l and I *do* find it irresistible so spare
yourself any repeated effort, I am taking the easy way out with you.
(push marktarver *killfile*)
<Error: memory exhausted>
I'll get more RAM tomorrow.
Peace and good luck with Qi, I am glad to see you gaining traction with
that. (But I suggest you lose the type stuff and pattern matching to
make it more approachable. :))
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
> So you have no chance of getting any traction with me. Especially now
> that you have revealed that your fascination with seeing Cells
> documented by me is to avoid work by you. :)
Anything you do into which you place a lot of effort should be
properly doced if you want people to take an interest in it. Nobody
should be expected to have to doc your work except *you*. From your
perspective it should be for the good of your creation, not me.
> This all starts from you thinking I will listen to you because you think
> I care if anyone else uses Cells. The bad news being:
Well I assumed that since you were recommending Cells on cll, you do
care. However since you don't, then you can ignore my
recommendations. *Nuff said!*
I knew that breaking my rule of not repeating myself was probably a
bad idea.
Mark
On Feb 25, 8:13 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
> > I doubt it. I did this and no one asked any questions.
>
> >http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?...
>
> That really is not documentation. Its a collection of scattered code,
> comments and advertising.
>
> You should understand that people will not struggle with your stuff
> unless you document it properly. The attitude is going to be 'Well if
> he doesn't care enough to write it up, why should I waste BPU* time
> trying to figure it out?". An undocumented pile of code is not
> vapourware but in some ways it is observationally equivalent to it.
>
> If you want Cells to catch on beyond the few staunch believers who are
> willing to persevere despite all odds then invest time in writing
> Cells up properly. If you want to know what I mean by 'properly' see
> my remarks in
>
> http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/26c...
>
> Don't be the BiPolar Lisp Programmer who dwells in his own space ;)http://www.lambdassociates.org/Blog/bipolar.htm
>
> QUOTE
> Lisp allows you to just chuck things off so easily, and it is easy to
> take this for granted. I saw this 10 years ago when looking for a GUI
> to my Lisp (Garnet had just gone West then). No problem, there were 9
> different offerings. The trouble was that none of the 9 were properly
> documented and none were bug free. Basically each person had
> implemented his own solution and it worked for him so that was fine.
> This is a BBM attitude; it works for me and I understand it.
> UNQUOTE
>
> Mark
>
> * Brain Processing Unit
I even invented a term for your remarks. hackbrary, now I'm actively
waiting to catch on
http://tourdelisp.blogspot.com/2008/01/common-lisp-libraries-victims-of-drive.html
2nd Kenny is a real programmers, real programmers don't docuemnt their
code if it was hard to write it should
be hard to understand.
3rd Compared with Quality of Qi docs, most people feel hopeless re
documenting their code.
Slobodan
On 26 Feb, 08:17, Slobodan Blazeski <·················@gmail.com>
wrote:
> On Feb 25, 8:13 pm, Mark Tarver <··········@ukonline.co.uk> wrote:
>
>
>
>
>
> > > I doubt it. I did this and no one asked any questions.
>
> > >http://common-lisp.net/cgi-bin/viewcvs.cgi/cells/cells-manifesto.txt?...
>
> > That really is not documentation. Its a collection of scattered code,
> > comments and advertising.
>
> > You should understand that people will not struggle with your stuff
> > unless you document it properly. The attitude is going to be 'Well if
> > he doesn't care enough to write it up, why should I waste BPU* time
> > trying to figure it out?". An undocumented pile of code is not
> > vapourware but in some ways it is observationally equivalent to it.
>
> > If you want Cells to catch on beyond the few staunch believers who are
> > willing to persevere despite all odds then invest time in writing
> > Cells up properly. If you want to know what I mean by 'properly' see
> > my remarks in
>
> >http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/26c...
>
> > Don't be the BiPolar Lisp Programmer who dwells in his own space ;)http://www.lambdassociates.org/Blog/bipolar.htm
>
> > QUOTE
> > Lisp allows you to just chuck things off so easily, and it is easy to
> > take this for granted. I saw this 10 years ago when looking for a GUI
> > to my Lisp (Garnet had just gone West then). No problem, there were 9
> > different offerings. The trouble was that none of the 9 were properly
> > documented and none were bug free. Basically each person had
> > implemented his own solution and it worked for him so that was fine.
> > This is a BBM attitude; it works for me and I understand it.
> > UNQUOTE
>
> > Mark
>
> > * Brain Processing Unit
>
> I even invented a term for your remarks. hackbrary, now I'm actively
> waiting to catch onhttp://tourdelisp.blogspot.com/2008/01/common-lisp-libraries-victims-...
> 2nd Kenny is a real programmers, real programmers don't docuemnt their
> code if it was hard to write it should
> be hard to understand.
> 3rd Compared with Quality of Qi docs, most people feel hopeless re
> documenting their code.
>
> Slobodan- Hide quoted text -
>
> - Show quoted text -
Good article. I suspect that one reason why Python has done so well
is the provision of standard well-documented libraries where you can
walk into Borders and pick up a guide, download the app and run it out
of the box. Its not functionally better than Lisp, but it makes life
easier for users.
As Richard Gabriel said 'The Right Thing and 2 shillings will buy you
a cup of tea.'
Mark
Ken Tilton <·········@gmail.com> wrote:
+---------------
| John Stoneham wrote:
| > BTW, Arc1 is out
|
| Thx, it will be interesting to see what changed. I am pretty sure
| nothing that would affect me.
+---------------
From <http://arclanguage.org/item?id=2166> and followup comments:
- New tarball: <http://ycombinator.com/arc/arc1.tar>
- New syntax: x.y and x!y as abbreviations for (x y) and (x 'y), resp.
- SUBSEQ changed into CUT, and now takes negative indices.
- Misc. bug fixes, other stuff.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) writes:
> From <http://arclanguage.org/item?id=2166> and followup comments:
> [...]
> - New syntax: x.y and x!y as abbreviations for (x y) and (x 'y), resp.
y.x and y!x would be expected.
myWindow.close <-> (close myWindow)
12!sin <-> (sin 12)
Still, not serrious...
--
__Pascal Bourguignon__ http://www.informatimago.com/
WARNING: This product attracts every other piece of matter in the
universe, including the products of other manufacturers, with a
force proportional to the product of the masses and inversely
proportional to the distance between them.
On Thu, 14 Feb 2008 01:20:25 +0100, Pascal Bourguignon <···@informatimago.com>
tried to confuse everyone with this message:
>····@rpw3.org (Rob Warnock) writes:
>> From <http://arclanguage.org/item?id=2166> and followup comments:
>> [...]
>> - New syntax: x.y and x!y as abbreviations for (x y) and (x 'y), resp.
>
>y.x and y!x would be expected.
>
>myWindow.close <-> (close myWindow)
Good point. That's how Parenscript handles it for example.
Also it seems that in Arc foo.bar.baz translates to (foo bar baz) and so on,
which is even weirder. It almost allows to write code without any parens at
all! Perhaps significant whitespace can be put to good use?
x.y -> (x y)
x. y -> x (y
x .y -> x) y
x . y -> (x . y)
x .. y -> x) (y
mac.when. test . body .`. if.,test. do.,@body
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
On Feb 12, 4:53 pm, danb <·········@gmail.com> wrote:
> > > On Feb 12, 6:12 am, Espen Vestre wrote:
> > > > I don't understand all this hostility to lambda.
> > On Feb 12, 3:17 pm, danb wrote:
> > > The name "lambda" is terrifying to newbies.
> > > "ZOMG, what is that???
>
> On Feb 12, 8:30 am, "Thomas F. Burdick" wrote:
>
> > ("DE-fun?!?! AAAA!"),
>
> I've never heard complaints about defun.
Of course you haven't. See, the problem with DEfun is that it's no
fun (duh!). Obviously not a problem for you since you were no fun to
begin with.
> > Maybe we could rename LOOP to WHEE! as well...
>
> Very entertaining. Are you aware that "loop" is English?
And are you aware that "loop" (a) contains no exciting ! marker, and
(b) not all the world speaks English. Franchement ça fait peur !
> If part of the goal is to intentionally create stumbling
> blocks that weed out less adept individuals, then "lambda"
> is fine.
Hello? Did I not just suggest "KITTEHS!" ? What could be more
friendly than that? Okay, they do tend to get underfoot and cause
stumbling, but really ... if someone is so scared by the KITTEHS!
special form that they don't keep reading to find out that it creates
an anonymous function ... what hope do they have with CAR (lookout!
BEEEP! *swerve*)
> Haskell seems ideal for that purpose. I'm not
> even saying that doesn't have its merits. The more I hang
> out here, learn Lisp, and hear about patterns in the Java
> community, the more I see how one might want to discourage
> people who really would hurt themselves using Lisp.
Ha ha, this one time I was using MCL and cut myself on the coral,
lol. It's sharp!
> Person-
> ally, I'd rather do user filtering in a more substantive way,
> by adding features to the language that intimidate noobs
> because the features are so abstract (but not gratuitous),
> instead of because their names are greek. "lambda" is
> gratuitous obfuscation, and it doesn't even reduce the
> character count.
chui dak c ça ki kmt avan tut, mé on le lS tomB jusqu'à la prochN
noobsday, caV ? MDR A+
Thomas
From: Espen Vestre
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m13arycahm.fsf@gazonk.netfonds.no>
danb <·········@gmail.com> writes:
> On Feb 12, 6:12 am, Espen Vestre <·····@vestre.net> wrote:
>> I don't understand all this hostility to lambda.
>
> The name "lambda" is terrifying to newbies.
Then they need a psychologist, not a different language.
Or maybe they should simply learn perl first?
--
(espen)
From: Joost Diepenmaat
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <87bq6mkl58.fsf@zeekat.nl>
danb <·········@gmail.com> writes:
> The name "lambda" is terrifying to newbies. "ZOMG, what
> is that??? You mean it's not a regular function? I can
> hardly understand macros and now there's a THIRD kind of
> function-like thingy? With a name from a language I don't
> even know, this must be some kind of bizarre hyper-function
> or something!"
I know you're (probably) joking, but my main issue with lambda is that
it's IMHO very hard to type on a QWERTY keyboard. Plus, for such an
important and much used feature the name is arguably too long anyway. I
mean, we've got CAR and CDR, I'd go with FUN or even LMB. I don't even
care that much about readability for something so fundamental. (As I
said before, I really like Arc's "fn")
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
> danb <·········@gmail.com> writes:
> > The name "lambda" is terrifying to newbies. "ZOMG, what
> > is that??? You mean it's not a regular function? ...
Joost Diepenmaat <·····@zeekat.nl> wrote:
> I know you're (probably) joking,
Not at all. I'm dramatizing, but I've seen several instances
of beginners assuming that anything with such a long foreign
name must have some complex, obtuse meaning. It can be hard
to unfreeze their minds long enough to explain that it's just
a function, with maybe a variable or two thrown in from the
surrounding scope. The same thing happens with monads.
Newbies freak out just because of the name.
> for such an important and much used feature the name is
> arguably too long
Exactly, plus it's unfamiliar to many non-mathematicians.
> we've got CAR and CDR,
Not to mention CADR, CDDR, CDAR, etc..
> I'd go with FUN or even LMB.
I'm with you on FUN (ML) but not LMB (obfuscated).
> I really like Arc's "fn"
Even better than FUN, IMHO. My preference would be
FN (short) or FUNC (mnemonic).
--Dan
www.prairienet.org/~dsb/
Joost Diepenmaat <·····@zeekat.nl> writes:
> danb <·········@gmail.com> writes:
>> The name "lambda" is terrifying to newbies. "ZOMG, what
>> is that??? You mean it's not a regular function? I can
>> hardly understand macros and now there's a THIRD kind of
>> function-like thingy? With a name from a language I don't
>> even know, this must be some kind of bizarre hyper-function
>> or something!"
>
> I know you're (probably) joking, but my main issue with lambda is that
> it's IMHO very hard to type on a QWERTY keyboard. Plus, for such an
> important and much used feature the name is arguably too long anyway. I
> mean, we've got CAR and CDR, I'd go with FUN or even LMB. I don't even
> care that much about readability for something so fundamental. (As I
> said before, I really like Arc's "fn")
Yep. I know a lot of words that are very hard to type on a QWERTY
keyboard. Just put the following in your ~/.emacs:
(global-set-key (kbd "A-q") (lambda () (interactive) (insert "(CONS "))))
(global-set-key (kbd "A-w") (lambda () (interactive) (insert "(CAR "))))
(global-set-key (kbd "A-e") (lambda () (interactive) (insert "(CDR "))))
(global-set-key (kbd "A-r") (lambda () (interactive) (insert "(NULL "))))
...
(global-set-key (kbd "S-A-q") (lambda () (interactive) (insert "(MULTIPLE-VALUE-BIND "))))
(global-set-key (kbd "S-A-w") (lambda () (interactive) (insert "(RANDOM "))))
(global-set-key (kbd "S-A-e") (lambda () (interactive) (insert "(DEFINE-CONDITION "))))
(global-set-key (kbd "S-A-r") (lambda () (interactive) (insert "(WITH-OUTPUT-TO-STRING "))))
...
like on the old ZX80...
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
From: Joost Diepenmaat
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <87myq5kh9x.fsf@zeekat.nl>
Pascal Bourguignon <···@informatimago.com> writes:
> Yep. I know a lot of words that are very hard to type on a QWERTY
> keyboard. Just put the following in your ~/.emacs:
>
> (global-set-key (kbd "A-q") (lambda () (interactive) (insert "(CONS "))))
[...]
Getting off-topic, but which key is the "A" modifier? I already use C, M
and S, and for some reason the "windows menu key" seems to be bound to
"M-x" by default.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Joost Diepenmaat <·····@zeekat.nl> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> Yep. I know a lot of words that are very hard to type on a QWERTY
>> keyboard. Just put the following in your ~/.emacs:
>>
>> (global-set-key (kbd "A-q") (lambda () (interactive) (insert "(CONS "))))
> [...]
>
> Getting off-topic, but which key is the "A" modifier? I already use C, M
> and S, and for some reason the "windows menu key" seems to be bound to
> "M-x" by default.
A- Alt
C- Control
M- Meta
H- Hyper
S- Shift
s- super
Once upon a time (on the Space Cadet Keyboard
http://en.wikipedia.org/wiki/Space-cadet_keyboard), there was also:
T- Top
F- Front
Note that on that keyboard, λ was F-l
--
__Pascal Bourguignon__ http://www.informatimago.com/
READ THIS BEFORE OPENING PACKAGE: According to certain suggested
versions of the Grand Unified Theory, the primary particles
constituting this product may decay to nothingness within the next
four hundred million years.
From: Joost Diepenmaat
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <87ir0tkf5c.fsf@zeekat.nl>
Pascal Bourguignon <···@informatimago.com> writes:
> Once upon a time (on the Space Cadet Keyboard
> http://en.wikipedia.org/wiki/Space-cadet_keyboard), there was also:
>
> T- Top
> F- Front
>
> Note that on that keyboard, λ was F-l
Ah yes, I thought there was a "greek" key on that. Seems I was right.
Time to mess with my keymaps...
Thanks,
Joost.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
On Tue, 12 Feb 2008 20:52:19 +0100, Joost Diepenmaat <·····@zeekat.nl>
wrote:
>my main issue with lambda is that
>it's IMHO very hard to type on a QWERTY keyboard. Plus, for such an
>important and much used feature the name is arguably too long anyway. I
>mean, we've got CAR and CDR, I'd go with FUN or even LMB. I don't even
>care that much about readability for something so fundamental. (As I
>said before, I really like Arc's "fn")
Then why not write an "fn" macro?
George
--
for email reply remove "/" from address
From: Joost Diepenmaat
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <87k5l8mrdb.fsf@zeekat.nl>
George Neuner <·········@/comcast.net> writes:
> Then why not write an "fn" macro?
Sure I can work around it, and I probably will use a "fn" macro in the
future, but the point I was trying to make is that "lambda" is just an
unfortunate choice for a *very prominent* keyword.
If I used some-obscure-and-very-long-name a lot in some section of code,
I would write a macro and not think about it twice, but having to write a
macro just to change the name of something so ubiquitous smells of a bad
design choice, since I'd use it everywhere.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
From: Damien Kick
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <13reuk8akektj0f@corp.supernews.com>
Joost Diepenmaat wrote:
> George Neuner <·········@/comcast.net> writes:
>
>> Then why not write an "fn" macro?
>
> Sure I can work around it, and I probably will use a "fn" macro in the
> future, but the point I was trying to make is that "lambda" is just an
> unfortunate choice for a *very prominent* keyword.
>
> If I used some-obscure-and-very-long-name a lot in some section of code,
> I would write a macro and not think about it twice, but having to write a
> macro just to change the name of something so ubiquitous smells of a bad
> design choice, since I'd use it everywhere.
Indeed, I want my code to read like a text message from one of my
thirteen year old cousins. I've always been suspicious of people who
use big words, anyway. Think about how much more efficient public
debate has become since we've introduced sound bites and message
advertisements. I'm sorry, ads. Any concept fundamental to a system of
thought is best conveyed in a staccato rhythm of short syllables, much
like the quacking of a duck.
Hell, even "lambda calculus" has the fussy sound of having come from the
liberal elite. That's five syllables to name something which was meant
to explain the underpinning of logical thought. And who does that,
anyway? I got the underpinning of logical thought for ya', right here.
My fist and your face. Argue with that, egg head. Oh, and that
stupid "amb da" part. Hard to say. Should have just been "da
calculus". Kinda like "da Bears".[1] Makes a nice short name, too.
(funcall (da (x) (dwim x)))
What function? Da function. It ain't got no name. It's just da
function. What are you, some kind of commie? Oh, and funcall. What
kind of name is that? I just want it to do something.
(do (da (x) (dwim x)))
Just do da thing, you know what I mean, Poindexter? Now that's progress.
[1] Can you tell I live in Chicago?
On Feb 16, 7:06 pm, Damien Kick <·····@earthlink.net> wrote:
> Joost Diepenmaat wrote:
> > George Neuner <·········@/comcast.net> writes:
>
> >> Then why not write an "fn" macro?
>
> > Sure I can work around it, and I probably will use a "fn" macro in the
> > future, but the point I was trying to make is that "lambda" is just an
> > unfortunate choice for a *very prominent* keyword.
>
> > If I used some-obscure-and-very-long-name a lot in some section of code,
> > I would write a macro and not think about it twice, but having to write a
> > macro just to change the name of something so ubiquitous smells of a bad
> > design choice, since I'd use it everywhere.
>
> Indeed, I want my code to read like a text message from one of my
> thirteen year old cousins. I've always been suspicious of people who
> use big words, anyway. Think about how much more efficient public
> debate has become since we've introduced sound bites and message
> advertisements. I'm sorry, ads. Any concept fundamental to a system of
> thought is best conveyed in a staccato rhythm of short syllables, much
> like the quacking of a duck.
>
> Hell, even "lambda calculus" has the fussy sound of having come from the
> liberal elite. That's five syllables to name something which was meant
> to explain the underpinning of logical thought. And who does that,
> anyway? I got the underpinning of logical thought for ya', right here.
> My fist and your face. Argue with that, egg head. Oh, and that
> stupid "amb da" part. Hard to say. Should have just been "da
> calculus". Kinda like "da Bears".[1] Makes a nice short name, too.
>
> (funcall (da (x) (dwim x)))
>
> What function? Da function. It ain't got no name. It's just da
> function. What are you, some kind of commie? Oh, and funcall. What
> kind of name is that? I just want it to do something.
>
> (do (da (x) (dwim x)))
>
> Just do da thing, you know what I mean, Poindexter? Now that's progress.
>
> [1] Can you tell I live in Chicago?
Looks like we got a "n00b" here.
http://steve-yegge.blogspot.com/2008/02/portrait-of-n00b.html
Steve Yegge argues that the explicit statement of intent all the time
is one of the hallmarks of a newbie programmer.
"In the old days, seeing too much code at once quite frankly exceeded
my complexity threshold, and when I had to work with it I'd typically
try to rewrite it or at least comment it heavily. Today, however, I
just slog through it without complaining (much). When I have a
specific goal in mind and a complicated piece of code to write, I
spend my time making it happen rather than telling myself stories
about it."
Having unnecessarily large function names is definitly a step toward
the "telling youself stories" about your code, rather than actually
writing code.
From: Damien Kick
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <13rk2l8fimketce@corp.supernews.com>
···········@gmail.com wrote:
> Having unnecessarily large function names is definitly a step toward
> the "telling youself stories" about your code, rather than actually
> writing code.
Besides, real programmers write machine code in hex notation. Fortran
is for quiche eaters.
On 2008-02-16 19:06:32 -0500, Damien Kick <·····@earthlink.net> said:
> Any concept fundamental to a system of thought is best conveyed in a
> staccato rhythm of short syllables, much like the quacking of a duck.
>
> Hell, even "lambda calculus" has the fussy sound of having come from
> the liberal elite. That's five syllables to name something which was
> meant to explain the underpinning of logical thought. And who does
> that, anyway? I got the underpinning of logical thought for ya', right
> here. My fist and your face. Argue with that, egg head. Oh, and
> that stupid "amb da" part. Hard to say. Should have just been "da
> calculus". Kinda like "da Bears".[1]
nail on the head, and very funny as well.
From: Joost Diepenmaat
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <87skzs2zha.fsf@zeekat.nl>
Damien Kick <·····@earthlink.net> writes:
> Indeed, I want my code to read like a text message from one of my
> thirteen year old cousins. I've always been suspicious of people who
> use big words, anyway. Think about how much more efficient public
> debate has become since we've introduced sound bites and message
> advertisements. I'm sorry, ads. Any concept fundamental to a system
> of thought is best conveyed in a staccato rhythm of short syllables,
> much like the quacking of a duck.
There are two points to consider here:
Readability: long/explicit names for functions can make the intent of
the code clearer. On the other hand, short - even "obfuscated" names for
often used functions can make the code easier to scan. A minimal amount
of knowledge of the language - or the project and its programming style
- can be supposed.
Ease of use: I use lambda a *lot*. I suspect I'm not alone in that. If I
had to use "compute-applicable-methods" as much as I did lambda, I'd run
away screaming. Or write a short alias.
> Hell, even "lambda calculus" has the fussy sound of having come from
> the liberal elite. That's five syllables to name something which was
> meant to explain the underpinning of logical thought. And who does
> that, anyway? I got the underpinning of logical thought for ya',
> right here. My fist and your face. Argue with that, egg head. Oh,
> and that stupid "amb da" part. Hard to say. Should have just been
> "da calculus". Kinda like "da Bears".[1] Makes a nice short name,
> too.
I don't care where it's coming from. It could be called /. for all I
care (as has been suggested in this thread). Except that /. is much
easier to type.
> (funcall (da (x) (dwim x)))
>
> What function? Da function. It ain't got no name. It's just da
> function. What are you, some kind of commie? Oh, and funcall. What
> kind of name is that? I just want it to do something.
>
> (do (da (x) (dwim x)))
>
> Just do da thing, you know what I mean, Poindexter? Now that's progress.
(call) would be fine by me.
> [1] Can you tell I live in Chicago?
Not really. But then, I'm one of those european types.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
Joost Diepenmaat <·····@zeekat.nl> wrote:
+---------------
| I don't care where it's coming from. It could be called /. for all I
| care (as has been suggested in this thread). Except that /. is much
| easier to type.
+---------------
Oh, dear. ISTR "suggesting" it, but the intention was sarcastic,
which seems to have been taken seriously. (Ouch!) Personally,
I *greatly* prefer "FN" to "/.", both to type (faster, two hands)
and to read. Besides, the Slashdot guys already have a claim on "/.".
-Rob
p.s. FWIW, my "P'Lite Scheme" infix hack (circa 1996) used "FN":
plite> def fact = fn x in if x < 2 then 1 else x * [fact x - 1]
fact
plite> fact 5
120
plite>
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Feb 16, 10:44 pm, ····@rpw3.org (Rob Warnock) wrote:
> the Slashdot guys already have a claim on "/.".
Not to mention ML. I've been using /. and /_ for
float @ / and floor @ / respectively.
--Dan
www.prairienet.org/~dsb/
From: Joost Diepenmaat
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <87mypzn3t3.fsf@zeekat.nl>
····@rpw3.org (Rob Warnock) writes:
> Joost Diepenmaat <·····@zeekat.nl> wrote:
> +---------------
> | I don't care where it's coming from. It could be called /. for all I
> | care (as has been suggested in this thread). Except that /. is much
> | easier to type.
> +---------------
>
> Oh, dear. ISTR "suggesting" it, but the intention was sarcastic,
> which seems to have been taken seriously. (Ouch!) Personally,
> I *greatly* prefer "FN" to "/.", both to type (faster, two hands)
> and to read. Besides, the Slashdot guys already have a claim on "/.".
I know it wan't a serious suggestion, but it does have a kind of
perverse charm. I was just stressing that my "dislike" of "lambda" has
nothing to do with it being some kind of elitist, difficult word.
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
From: Damien Kick
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <13rk2boep0d4g10@corp.supernews.com>
Joost Diepenmaat wrote:
> There are two points to consider here:
>
> Readability: long/explicit names for functions can make the intent of
> the code clearer. On the other hand, short - even "obfuscated" names for
> often used functions can make the code easier to scan. A minimal amount
> of knowledge of the language - or the project and its programming style
> - can be supposed.
What do you mean by "making the code easier to scan?" Surely the
computational complexity involved in lexical analysis of a token is not
significantly increased by the length of the token involved. And, in
Lisp especially, after the reader has finished with a string, we're only
left with symbols anyway, which we can test for equality with EQ.
; SLIME 2006-04-20
CL-USER> (defun foo ()
(read-from-string "cam"))
FOO
CL-USER> (compile 'foo)
FOO
NIL
NIL
CL-USER> (defun bar ()
(read-from-string "compute-applicable-methods"))
BAR
CL-USER> (compile 'bar)
BAR
NIL
NIL
CL-USER> (defun baz ()
(read-from-string
"compute-the-applicable-methods-from-the-types-of-the-arguments-which-would-be-passed-to-the-generic-function-at-run-time"))
BAZ
CL-USER> (compile 'baz)
BAZ
NIL
NIL
CL-USER> (time (foo))
; cpu time (non-gc) 0 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 0 msec user, 0 msec system
; real time 0 msec
; space allocation:
; 26 cons cells, 320 other bytes, 0 static bytes
CAM
3
CL-USER> (time (bar))
; cpu time (non-gc) 0 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 0 msec user, 0 msec system
; real time 0 msec
; space allocation:
; 2 cons cells, 0 other bytes, 0 static bytes
COMPUTE-APPLICABLE-METHODS
26
CL-USER> (time (baz))
; cpu time (non-gc) 0 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 0 msec user, 0 msec system
; real time 1 msec
; space allocation:
; 2 cons cells, 320 other bytes, 0 static bytes
COMPUTE-THE-APPLICABLE-METHODS-FROM-THE-TYPES-OF-THE-ARGUMENTS-WHICH-WOULD-BE-PASSED-TO-THE-GENERIC-FUNCTION-AT-RUN-TIME
120
CL-USER> (defun qux ()
(read-from-string (make-string 4096 :initial-element #\x)))
QUX
CL-USER> (compile 'qux)
QUX
NIL
NIL
CL-USER> (time (qux))
; cpu time (non-gc) 0 msec user, 0 msec system
; cpu time (gc) 0 msec user, 0 msec system
; cpu time (total) 0 msec user, 0 msec system
; real time 2 msec
; space allocation:
; 2 cons cells, 38,136 other bytes, 0 static bytes
XXXXXXXX [...]
4096
CL-USER>
So, yes, QUX took 2 milliseconds instead of 1 millisecond for FOO, BAR,
and BAZ. Perhaps "scanning" a 4096 character long symbol can make a
measurable difference. Now, I could see whining about a name like
something from BAZ, but when we're talking about a difference of four
characters between LAMBDA and FN, I just can't believe that people are
seriously considering such a thing to be an issue.
I watch my niece, who is just learning to read, trace her finger along
with each individual letter of a word while she tries to form the sounds
for it. But for quite some time after such a young age, I find that
something along the pathway from my eyes to my brain will even helpfully
correct spelling mistakes in words for me such that I have a hard time
seeing the actual mistake on the page. I have absolutely no conscious
thought of there being anything like "scanning" involved. Again, I
can't believe that anyone would seriously argue that our mental
apparatus gets bogged down by "scanning" the tokens. The longest symbol
in the COMMON-LISP package is 38 characters long, at least according to
CL-USER> (loop for s being each present-symbol of :cl
maximize (length (symbol-name s)))
38
CL-USER> (loop for s being each present-symbol of :cl
when (= (length (symbol-name s)) 38)
collect s)
(LEAST-POSITIVE-NORMALIZED-DOUBLE-FLOAT
LEAST-NEGATIVE-NORMALIZED-SINGLE-FLOAT
LEAST-NEGATIVE-NORMALIZED-DOUBLE-FLOAT
LEAST-POSITIVE-NORMALIZED-SINGLE-FLOAT)
CL-USER>
If anyone would actually claim to have a difficult time "scanning" these
phrases, I would seriously doubt that they could read at a level would
be required to have been educating to the point to be able to understand
the concept of a least positive normalized double float in the first
place. And I seriously doubt that probably as high a percentage of 99%
of the people making pop physiology arguments have the slightest idea of
that on which they are basing their arguments. Which is, I suppose, why
it is "pop" physiology. However, since we're already in that water, I
might as well splash around a little bit, too. Given how difficult a
time most people seem to have finding typos, given the unconscious
behavior of seeing what one expects to find on the page instead of that
which is really on the page, I would expect that compacting information
into less characters actually makes it harder to scan. It requires that
the reader basically be constantly on the alert for significant typos.
Of course, I am far from an expert on the cognitive functions involved
in turning glyphs on a page or screen into thoughts and meaning. I
going to go out on a limb and guess that neither do you, Joost. My
apologies if this just happens to have been the topic of your doctorate
thesis.
> Ease of use: I use lambda a *lot*. I suspect I'm not alone in that. If I
> had to use "compute-applicable-methods" as much as I did lambda, I'd run
> away screaming. Or write a short alias.
"c-a-m C-c M-i" works just fine for me. I have a feeling that the
majority of people who like to complain about long names use deficient
text editors. I wonder what Paul Graham's favorite editor is.
> I don't care where it's coming from. It could be called /. for all I
> care (as has been suggested in this thread). Except that /. is much
> easier to type.
I tend to like my names to "come from" somewhere. I find it helps
associate the name with the concept. What I type into the editor, on
the other hand, I like to have it associated with the muscle memory of
my fingers. Personally, I've never even paused to consider typing
(lambda (x) (...)) to be an issue but if I did I would've probably
defined an abbreviation in Emacs for "/." to insert "(lambda (x) ())",
leaving point inside the body of the lambda form. Lisp is already a
language for which one needs an editor which will help the programmer
write her code. I can't imagine trying to write Lisp without some kind
of parentheses matching capability.
On Mon, 18 Feb 2008, Damien Kick wrote:
> my fingers. Personally, I've never even paused to consider typing
> (lambda (x) (...)) to be an issue but if I did I would've probably
> defined an abbreviation in Emacs for "/." to insert "(lambda (x) ())",
> leaving point inside the body of the lambda form. Lisp is already a
Yes, _writing_ lambda is of course not an issue. Reading it, however, can
be. I very often write macros where functions which takes
other functions as arguments would do instead:
(defun when2 (cond then)
(if cond (funcall then)))
(when2 a #'(lambda () b))
vs.
(defmacro when3 (cond &rest rest)
`(cond (,cond ,@rest)))
(when3 a b)
I like the first one because its more explicit
about whats happening and because its easier to debug
a program when only using functions (at least in scheme),
but I still end up writing the macro version instead
only because "(when a b)" is faster to read
than "(when a #'(lambda () b))".
(Hmm, I think maybe the next common lisp should have
optional lazy evaluation for function arguments...)
From: Damien Kick
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <13rkkes9mh2av5a@corp.supernews.com>
Kjetil S. Matheussen wrote:
> [...] I still end up writing the macro version instead
> only because "(when a b)" is faster to read
> than "(when a #'(lambda () b))".
Really? Faster to read. If you sat down with a stop watch and actually
timed yourself, how long do you think it would take you to read either
form. What is the speed advantage of the first form? What are you
shaving off your read time? The first form takes you only five seconds
while the second takes all of twenty seconds? I'm only kidding, though.
Surely you don't read that slowly. The macro form takes only one
second while the lambda form takes all of two seconds? If you write all
of your code in the first form, you can go home a full hour and a half
hour sooner because you've shaved off all that unnecessary time reading
that cumbersome lambda form. Maybe if you remove the speed bump of #',
you could go home an hour earlier.
Really?
I can fully understand that people have personal preferences. Some
people like short pithy names or just plain hate vowels, but even Ken
Thompson admits that if he had to do it over all again, he would've
spelled creat with the 'e'. Some people like long names which almost
read like sentence fragments. But I really can't stand having to sit
through code reviews in which people try and explain their purely
subjective preferences with these bullshit pseudo-objective
justifications like "it is faster to read."
I like (when a b) better, too. But that's because I already know that
WHEN does not FUNCALL it's second argument. My difficulty in reading
the one over the other has nothing to do with laboring over all those
extra characters. (Honey, I'm going to have to stay late at work
tonight. I'm having a hard time reading all those damn lambda forms.
If only the designers of Common Lisp had used something four characters
shorter!) It's trying to figure out why you wrote (when a #'(lambda ()
b)) as an alternative to (when a b) instead of (when a (funcall
#'(lambda () b))). In other words, WHEN is a bad example because it's
semantics are already defined. If you happen to be writing something
with the semantics of a WHEN, i.e. introducing syntax for a new control
structure, perhaps a macro is the best way to write it because of purely
semantic reasons.
And if every Lisp operator was defined to take an anonymous function
which would be FUNCALLed, I would probably find it annoying to have to
use LAMBDA everywhere, too.
CL-USER> (defun when* (test value)
(when (funcall test)
(funcall value)))
WHEN*
CL-USER> (when* #'(lambda () (< 13 69))
#'(lambda () :is-less-than))
:IS-LESS-THAN
CL-USER>
If every Lisp operator was defined like this hypothetical WHEN*
function, then all of those LAMBDAs everywhere would get to be truly
annoying. But that would have nothing to do with the word LAMBDA. It
would have everything to do with unnecessarily having to wrap everything
into an anonymous function, regardless of the syntax used for it.
On Mon, 18 Feb 2008, Damien Kick wrote:
> Kjetil S. Matheussen wrote:
>
> > [...] I still end up writing the macro version instead
> > only because "(when a b)" is faster to read
> > than "(when a #'(lambda () b))".
>
> Really? Faster to read. If you sat down with a stop watch and actually
> timed yourself, how long do you think it would take you to read either
> form.
Its faster to read because its less messy, not because the time
looking at each token takes very much time. Guess I should
have written faster to understand instead of faster to read,
altough it should be obvious.
On Feb 19, 7:32 am, "Kjetil S. Matheussen" <··············@notam02.no>
wrote:
> On Mon, 18 Feb 2008, Damien Kick wrote:
> > Kjetil S. Matheussen wrote:
>
> > > [...] I still end up writing the macro version instead
> > > only because "(when a b)" is faster to read
> > > than "(when a #'(lambda () b))".
>
> > Really? Faster to read. If you sat down with a stop watch and actually
> > timed yourself, how long do you think it would take you to read either
> > form.
>
> Its faster to read because its less messy, not because the time
> looking at each token takes very much time. [...]
So one would look at each token in about the same time and then our
mental processes are supposed to get bogged down because of all the
extra "mess". What is this mess to which you're referring exactly?
Certinaly it can't be typographical messiness because you just agreed
that it would not take very much time to look at each token, whatever
a token is in this context. If we're writing a compiler, certainly
there are tokens. Are you so sure that your mental processes involve
something called tokens? Where does a token live in the brain,
exactly? And if the messiness isn't something more or less
typographical, if it is somehow semantic, why in the world would it
make any difference to use a word other than LAMBDA to try and clean
up the mess? Can't have it both ways.
Less messy. Cleaner. More readable. This is all still bullshit hand
waving to try and avoid just coming right out and saying, "I like it
better." Not because it's faster by any standard measure of time or
has been found to be so by any kind of repeatable experiment conducted
on a random sample of a relavent population or by anything even
remotely approaching so much as a pseudo-objective measure of
"goodness" or "lack of messiness". You just like it better. That's
fine. I happen to like the word LAMBDA because I like the association
with the intellectual history that gave birth to its use in Lisp. Not
for the CADDR of a WHEN form, though. But that doesn't mean that my
code, which uses LAMBDA, is "slower to read" or is somehow "messier".
I completely agree with you, though, when you write in another post in
this thread that
> Hmm, I wonder if this, eh, dilemma can be solved just by using a
> more intelligent text editor
I share this intution that a large part of this endless religious war
between those who hate vowels and those who love them should be solved
as a problem of customizing the display of a piece of code. I'd
posted something similiar previously <http://tinyurl.com/2trqta> and
Ray Dillinger had pointed out what he thought was a problem with the
idea <http://tinyurl.com/2rxqnd>. I haven't actually heard of a
system which customizes things like the displaying the names of the
symbols used according to user preference.
> [...] Guess I should
> have written faster to understand instead of faster to read,
> altough it should be obvious.
I don't think it is obvious at all. When I talk about having read
something, I tend to assume that people will understand that I've read
that something and understood at least some significant portion of
that something. Perhaps I will not have understood some "deeper"
meaning but I would be able to answer at least basic questions about
it. Conversely, when I ask someone if they read a book, if they say
yes, I generally tend to imagine that they took some time to map the
glyphs to some kind of meaning. Unless, for example, I'm talking to
my four year old niece, in which case it seems that she is still
tetering on the edge of considering the act of reading to be the act
of tracing her finger under the words on the page.
On Feb 19, 10:58 pm, dkixk <······@gmail.com> wrote:
> On Feb 19, 7:32 am, "Kjetil S. Matheussen" <··············@notam02.no>
> wrote:
>
> > On Mon, 18 Feb 2008, Damien Kick wrote:
> > > Kjetil S. Matheussen wrote:
>
> > > > [...] I still end up writing the macro version instead
> > > > only because "(when a b)" is faster to read
> > > > than "(when a #'(lambda () b))".
>
> > > Really? Faster to read. If you sat down with a stop watch and actually
> > > timed yourself, how long do you think it would take you to read either
> > > form.
>
> > Its faster to read because its less messy, not because the time
> > looking at each token takes very much time. [...]
>
> So one would look at each token in about the same time and then our
> mental processes are supposed to get bogged down because of all the
> extra "mess". What is this mess to which you're referring exactly?
> Certinaly it can't be typographical messiness because you just agreed
> that it would not take very much time to look at each token, whatever
> a token is in this context. If we're writing a compiler, certainly
> there are tokens. Are you so sure that your mental processes involve
> something called tokens? Where does a token live in the brain,
> exactly? And if the messiness isn't something more or less
> typographical, if it is somehow semantic, why in the world would it
> make any difference to use a word other than LAMBDA to try and clean
> up the mess? Can't have it both ways.
>
> Less messy. Cleaner. More readable. This is all still bullshit hand
> waving to try and avoid just coming right out and saying, "I like it
> better." Not because it's faster by any standard measure of time or
> has been found to be so by any kind of repeatable experiment conducted
> on a random sample of a relavent population or by anything even
> remotely approaching so much as a pseudo-objective measure of
> "goodness" or "lack of messiness". You just like it better. That's
> fine. I happen to like the word LAMBDA because I like the association
> with the intellectual history that gave birth to its use in Lisp. Not
> for the CADDR of a WHEN form, though. But that doesn't mean that my
> code, which uses LAMBDA, is "slower to read" or is somehow "messier".
In a round-a-bout way I think you have hit the nail right on the head,
except you are wrong. Of course the mess that he was referring to in
the second example is everything that is not in the first example. It
is a mess because it has nothing to do with the task at hand. In
fact, the #' syntax is a leaky abstraction. It is a piece of the
underlying implementation of a lisp-2 that is bubbling up into the
programmers point of view, and it is necessary to talk to the
compiler. Liking lambda's for historical reasons is quaint, but we
are talking about how to improve a programming language, not how to
hold them back for historical warm fuzzies. In this case, the goal is
to find the most efficient way to translate ideas in our head into a
language that both people and computers can understand.
As for goodness and testing on populations. You can find lots of work
which looks at library design, and it's quite clear that the fewer
concepts that must be dealt with by a library user to achieve the
exact same functionality the better. Concepts are represented by
groups of neural columns in your cerebral cortex, and you only have a
finite amount of attention to which you can give each one. Minimizing
the attention which is spent on concepts not directly leading to the
implementation of the ideas in your head is smart. It leaves as much
attention as possible for the primary task at hand.
> I completely agree with you, though, when you write in another post in
> this thread that
>
> > Hmm, I wonder if this, eh, dilemma can be solved just by using a
> > more intelligent text editor
>
> I share this intution that a large part of this endless religious war
> between those who hate vowels and those who love them should be solved
> as a problem of customizing the display of a piece of code. I'd
> posted something similiar previously <http://tinyurl.com/2trqta> and
> Ray Dillinger had pointed out what he thought was a problem with the
> idea <http://tinyurl.com/2rxqnd>. I haven't actually heard of a
> system which customizes things like the displaying the names of the
> symbols used according to user preference.
I'm sorry, but I completely disagree yet again. If you are automating
the generation of text which is going to be splatted into your
programs then you are forcing any future readers of that text to
actually deal with the splatted stuff rather than the nice concise
thing you actually input. When you read any words or groupings of
words for the first time you have to parse them piece by piece to map
them to their meaning. After having seen the same words or groupings
over and over your brain actually learns to recognize them as a single
unit, which lets you read and understand their meaning in much less
time. It is a bad idea if everyone is looking at things in different
ways, and depending on what editor, or browser or mail reader you are
looking at things look different. Methods that are used often should
have short names because you will type them often and remember them
anyway, while methods which are used less should have more descriptive
names to remind the user of their meaning. Look at Ruby for a very
well done standard library that uses clear names which are
considerably shorter than what common-lisp has.
-Jeff
From: Damien Kick
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <13rngq1p16tri4d@corp.supernews.com>
Jeff wrote:
>>> On Mon, 18 Feb 2008, Damien Kick wrote:
>>>> Kjetil S. Matheussen wrote:
>>>>> [...] I still end up writing the macro version instead
>>>>> only because "(when a b)" is faster to read
>>>>> than "(when a #'(lambda () b))".
>>>>
>>>> Really? Faster to read. If you sat down with a stop watch and actually
>>>> timed yourself, how long do you think it would take you to read either
>>>> form.
>
> In a round-a-bout way I think you have hit the nail right on the head,
> except you are wrong. [...]
So wouldn't that be hitting the nail right on the point?
> Of course the mess that he was referring to in
> the second example is everything that is not in the first example. It
> is a mess because it has nothing to do with the task at hand. In
> fact, the #' syntax is a leaky abstraction. It is a piece of the
> underlying implementation of a lisp-2 that is bubbling up into the
> programmers point of view, and it is necessary to talk to the
> compiler.
I agree that the mess in the second example has everything to do with
its not being related to the task at hand. But why do you think that
syntax is to blame for that? Is it somehow less of a leaky abstraction
to write (lambda () b) instead of #'(lambda () b) because it has two
less characters? The mismatch is semantic, not syntactic.
(when a (fn () b))
Would be no better. And, if I recall one of Kent's posts correctly, one
of the advantages of Lisp-2 as a syntax is that it works well in
situations in which ones does not expect everything to be passed as a
function argument. (lambda (f) (funcall f *x*)) brings attention to the
fact that something "different is happening".
> Liking lambda's for historical reasons is quaint, but we
> are talking about how to improve a programming language, not how to
> hold them back for historical warm fuzzies. In this case, the goal is
> to find the most efficient way to translate ideas in our head into a
> language that both people and computers can understand.
What makes you think that language is not intimately related to history?
Entwined in it. Produced by it. Do you really think that the most
efficient way to translate ideas in our head into language is to shorten
words and reduce variety in representation by removing things like
synonyms, abbreviations, and puns? I realize that programming languages
are not natural languages but, seriously, if nice short, concise names
was all it took to have something that worked well, why aren't we all
programming in machine code? It really doesn't get much less ambiguous
or pithy than that.
> When you read any words or groupings of
> words for the first time you have to parse them piece by piece to map
> them to their meaning. After having seen the same words or groupings
> over and over your brain actually learns to recognize them as a single
> unit, which lets you read and understand their meaning in much less
> time.
So explain to me how seeing #' over and over again somehow does not fall
victim to this process of "chunking" (IIRC, this is the term that
Douglas Hofstadter uses and I kind of like the term). Explain to me how
seeing the same sequence of characters repeated over and over again in a
horrendously long symbol name does not somehow lend itself to
recognizing them as a single unit. Do you not think that this kind of
"chunking" is what allows us to subconsciously correct the spelling
mistakes in a word, such that it can become difficult to even see them?
<grumble> So now I'm wallowing in the very pop physiology I am supposed
to dislike. Oh, well. Always knew I was a hypocrite. And at least
when I spouting shite about which I am not an expert, I'm going to at
least quote somebody who is.
<blockquote cite="_Where Mathematics Comes From_, page 19">
All human beings, regardless of culture or education, can instantly tell
at a glance whether there are one, two, or three objects before them.
This ability is called /subitizing/, from the Latin word for "sudden."
[...] In addition to being able to subitize objects in arrays we can
subitize sequences. For example, given a sequence of knocks or beeps or
flashes of light, we can accurately and quickly tell how many there are
[...] These results are well established in experimental studies of
human perception, and have been for half a century. Kaufmann et al.
observed that subitizing was a different process from counting or
estimating. Today there is a fair amount of robust evidence suggesting
that the ability to subitize is inborn. A survey of the range of
subitizing experiments can be found in Mandler and Shebo (1982).
</blockquote>
Its something similar to that about which you were writing in being able
to recognize a grouping of words as a single unit. The bullshit aspect
of my quoting this, however, is that they're referring to an innate
arithmetic ability. I'm trying to use this somewhat unfairly to extend
to language recognition. But you yourself have conceded that "chunking"
allows for treating a sequence of words as a single unit and yet somehow
you think that this kind of process does not also turn a sequence of
characters into a single unit, such that this sequence of characters is
subitized into a word, almost instantaneously. Are you really that slow
of a reader that you can actually feel your brain slow down while trying
to chew over big words?
> It is a bad idea if everyone is looking at things in different
> ways, and depending on what editor, or browser or mail reader you are
> looking at things look different.
But if I'm looking at my things in the same way every time, why do I
even have to think about whatever degenerate representation you want to
use? Sure, I might feel a disturbance in the force if you decide to
start replacing every symbol with its Huffman encoding so that its
shorter, but unless you actually force me to use your scheme, why should
I even know what you're doing? And if having different ways of saying
the same thing are such a bad idea, why do we have synonyms or
nicknames? Thesauruses? Does your head explode whenever you find, one
day, that someone used the package COMMON-LISP while, another day,
someone used CL? You are aware that entire books are translated from
one language into another, and yet the presence of a Portuguese
translation of _Practical Common Lisp_ (well, it that ever happens) in
now way makes it more difficult for me to understand the edition I have
printed in English?
> Methods that are used often should
> have short names because you will type them often and remember them
> anyway, while methods which are used less should have more descriptive
> names to remind the user of their meaning.
As it was written, the word of the Jeff. The truth made manifest in the
very utterance.
> Look at Ruby for a very
> well done standard library that uses clear names which are
> considerably shorter than what common-lisp has.
Here, you're just begging the question.
On Feb 20, 7:05 am, Damien Kick <·····@earthlink.net> wrote:
> Jeff wrote:
> >>> On Mon, 18 Feb 2008, Damien Kick wrote:
> >>>> Kjetil S. Matheussen wrote:
> >>>>> [...] I still end up writing the macro version instead
> >>>>> only because "(when a b)" is faster to read
> >>>>> than "(when a #'(lambda () b))".
>
> >>>> Really? Faster to read. If you sat down with a stop watch and actually
> >>>> timed yourself, how long do you think it would take you to read either
> >>>> form.
>
> > In a round-a-bout way I think you have hit the nail right on the head,
> > except you are wrong. [...]
>
> So wouldn't that be hitting the nail right on the point?
>
> > Of course the mess that he was referring to in
>
> > the second example is everything that is not in the first example. It
> > is a mess because it has nothing to do with the task at hand. In
> > fact, the #' syntax is a leaky abstraction. It is a piece of the
> > underlying implementation of a lisp-2 that is bubbling up into the
> > programmers point of view, and it is necessary to talk to the
> > compiler.
>
> I agree that the mess in the second example has everything to do with
> its not being related to the task at hand. But why do you think that
> syntax is to blame for that? Is it somehow less of a leaky abstraction
> to write (lambda () b) instead of #'(lambda () b) because it has two
> less characters? The mismatch is semantic, not syntactic.
Yes, it would be less leaky. It's not a matter of characters it is a
matter of concepts. In some cases a lambda is used without the need
for a #', but in other cases it is used with one. This is an
additional concept that has to be tended to when programming in a
lisp-2. Besides messing with Arc I've only programmed in common-lisp,
and I actually think there might be good reasons to stick with a
lisp-2 because of it's ability to cut down aliasing bugs. It's
primary drawback however, is exactly this. I don't really want to get
into the lisp-[1|2] debate though. Here the point is that it is
absolutely cleaner and clearer to use a lisp-1 when passing anonymous
functions because of both the conceptual and syntactical differences.
> > are talking about how to improve a programming language, not how to
> > hold them back for historical warm fuzzies. In this case, the goal is
> > to find the most efficient way to translate ideas in our head into a
> > language that both people and computers can understand.
>
> What makes you think that language is not intimately related to history?
I never said that, natural languages surely are.
> Entwined in it. Produced by it. Do you really think that the most
> efficient way to translate ideas in our head into language is to shorten
> words and reduce variety in representation by removing things like
> synonyms, abbreviations, and puns?
I never said any of this either. Limiting the number of extra
concepts you need to deal with when translating program ideas from
your head to your computer is good. You already saw my personal rule
for method names and length.
> I realize that programming languages
> are not natural languages but, seriously, if nice short, concise names
> was all it took to have something that worked well, why aren't we all
> programming in machine code? It really doesn't get much less ambiguous
> or pithy than that.
Your either completely missing the point or bad at making insults.
Moving to higher levels of abstraction is the goal, not smaller
words. Typically moving up a level of abstraction means leaving
behind details of underlying implementation so that you can get closer
to only thinking about your specific programming problem.
>
> > When you read any words or groupings of
>
> > words for the first time you have to parse them piece by piece to map
> > them to their meaning. After having seen the same words or groupings
> > over and over your brain actually learns to recognize them as a single
> > unit, which lets you read and understand their meaning in much less
> > time.
>
> So explain to me how seeing #' over and over again somehow does not fall
> victim to this process of "chunking" (IIRC, this is the term that
> Douglas Hofstadter uses and I kind of like the term). Explain to me how
> seeing the same sequence of characters repeated over and over again in a
> horrendously long symbol name does not somehow lend itself to
> recognizing them as a single unit.
You are confusing two separate topics. One is conceptual complexity
and the other is syntactical complexity. I'm sure a lisper chunks #'
just fine, but in a lisp-2 you have to maintain two concepts of a
function: one which has #' and one which does not. (< 1 2) => T
> But you yourself have conceded that "chunking"
> allows for treating a sequence of words as a single unit and yet somehow
> you think that this kind of process does not also turn a sequence of
> characters into a single unit, such that this sequence of characters is
> subitized into a word, almost instantaneously. Are you really that slow
> of a reader that you can actually feel your brain slow down while trying
> to chew over big words?
I didn't concede it, I brought it into the discussion. Yes, chunking
occurs over any sequence of characters, and yes I can feel my brain
slow down when I see long words that I am unfamiliar with and even
more so with sequences of such words.
> > It is a bad idea if everyone is looking at things in different
>
> > ways, and depending on what editor, or browser or mail reader you are
> > looking at things look different.
>
> But if I'm looking at my things in the same way every time, why do I
> even have to think about whatever degenerate representation you want to
> use? Sure, I might feel a disturbance in the force if you decide to
> start replacing every symbol with its Huffman encoding so that its
> shorter, but unless you actually force me to use your scheme, why should
> I even know what you're doing? And if having different ways of saying
> the same thing are such a bad idea, why do we have synonyms or
> nicknames? Thesauruses? Does your head explode whenever you find, one
> day, that someone used the package COMMON-LISP while, another day,
> someone used CL? You are aware that entire books are translated from
> one language into another, and yet the presence of a Portuguese
> translation of _Practical Common Lisp_ (well, it that ever happens) in
> now way makes it more difficult for me to understand the edition I have
> printed in English?
The first sentence of the paragraph was sufficient. I think there are
many practical reasons to have groups of developers who share code
using the same representation. Posting on mailing lists, reading
comments and examples, pair-programming, discussion, editor macros,
name aliasing where one persons nickname or abbreviation is the same
as another persons new method name...
> > Methods that are used often should
>
> > have short names because you will type them often and remember them
> > anyway, while methods which are used less should have more descriptive
> > names to remind the user of their meaning.
>
> As it was written, the word of the Jeff. The truth made manifest in the
> very utterance.
Yup, now you get it.
> > Look at Ruby for a very
>
> > well done standard library that uses clear names which arediverse
> > considerably shorter than what common-lisp has.
>
> Here, you're just begging the question.
I didn't ask any questions. There are many great things to learn from
Common Lisp and its followers, but this thread shows an amazing level
of closed mindedness that makes me think it could never become the
type of vibrant community I enjoy working in. Maybe Arc could.
-Jeff
From: Damien Kick
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <13rtfg03s3elu44@corp.supernews.com>
Jeff wrote:
> I don't really want to get
> into the lisp-[1|2] debate though.
Then whey did you bring it up, exactly? Oh, wait.
> Here the point is that it is
> absolutely cleaner and clearer to use a lisp-1 when passing anonymous
> functions because of both the conceptual and syntactical differences.
Yes, absolutely. Of course it is. Why bother to debate anything about
which everyone already agrees?
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47bb6939$0$8064$607ed4bc@cv.net>
dkixk wrote:
> On Feb 19, 7:32 am, "Kjetil S. Matheussen" <··············@notam02.no>
> wrote:
>
>>On Mon, 18 Feb 2008, Damien Kick wrote:
>>
>>>Kjetil S. Matheussen wrote:
>>
>>>>[...] I still end up writing the macro version instead
>>>>only because "(when a b)" is faster to read
>>>>than "(when a #'(lambda () b))".
>>
>>>Really? Faster to read. If you sat down with a stop watch and actually
>>>timed yourself, how long do you think it would take you to read either
>>>form.
>>
>>Its faster to read because its less messy, not because the time
>>looking at each token takes very much time. [...]
>
>
> So one would look at each token in about the same time and then our
> mental processes are supposed to get bogged down because of all the
> extra "mess". What is this mess to which you're referring exactly?
I SEE YOU KNOW NOTHING ABOUT READABILITY.*
(I see you know nothing about readability.)
hth, kenny
* "You make me want to shout, throw my hands up and shout..." k
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Damien Kick
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <13rnguur4v9e499@corp.supernews.com>
Ken Tilton wrote:
>
> I SEE YOU KNOW NOTHING ABOUT READABILITY.*
>
> (I see you know nothing about readability.)
>
> hth, kenny
>
> * "You make me want to shout, throw my hands up and shout..." k
>
I think you may be right, because I've read this a few times and I still
have no idea what you mean. I do feel an odd urge to dance like I was
at a wedding reception, but that's about all I'm getting out of this
message. You, sir, have proven your point most admirably.
On Feb 19, 11:08 pm, Damien Kick <·····@earthlink.net> wrote:
> Ken Tilton wrote:
>
> > I SEE YOU KNOW NOTHING ABOUT READABILITY.*
>
> > (I see you know nothing about readability.)
>
> > hth, kenny
>
> > * "You make me want to shout, throw my hands up and shout..." k
>
> I think you may be right, because I've read this a few times and I still
> have no idea what you mean. I do feel an odd urge to dance like I was
> at a wedding reception, but that's about all I'm getting out of this
> message. You, sir, have proven your point most admirably.
These links may clarify the immediate meaning...
a passable overview (but by far not the best)-
http://www.aranworld.com/2005/03/all-caps-readability-and-press_10.html
simple example - http://grasswire.wordpress.com/2008/01/16/caps-vs-lower-case/
formal - http://hubel.sfasu.edu/courseinfo/SL03/email_study.htm
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47bbeb90$0$8071$607ed4bc@cv.net>
David Hilton wrote:
> These links may clarify the immediate meaning...
>
> a passable overview (but by far not the best)-
> http://www.aranworld.com/2005/03/all-caps-readability-and-press_10.html
> simple example - http://grasswire.wordpress.com/2008/01/16/caps-vs-lower-case/
Awesome. I never knew the upper half was especially important.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Damien Kick
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <13rteuvfa78b6a7@corp.supernews.com>
David Hilton wrote:
> On Feb 19, 11:08 pm, Damien Kick <·····@earthlink.net> wrote:
>> Ken Tilton wrote:
>>
>>> I SEE YOU KNOW NOTHING ABOUT READABILITY.*
>>> (I see you know nothing about readability.)
>>> hth, kenny
>>> * "You make me want to shout, throw my hands up and shout..." k
>> I think you may be right, because I've read this a few times and I still
>> have no idea what you mean. [...]
>
> These links may clarify the immediate meaning...
>
> a passable overview (but by far not the best)-
> http://www.aranworld.com/2005/03/all-caps-readability-and-press_10.html
> simple example - http://grasswire.wordpress.com/2008/01/16/caps-vs-lower-case/
> formal - http://hubel.sfasu.edu/courseinfo/SL03/email_study.htm
Those are interesting links. I will definitely continue to not write
entire sentences, paragraphs, or e-mails in all uppercase. Of course, I
still have no idea what Kenzo is on about.
On Tue, 19 Feb 2008, dkixk wrote:
>
> Less messy. Cleaner. More readable. This is all still bullshit hand
> waving to try and avoid just coming right out and saying, "I like it
> better."
Well, I tried to build up an argument:
(when a b)
vs.
(when a #'(lambda () b))
My point is that the first one causes less mess, simply
because it has less tokens. I think thats a fair argument.
Well, enough said. Stupid discussion.
On Feb 19, 4:11 pm, "Kjetil S. Matheussen" <··············@notam02.no>
wrote:
> On Tue, 19 Feb 2008, dkixk wrote:
>
> > Less messy. Cleaner. More readable. This is all still bullshit hand
> > waving to try and avoid just coming right out and saying, "I like it
> > better."
>
> Well, I tried to build up an argument:
>
> (when a b)
>
> vs.
>
> (when a #'(lambda () b))
>
> My point is that the first one causes less mess, simply
> because it has less tokens. I think thats a fair argument.
But you had previously written:
> Its faster to read because its less messy, not because the time
> looking at each token takes very much time.
If it doesn't take much time to look at each token, whatever a token
may be in the context of a human looking at glyphs, how does the
effect of adding a few more of these "cheap to look at" tokens result
in the one form being so much slower to read than the other? I think
it's an argument which can't be articulated very well and, when
challenged, leads one back to the unsupported assertion which started
the whole thing off in the first place.
> Well, enough said. Stupid discussion.
I have a dream. That some day a name with be judged not by the count
of its characters but rather the characters of its content. That ...
Oh, hell, I couldn't keep it going any longer than that. In many
ways, its a stupid discussion. Unfortunately, now we've got some kind
of splinter group in the lisp community, some of the motivation for
which being that somebody didn't like the length of the names. Feh.
Judean People's Front. We're the People's Front of Judea!
On Tue, 19 Feb 2008, Kjetil S. Matheussen wrote:
> On Mon, 18 Feb 2008, Damien Kick wrote:
>
> > Kjetil S. Matheussen wrote:
> >
> > > [...] I still end up writing the macro version instead
> > > only because "(when a b)" is faster to read
> > > than "(when a #'(lambda () b))".
> >
> > Really? Faster to read. If you sat down with a stop watch and actually
> > timed yourself, how long do you think it would take you to read either
> > form.
>
> Its faster to read because its less messy, not because the time
> looking at each token takes very much time. Guess I should
> have written faster to understand instead of faster to read,
> altough it should be obvious.
>
Hmm, I wonder if this, eh, dilemma can be solved just by using a
more intelligent text editor:
(lambda () a)
takes up more space (and can eventually make code more messy) than:
(fn () a)
However, the first one is more explicit.
So a solution could be that if the
language uses lambda, then the text editor should decrease
the size of "lambda", while if the language uses fn, then
the text editor should increase the size of "fn". Or,
alternatively use different colors, or symbols, or.
Another solution is just to map shortcuts so that
its easy to increase and decrease the size of the font,
so that if the code starts to get big and messy: just
press a key, and make more code available on the screen
at once.
I have mapped Ctrl-+ and Ctrl-- to do that in emacs:
(defvar fontname "Bitstream Vera Sans Mono")
(defvar fontsize 12)
(defun font-set ()
(let ((font (format "%s-%d" fontname fontsize)))
(set-default-font font)
(print font)))
(defun font-inc ()
(interactive)
(setq fontsize (1+ fontsize))
(font-set))
(defun font-dec ()
(interactive)
(setq fontsize (1- fontsize))
(font-set))
(global-set-key (kbd "<C-kp-add>") 'font-inc)
(global-set-key (kbd "<C-kp-subtract>") 'font-dec)
(font-set)
From: Harald Hanche-Olsen
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <pcoy79k7wph.fsf@shuttle.math.ntnu.no>
+ Damien Kick <·····@earthlink.net>:
> My fist and your face. Argue with that, egg head. Oh, and that
> stupid "amb da" part. Hard to say. Should have just been "da
> calculus". Kinda like "da Bears".[1] Makes a nice short name, too.
Um, "calculus" is of course waaay to pretentious (uh, snobbish).
So you imagine you know Latin, eh? No, "da rocks" it is.
--
* Harald Hanche-Olsen <URL:http://www.math.ntnu.no/~hanche/>
- It is undesirable to believe a proposition
when there is no ground whatsoever for supposing it is true.
-- Bertrand Russell
On 2008-02-17 04:34:34 -0500, Harald Hanche-Olsen <······@math.ntnu.no> said:
> No, "da rocks" it is.
Yo, da L-rocks, yo
From: Holger Schauer
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <yxzwsp68o6w.fsf@gmx.de>
On 5278 September 1993, George Neuner wrote:
> On Tue, 12 Feb 2008 20:52:19 +0100, Joost Diepenmaat <·····@zeekat.nl>
> wrote:
[lambda to long]
> Then why not write an "fn" macro?
That's not a fix at all, that's macrology abuse. We're not talking
personal preferences here alone, it's about what's recommended as the
"right" thing the language demands anybody to use, especially for use
in code that's shared with other developers. [1] Whether CL chose
lambda or Arc has fn is really not all interesting. What's interesting
with code is readability and maintainability and "fixing" a language
by silly renaming whatever isn't up to one's personal taste is
ultimately defeating both of these issues.
Holger
Footnotes:
[1] I feel a kenny coming on: of course, as we're here in cll and all
of us being smug lisp weenies who use lisp only alone at home, that's
not really an issue.
--
--- http://hillview.bugwriter.net/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
177: Mainframe-Admin
Arbeitsschutzschuhe (Holger Spielmann)
From: tim
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <13rbqrl8usgfm5d@corp.supernews.com>
On Fri, 15 Feb 2008 12:16:23 +0100, Holger Schauer wrote:
> ... "fixing" a language
> by silly renaming whatever isn't up to one's personal taste is
> ultimately defeating both of these issues.
>
> Holger
While gratuitous changes may be counter-productive, there is a
counter-argument.
Lisp function and macro names are lacking in regularity, clarity and
consistency. They are also very long in many cases. In a large project you
should be able to amortize the costs involved in renaming and reap the
benefits.
Tim
From: Espen Vestre
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m1fxvvao1r.fsf@gazonk.netfonds.no>
Joost Diepenmaat <·····@zeekat.nl> writes:
> I know you're (probably) joking, but my main issue with lambda is that
> it's IMHO very hard to type on a QWERTY keyboard.
Reality check:
CL-USER 7 > (time (read))
Timing the evaluation of (READ)
lambda
User time = 0.028
System time = 0.007
Elapsed time = 0.878
Allocation = 49288 bytes
14 Page faults
LAMBDA
I can reduce it to about 0.6 seconds, but then there's a 50% chance
that I end up with labmda or lambvda. My estimate is that so far, I
have may have spent up to 2 hours of my life typing "lambda".
Compare that to the time used on cll. Ouch, gotta go!
--
(espen)
In article <··············@gazonk.netfonds.no>,
Espen Vestre <·····@vestre.net> wrote:
> Joost Diepenmaat <·····@zeekat.nl> writes:
>
> > I know you're (probably) joking, but my main issue with lambda is that
> > it's IMHO very hard to type on a QWERTY keyboard.
>
> Reality check:
>
> CL-USER 7 > (time (read))
> Timing the evaluation of (READ)
> lambda
>
> User time = 0.028
> System time = 0.007
> Elapsed time = 0.878
> Allocation = 49288 bytes
> 14 Page faults
> LAMBDA
>
> I can reduce it to about 0.6 seconds, but then there's a 50% chance
> that I end up with labmda or lambvda. My estimate is that so far, I
> have may have spent up to 2 hours of my life typing "lambda".
>
> Compare that to the time used on cll. Ouch, gotta go!
I promise you there will come a time when you will want those two hours
back.
rg
From: Robert Uhl
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m37ih79ji4.fsf@latakia.dyndns.org>
Espen Vestre <·····@vestre.net> writes:
> Joost Diepenmaat <·····@zeekat.nl> writes:
>
>> I know you're (probably) joking, but my main issue with lambda is that
>> it's IMHO very hard to type on a QWERTY keyboard.
>
> Reality check:
>
> CL-USER 7 > (time (read))
> Timing the evaluation of (READ)
> lambda
>
> User time = 0.028
> System time = 0.007
> Elapsed time = 0.878
> Allocation = 49288 bytes
> 14 Page faults
> LAMBDA
>
> I can reduce it to about 0.6 seconds, but then there's a 50% chance
> that I end up with labmda or lambvda. My estimate is that so far, I
> have may have spent up to 2 hours of my life typing "lambda".
You've only used lambda 136 times?!? That seems a bit...low.
--
Robert Uhl <http://public.xdi.org/=ruhl>
America may be unique in being a country which has leapt from barbarism
to decadence without touching civilisation. --John O'Hara
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Espen Vestre <·····@vestre.net> writes:
>
>> Joost Diepenmaat <·····@zeekat.nl> writes:
>>
>>> I know you're (probably) joking, but my main issue with lambda is that
>>> it's IMHO very hard to type on a QWERTY keyboard.
>>
>> Reality check:
>>
>> CL-USER 7 > (time (read))
>> Timing the evaluation of (READ)
>> lambda
>>
>> User time = 0.028
>> System time = 0.007
>> Elapsed time = 0.878
>> Allocation = 49288 bytes
>> 14 Page faults
>> LAMBDA
>>
>> I can reduce it to about 0.6 seconds, but then there's a 50% chance
>> that I end up with labmda or lambvda. My estimate is that so far, I
>> have may have spent up to 2 hours of my life typing "lambda".
>
> You've only used lambda 136 times?!? That seems a bit...low.
CL-USER> (/ (* 2 60 60) 0.878)
8200.455
Regards,
Victor
--
http://macrodefinition.blogspot.com
From: Maciej Katafiasz
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fp330a$miq$1@news.net.uni-c.dk>
Den Thu, 14 Feb 2008 17:00:03 -0700 skrev Robert Uhl:
>>> I know you're (probably) joking, but my main issue with lambda is that
>>> it's IMHO very hard to type on a QWERTY keyboard.
>>
>> Reality check:
>>
>> CL-USER 7 > (time (read))
>> Timing the evaluation of (READ)
>> lambda
>>
>> User time = 0.028
>> System time = 0.007
>> Elapsed time = 0.878
>> Allocation = 49288 bytes
>> 14 Page faults
>> LAMBDA
>>
>> I can reduce it to about 0.6 seconds, but then there's a 50% chance
>> that I end up with labmda or lambvda. My estimate is that so far, I
>> have may have spent up to 2 hours of my life typing "lambda".
>
> You've only used lambda 136 times?!? That seems a bit...low.
cl-user> (/ (* 2 3600) 0.878)
8200.455
Cheers,
Maciej
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t6i2dntgut4oq5@pandora.alfanett.no>
På Thu, 14 Feb 2008 10:24:16 +0100, skrev Espen Vestre <·····@vestre.net>:
>
> I can reduce it to about 0.6 seconds, but then there's a 50% chance
> that I end up with labmda or lambvda. My estimate is that so far, I
> have may have spent up to 2 hours of my life typing "lambda".
>
Well this requires less typing ;)
;; To use this in the editor you need a character set that supports unicode
;; like "Lucida Console".
;; Unlike base-char simple-char understands Unicode.
(set-default-character-element-type 'simple-char)
;; modify the reader to insert lambda when it sees #λ
(defun lambda-reader (stream char)
(declare (ignore char))
(let* ((parameters (read stream nil (values) t))
(code (read stream nil (values) t)))
(when (and (consp parameters) (consp code))
(list 'lambda parameters code))))
(set-macro-character #\λ #'lambda-reader)
;; editor: Alt-Control-l inserts λ in lisp mode
(editor:defcommand "Insert Lambda" (p)
(declare (ignore p))
(editor:insert-character
(editor:current-point)
#\λ))
(editor:bind-key "Insert Lambda" #\meta-\control-\l :mode "lisp")
Now you can type..
(mapcar λ(e) (+ e 10) '(1 2 3 4))
Note that this is LispWorks spesific.
Also I have yet to figure out how to make the LispWorks editor save/load
utf8.
(Emacs can figure it out.)
--------------
John Thingstad
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t6i2xbs2ut4oq5@pandora.alfanett.no>
På Thu, 14 Feb 2008 19:45:13 +0100, skrev John Thingstad
<·······@online.no>:
Some errors crept into the comments.
- ;; To use this in the editor you need a character set that supports
unicode
+ ;; To use this in the editor you need a font that supports unicode
- ;; modify the reader to insert lambda when it sees #λ
+ ;; modify the reader to insert (lambda (read) (read)) when it sees λ
--------------
John Thingstad
From: Lars Brinkhoff
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <858x1mzgo6.fsf@junk.nocrew.org>
Espen Vestre <·····@vestre.net> writes:
> Joost Diepenmaat <·····@zeekat.nl> writes:
> > I know you're (probably) joking, but my main issue with lambda is
> > that it's IMHO very hard to type on a QWERTY keyboard.
>
> Reality check:
>
> CL-USER 7 > (time (read))
> Timing the evaluation of (READ)
> lambda
>
> User time = 0.028
> System time = 0.007
> Elapsed time = 0.878
> Allocation = 49288 bytes
> 14 Page faults
> LAMBDA
Ouch! Over two page faults per character could really hurt
performance in tight loops, etc. I bet F and N are almost always
fit in the L1 cache.
From: Espen Vestre
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m1pruy7bei.fsf@gazonk.netfonds.no>
Lars Brinkhoff <·········@nocrew.org> writes:
> Ouch! Over two page faults per character could really hurt
> performance in tight loops, etc. I bet F and N are almost always
> fit in the L1 cache.
Now that's really convincing, I'll define an FN macro ASAP!
:-)
--
(espen)
In article <··············@vestre.net>, Espen Vestre <·····@vestre.net>
wrote:
> I don't understand all this hostility to lambda.
It's not mnemonic. It makes a certain amount of sense that FN should
mean "function". That LAMBDA should mean function does not. (I vaguely
recall that Church used lambda because of some random typographical
constraint that he was facing back in the day when moveable type was a
literal description and not a metaphor.)
It's also easy to lose sight of the fact that L-A-M-B-D-A and the actual
Greek letter (which I cannot seem to coax my keyboard into producing at
the moment) are not the same thing. If one could reliably produce and
display the actual Greek letter on standard hardware we might not be
having this conversation.
rg
From: Espen Vestre
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m1ejbh9nud.fsf@gazonk.netfonds.no>
Ron Garret <·········@flownet.com> writes:
> It's not mnemonic. It makes a certain amount of sense that FN should
> mean "function". That LAMBDA should mean function does not.
But it doesn't just mean "function", it means "function abstraction",
or more procedurally "make a function that takes this arglist out of
that expression". "fn" seems like the name of some specific function,
not an operator that makes an unnamed function.
--
(espen)
From: Didier Verna
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <mux3arycpwt.fsf@uzeb.lrde.epita.fr>
Espen Vestre <·····@vestre.net> wrote:
> I don't understand all this hostility to lambda. Be happy, enjoy your
> language while you can, while you're debating this instead of hacking
> lisp, evildoers may already be at work writing a 32456 page
> specification of New World Order Lisp, with /this/ lambda:
>
> <ansi.lisp.common.core.special-forms.lambda>
> <ansi.lisp.common.core.special-forms.lambda.arglist>
> ....
> </ansi.lisp.common.core.special-forms.lambda.arglist>
> <ansi.lisp.common.core.special-forms.lambda.body>
> ....
> </ansi.lisp.common.core.special-forms.lambda.body>
> </ansi.lisp.common.core.special-forms.lambda>
ROTFL ! :-)
--
Resistance is futile. You will be jazzimilated.
Didier Verna, ······@lrde.epita.fr, http://www.lrde.epita.fr/~didier
EPITA / LRDE, 14-16 rue Voltaire Tel.+33 (0)1 44 08 01 85
94276 Le Kremlin-Bic�tre, France Fax.+33 (0)1 53 14 59 22 ······@xemacs.org
From: Joost Diepenmaat
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <87fxvykldi.fsf@zeekat.nl>
Marco Antoniotti <·······@gmail.com> writes:
> Yes, but /. or /_ (looks like an L) are much mure Perlish! Which is
> one of the driving forces of programming today.
And /. is extremely easy to type on a US keyboard (which is the most
popular keyboard layout here in the Netherlands).
--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
From: Kent M Pitman
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <uskzzn8ys.fsf@nhplace.com>
"John Thingstad" <·······@online.no> writes:
> >> (mapcar ���(format "~A:~A" ���1 ���2) list)
> >
> > Here, by contrast, I see lambdas.
> >
> > But I'm curious: how does the nesting of this macro work? What does
> >
> > (lambda (x)
> > (lambda (y z)
> > (f x y z)))
> >
> > look like in this shorthand format?
>
> ���(���1 ���(f ���1 ���2 ���3))
And how do I read that? (What's the first of the ���1's doing there? Why
does the second lambda not accidentally take 3 arguments, and why does it
start counting from 2?)
If I read it right, it doesn't cut&paste well transparently
into another expression [inside another lambda expression].
That is, ordinarily if I take a lambda with no free variables, I can
paste it into any lexical position and it will have the same meaning.
But something gives me the impression that the above expression, pasted
into certain other contexts, would suddenly mean something different.
From: Kent M Pitman
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <u1w7hmze0.fsf@nhplace.com>
Pascal Bourguignon <···@informatimago.com> writes:
> Kent M Pitman <······@nhplace.com> writes:
>
> > The Lisp Machine used the SAIL (Stanford AI Lab) character set, which
> > had Lambda allocated on code 008, and which aligned with BS
> > (backspace) in ASCII. In MACLISP code (sometimes with help from #+/#-
> > compatibility), you could write such a compatibility macro. But this
> > meant that on "glass" displays (CRT displays that were not bitmapped
> > and could not overstrike), it had a delete effect; on paper terminals
> > and some display terminals, it backed up and overstruck; and in EMACS
> > it displayed as ^H ...
> >
> > Some people used it anyway, and it just looked very weird.
>
> Nowadays, one can easily bind in emacs a key to any character.
> There are a lot of useless keys on a PC-105 keyboard...
Btw, I wasn't talking about the difficulty of typing them. I was
presupposing that you had typed in the character successfully. I was
talking about how the character rendered visually, and why there was
not an early move to use the lambda character in code. Even in
systems like the Lisp Machine, it wasn't done--I think mostly because
LispM users often stored their program texts (their .lisp files) on a
mainframe such as a PDP-10 or VAX, and then often edited their
programs there in EMACS, since Lisp Machines (being expensive) were
often shared by several users at different times of day. When in
EMACS, the fact that programs looked much different than in LispM
Zmacs was enough to keep a lot of the special characters from being
used. It just wasn't worth having the pretty display in some places
and the non-pretty display elsewhere.
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47aed800$0$15204$607ed4bc@cv.net>
Raffael Cavallaro wrote:
> On 2008-02-09 16:21:39 -0500, ···········@gmail.com said:
>
>> My favorite thing about scheme is lisp-1; my favorite thing about CL
>> is unhygienic macros. Arc combines them whether it was a design goal
>> or not.
>
>
> there are already several scheme implementations that have a common-lisp
> style defmacro available.
>
Too little too late. Let us know when nil is false and their table of
contents is longer than the CLHS spec. Scheme will be Arc's first
victim. Glad to see the Lisp-1s eating their own. :)
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <6191taF1tc429U1@mid.individual.net>
Ken Tilton wrote:
>
>
> Raffael Cavallaro wrote:
>> On 2008-02-09 16:21:39 -0500, ···········@gmail.com said:
>>
>>> My favorite thing about scheme is lisp-1; my favorite thing about CL
>>> is unhygienic macros. Arc combines them whether it was a design goal
>>> or not.
>>
>> there are already several scheme implementations that have a
>> common-lisp style defmacro available.
>
> Too little too late. Let us know when nil is false and their table of
> contents is longer than the CLHS spec. Scheme will be Arc's first
> victim. Glad to see the Lisp-1s eating their own. :)
NIL and false were allowed to be the same in R3RS Scheme, and that was
in fact the case in some Scheme implementations (actually until not so
long ago).
The table of contents for PLT Scheme is pretty long. See
http://download.plt-scheme.org/doc/ . There is also a paper describing
the "completeness" of that environment. See
http://citeseer.ist.psu.edu/201755.html
PLT Scheme is quite popular in the Scheme community.
Up until R5RS Scheme, the specification gave the impression that Scheme
is a minimalistic language. However, Scheme systems that are actually
used in practice are as large as anything else out there.
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/
On Feb 10, 4:54 am, Ken Tilton <···········@optonline.net> wrote:
> Scheme will be Arc's first victim.
As long as Arc is implemented in (Mz)Scheme, I think it will only
raise interest in Scheme, or at least the PLT implementation. Once Arc
become self-hosting, it may indeed swallow Schemers whole*, but that
day certainly feels a long way off given the status of Arc0.
[*] Plot summaries for a late-night sci-fi-horror movies included at
no extra charge. See store for details.
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47b0d808$0$7867$607ed4bc@cv.net>
John Stoneham wrote:
> On Feb 10, 4:54 am, Ken Tilton <···········@optonline.net> wrote:
>
>>Scheme will be Arc's first victim.
>
>
> As long as Arc is implemented in (Mz)Scheme, I think it will only
> raise interest in Scheme, or at least the PLT implementation.
Think bigger. The people trying Arc are Pythonistas and Rubicons, all of
whom are focused on applications. They will not even notice the
difference between Scheme and CL, but they will see CL has a bigger
toolbox and then they'll choose CL.
http://smuglispweeny.blogspot.com/
> Once Arc
> become self-hosting, it may indeed swallow Schemers whole*, but that
> day certainly feels a long way off given the status of Arc0.
Yep. This is why I think I hear the Arconauts coming over the hill already.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Feb 11, 5:19 pm, Ken Tilton <···········@optonline.net> wrote:
> Think bigger. The people trying Arc are Pythonistas and Rubicons, all of
> whom are focused on applications. They will not even notice the
> difference between Scheme and CL, but they will see CL has a bigger
> toolbox and then they'll choose CL.
It's my experience that Pythonistas and Rubicons are so in love with
themselves for having chosen their respective languages that they see
little benefit in exploring elsewhere and often scorn those who do.
Rather, someone likely to stumble upon arclanguage.org with real
interest is someone wishing to find a new language to chew on for a
while. I would say it's also likely that what lead them to
arclanguage.org in the first place was a knowledge or awareness of who
Paul Graham is and that Arc is his new baby. And anyone who knows
anything at all about Paul Graham knows two things: 1) He got rich
selling his web business; and 2) He credits Lisp for that success and
pimps it out like he's Terrence Howard in Hustle & Flow[*]. (Ok, they
probably also know or assume a couple of other things about him too,
but these are the first two almost everyone knows.)
So I would posit that a newcomer to Arc probably already knows about
Lisp and is interested in Arc because Lisp's most public advocate has
come up with something new. Now, the first 3 things they learn about
Arc when visiting the Arc site are: 1) Arc is a "new dialect" of Lisp;
2) It's not finished yet; and 3) "The current version compiles into
MzScheme and structurally is as much a skin on MzScheme as a separate
language."
They probably already knew #1, and weren't surprised by #2. But when
they get to #3, all kinds of bells start going off in their head. I
don't think that the following thought process is uncommon for them:
"What?!?" they think to themselves. "I thought _Common_Lisp_ was
supposed to be the Holy Grail of languages, at least that's what PG
has been telling me all these years. So why is he writing Arc in
MzScheme instead of Common Lisp? I thought he said you could do
anything and everything with Common Lisp -- was he wrong, or was I in
thinking he said that? Well, shoot, if MzScheme is good enough for PG
to trust with his new baby, it must be good enough for us mortals
until Arc is a little more finished."
So someone who had little-to-no interest in Scheme going in will now
want to find out what it is about MzScheme that makes it the
implementation language of choice for the Grandaddy Pimp of Common
Lisp. And sure enough, the Alexa comparison graph of arclangauge.org
and plt-scheme.org shows a steady increase in traffic to plt-
scheme.org over the past week while at the same time showing a steady
decrease in traffic to arclanguage.org. What's interesting is that the
plt-scheme.org traffic did not show a significant increase when Arc
was first released, so the Scheme traffic is increasing only AFTER
people have played with Arc for a bit.
If Arc had been implemented in C, we could speculate about whether Arc
as a language would ultimately drive interest towards Common Lisp over
Scheme or vise versa. But I think that since PG chose MzScheme as the
implementation platform, the winner here has to be PLT Scheme, at
least short-term. Long-term, I agree that if Scheme is fixed it will
end up being Common Lisp. I don't know if dabblers in Arc will get
that far in their exploration, though.
Anyway, this is all just speculation on my part. The ballgame sure did
get interesting all of a sudden.
[*] Excellent movie, by the way. The subject matter is rough, but
anyone who's ever felt compelled to rekindle their love for a talent
from their youth only to meet obstacle after obstacle along the way,
will connect on an emotional level with this movie.
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47b1d1e3$0$7865$607ed4bc@cv.net>
John Stoneham wrote:
> On Feb 11, 5:19 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Think bigger. The people trying Arc are Pythonistas and Rubicons, all of
>>whom are focused on applications. They will not even notice the
>>difference between Scheme and CL, but they will see CL has a bigger
>>toolbox and then they'll choose CL.
>
>
> It's my experience that Pythonistas and Rubicons are so in love with
> themselves for having chosen their respective languages that they see
> little benefit in exploring elsewhere and often scorn those who do.
No, look at the migrations from C to Java to Python to Ruby. The herd
has no loyalty.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Sohail Somani
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <nDksj.7955$FO1.7500@edtnps82>
On Tue, 12 Feb 2008 12:05:43 -0500, Ken Tilton wrote:
> No, look at the migrations from C to Java to Python to Ruby. The herd
> has no loyalty.
I notice you do not mention C++. Did the herd not move into/past C++?
--
Sohail Somani
http://uint32t.blogspot.com
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47b219d5$0$15202$607ed4bc@cv.net>
Sohail Somani wrote:
> On Tue, 12 Feb 2008 12:05:43 -0500, Ken Tilton wrote:
>
>
>>No, look at the migrations from C to Java to Python to Ruby. The herd
>>has no loyalty.
>
>
> I notice you do not mention C++. Did the herd not move into/past C++?
>
I did not want to burden the reader, plus it seemed to me a lot of
people never even headed down the C++ dead-end. Industry did, but I was
talking about the folks in the trenches.
And to tell you the truth, it is not clear to me how many mainframe
types ever made it to C, I might better have started the list at Java.
In the end I remembered that I have never let a concern for accuracy get
in the way of my rants, way too much work.
hth, kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Vetle Roeim
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <m2ejbiw18y.fsf@gmail.com>
Ken Tilton <···········@optonline.net> writes:
> John Stoneham wrote:
>> On Feb 11, 5:19 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>Think bigger. The people trying Arc are Pythonistas and Rubicons, all of
>>>whom are focused on applications. They will not even notice the
>>>difference between Scheme and CL, but they will see CL has a bigger
>>>toolbox and then they'll choose CL.
>>
>>
>> It's my experience that Pythonistas and Rubicons are so in love with
>> themselves for having chosen their respective languages that they see
>> little benefit in exploring elsewhere and often scorn those who do.
>
> No, look at the migrations from C to Java to Python to Ruby. The herd
> has no loyalty.
I haven't heard anyone going this route. People seem to be going from
Java to Ruby, not from Python to Ruby, which is a step backwards. Ruby
has too many similarities with Perl.
--
It's not a bug, it's the future.
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47b21b53$0$15193$607ed4bc@cv.net>
Vetle Roeim wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>John Stoneham wrote:
>>
>>>On Feb 11, 5:19 pm, Ken Tilton <···········@optonline.net> wrote:
>>>
>>>
>>>>Think bigger. The people trying Arc are Pythonistas and Rubicons, all of
>>>>whom are focused on applications. They will not even notice the
>>>>difference between Scheme and CL, but they will see CL has a bigger
>>>>toolbox and then they'll choose CL.
>>>
>>>
>>>It's my experience that Pythonistas and Rubicons are so in love with
>>>themselves for having chosen their respective languages that they see
>>>little benefit in exploring elsewhere and often scorn those who do.
>>
>>No, look at the migrations from C to Java to Python to Ruby. The herd
>>has no loyalty.
>
>
> I haven't heard anyone going this route. People seem to be going from
> Java to Ruby, not from Python to Ruby, which is a step backwards. Ruby
> has too many similarities with Perl.
>
See: http://wiki.alu.org/RtL_Highlight_Film
The path followed does not make it into the highlights (you have to
click thru to the whole Road) but it's a fun place to start.
Python has some nice stupid pet tricks, but it is fundamentally broken
in ways (I gather from the hoopla) Ruby is not (is it that blocks are
better than Python's pathtic lambda (we should make them stop using that
name)).
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47adf09a$0$15159$607ed4bc@cv.net>
Rainer Joswig wrote:
> It doesn't. For me 'Arc' is a 'domain specific language'
> for a certain type of programmer. Not more.
You mean the web app thing? If so, PG has said that that is there just
to "push down" on the core so Arc is not being defined purely in the
abstract. And he has said his goal is a hundred-year language, I doubt
that means for some domain that will last a hundred years.
>>Honestly, Pascal, Arc's biggest draw isn't what's different from
>>scheme or common lisp, it's how it combines the best of both languages
>>(at least I think it does).
>
>
> Honestly, it does not even try to do that.
Well, there /is/ one place where he says "CL sucks this way, Scheme
sucks that way. Maybe "it's how it eliminates the worst of both"?
>
>
>>I'm sure you'll disagree on some points,
>>like it's lisp-1-ness and various other choices it made, but the idea
>>was to combine the two languages.
>
>
> That was a non-goal. Where did you read that?
I for one get that feeling from the fact that he believes in small
(Scheme) but kept CL macros and NIL-is-false. But then we see the syntax
introduced to achieve brevity and that breaks with Lisp...
Anyway, all these classic angels on the head of a pin debates here in
c.l.l are typical of c.l.l where people sit around like old men outside
the barber shop grumbling about everything new that passes by. PG is a
working programmer thinking about the language he would like to use and
thinking it is the language lotsa real programmers would like best, he
is not (I agree) trying to be different or trying to be the same, he is
trying for the perfect language. He has old (Lisp-2), new (Lisp-1),
borrowed (CL macros and nil/fals), and if he read all this you might
hear some blue. :)
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <61912aF1u0vi7U1@mid.individual.net>
···········@gmail.com wrote:
> Oddly, the number one thing about Arc that you dislike about it seems
> to be that it isn't innovated by your definition of innovative. Why
> does it have to be innovative?
Because of http://www.paulgraham.com/hundred.html and
http://www.paulgraham.com/popular.html
> Common Lisp wasn't innovative. If I'm
> not mistaken Common Lisp was just a mash-up of many other lisps. While
> some things may have been added which weren't originally there,
> nothing was a spectacular change which couldn't have been easily
> implemented as a "plain thin library" on top of some other lisp.
Others have already responded to that. The most important aspect to me,
though, is that Common Lisp's goals were much more humble than Paul
Graham's goal for Arc:
http://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node6.html#SECTION00510000000000000000
> Honestly, Pascal, Arc's biggest draw isn't what's different from
> scheme or common lisp, it's how it combines the best of both languages
> (at least I think it does). I'm sure you'll disagree on some points,
> like it's lisp-1-ness and various other choices it made, but the idea
> was to combine the two languages. Like how Common Lisp was meant to
> combine the lisps which were available when it was made. I know you
> disagree with a lot about Arc, but to me it's Common Lisp 2, because
> it was designed with the same idea in mind as CL was (despite what pg
> may say).
It doesn't even remotely cover the whole feature set of either Scheme or
Common Lisp.
> Now, you never said you think CL is the hundred year language, so this
> doesn't really prove anything; but what leads you to believe that the
> next 100 year language must necessarily be innovative?
Because 100 years is a very long time. A lot of things may change until
then, including completely unexpected changes. What will survive in the
very long run are the concepts, not the concrete manifestations of the
concepts. What matters are concepts like functional programming, not
concrete functional programming languages; object-oriented programming,
not concrete object-oriented programming languages; imperative
programming, not concrete imperative programming languages; programmable
programming languages, not concrete programmable programming languages.
None of the existing Lisp dialects will still be there in a 100 years
from now. Common Lisp and Scheme won't be there. At least not in the
same form as we know them today. (Maybe the unlikely thing happens that
one of the names survives, but it's likely that it will stand for
something quite different.) New programming paradigms will emerge, and
some currently existing ones will die. Hopefully.
In terms of concepts, there is _nothing_ new in Arc at all. So far.
Yes, it would be nice if the concepts in Arc would still exist in
hundred years from now. But they are exactly the same concepts like in
dozens of other languages. So far.
> Consider some of the most popular programming languages right now:
> Java, C, C++. Were they innovative? No, not really.
I don't care about popularity.
>> BTW, I wouldn't have any problems with Arc if Paul Graham just said what
>> it is: A neat scripting language, without substantially new ideas, like
>> most other neat scripting languages. But he promises much more, and
>> doesn't seem to deliver...
>
> Please ignore everything PG says about Arc. Arc is the programming
> language; Arc is what we are discussing here, not our personal
> feelings toward Mr. Graham, or what kind of ceremony it was released
> with. If you have no problems with Arc, why complain about it so
> avidly?
Because it may do more harm than good.
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/
From: John Thingstad
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <op.t5ys8yn0ut4oq5@pandora.alfanett.no>
P� Sun, 03 Feb 2008 14:47:00 +0100, skrev Pascal Costanza <··@p-cos.net>:
A few points that come to mind:
Destructuring works differently and functions and let also allow
destucturing.
It is implemented in Arc.
The syntax if different so it requires different parsing.
(let x 5 (pr 5))
(with (x 5 y 6) (prf "X=~A,Y~A~%" x y))
prf is a subset of format implemented in arc.
Macro processing is implemented in arc.
You seem to have glanced at ac.scm and jumped to conclusions.
The real work is in arc.arc .
Also the you seem to miss the point. The issue isn't so much which
features to add.
It is to provide a simpler language which is terse but doesn't loose any
of scheme/CL's power.
The real effort is in determining what could be removed. The code has been
continually rewritten to simplify/tersify the language and also the
implementation. It is not easy to come up with a simple yet complete
language.
define-condition and defclass syntax doesn't jive well together with the
terse original lingo car, cons, cond, map etc.. In that sense it is a
attempt to get closer to the language originally envisioned by McCarthy.
--------------
John Thingstad
From: Maciej Katafiasz
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <fo2pv6$dc0$7@news.net.uni-c.dk>
Den Sat, 02 Feb 2008 22:51:21 +0100 skrev Pascal Costanza:
> To put it differently: The introduction of a foreach statement to Java
> was more interesting!
Now, let's be fair: Arc has much more than what foreach introduces.
Callable data structures, composition and lambda shorthands are
definitely more than foreach. I consider Arc extremely disappointing, and
little more than what is routinely done as a part of library development
in CL (like UCW, which has an interpreter *and* a real web development
lib), but comparing it to foreach is just selling it short.
Cheers,
Maciej
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47a50275$0$25045$607ed4bc@cv.net>
Maciej Katafiasz wrote:
> I consider Arc extremely disappointing
How much Arc code have you written?
Thought so.
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <60kf49F1qe7t2U1@mid.individual.net>
Maciej Katafiasz wrote:
> Den Sat, 02 Feb 2008 22:51:21 +0100 skrev Pascal Costanza:
>
>> To put it differently: The introduction of a foreach statement to Java
>> was more interesting!
>
> Now, let's be fair: Arc has much more than what foreach introduces.
> Callable data structures, composition and lambda shorthands are
> definitely more than foreach. I consider Arc extremely disappointing, and
> little more than what is routinely done as a part of library development
> in CL (like UCW, which has an interpreter *and* a real web development
> lib), but comparing it to foreach is just selling it short.
You can't add foreach to Java as a library.
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/
On Jan 29, 4:55 pm, ······@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? What do you think will be the long
> term impact of Arc on CL?
When one reads this thread, he gets the impression that most
users of Common Lisp fervently hope that Arc isn't superior
to CL.
They have have pledged their troth, and they will be true to
The Ultimate Language for ever and ever, blindly and rabidly
attacking all heretics and blasphemers.
Of course, they believe that the user of any other language
should be willing to abandon it at the drop of a hat.
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <6217l2F20a2b7U1@mid.individual.net>
William James wrote:
> On Jan 29, 4:55 pm, ······@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? What do you think will be the long
>> term impact of Arc on CL?
>
> When one reads this thread, he gets the impression that most
> users of Common Lisp fervently hope that Arc isn't superior
> to CL.
>
> They have have pledged their troth, and they will be true to
> The Ultimate Language for ever and ever, blindly and rabidly
> attacking all heretics and blasphemers.
No, they just ask what it is that is superior about Arc, and don't get
an answer. Now, who is the blind believer here?
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/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
> William James wrote:
> > On Jan 29, 4:55 pm, ······@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? What do you think will be the long
> >> term impact of Arc on CL?
> >
> > When one reads this thread, he gets the impression that most
> > users of Common Lisp fervently hope that Arc isn't superior
> > to CL.
> >
> > They have have pledged their troth, and they will be true to
> > The Ultimate Language for ever and ever, blindly and rabidly
> > attacking all heretics and blasphemers.
>
> No, they just ask what it is that is superior about Arc, and don't get
> an answer.
Oh, is that what you want? I'll answer that question: Arc is superior
(to CL at least) because it has a charismatic BDFL who tends to attract
team players. From the point of view of getting real work done that
trumps any technical issues the language may (temporarily) have.
rg
From: Pascal Costanza
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <622p5jF21i4l4U2@mid.individual.net>
Ron Garret wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>
>> William James wrote:
>>> On Jan 29, 4:55 pm, ······@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? What do you think will be the long
>>>> term impact of Arc on CL?
>>> When one reads this thread, he gets the impression that most
>>> users of Common Lisp fervently hope that Arc isn't superior
>>> to CL.
>>>
>>> They have have pledged their troth, and they will be true to
>>> The Ultimate Language for ever and ever, blindly and rabidly
>>> attacking all heretics and blasphemers.
>> No, they just ask what it is that is superior about Arc, and don't get
>> an answer.
>
> Oh, is that what you want? I'll answer that question: Arc is superior
> (to CL at least) because it has a charismatic BDFL who tends to attract
> team players. From the point of view of getting real work done that
> trumps any technical issues the language may (temporarily) have.
I doubt that, but we'll see. (Under this assumption, we might as well
program in Python, or so...)
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/
From: Ken Tilton
Subject: Re: Paul Graham's Arc is released today... what is the long term impact?
Date:
Message-ID: <47bb47e4$0$8059$607ed4bc@cv.net>
j.oke wrote:
> Note 1: did you notice how many newbies are attracted by Arc (away
> from Ruby, Python, ...) ?
I have only contemplated a Road to Arc Survey. I cannot say I see enough
activity to justify one, however.
> Note 2: Arc defines itself simply as a dialect (and not as a
> language).
No sh*t. pg loves Lisp, hates Common Lisp. What were you expecting ARCOBOL?
<sigh>
I hope you are all Patriots fans.
kenny
--
http://smuglispweeny.blogspot.com/
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius