...and Ruby now leads Python by 25%. Googlefight tells all.
Based on a more frivolous indicator (close examination of the language)
I think Arc has a chance to take down CL eventually. It will be a close
call, but Arc has a rock star BDFL and it's Lisp /and/ it has macros
/and/ they are targeting the Web app space (can you say Rails? sher ya
can) so it could easily catch on big time, get a big community fast
leading to lotsa libraries, and once it compiles native... well, CL will
still be better, but not by enough to stop Arc from taking over.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
but the cons business lives!
Xah
On Jan 31, 3:30 am, Ken Tilton <···········@optonline.net> wrote:
> ...and Ruby now leads Python by 25%. Googlefight tells all.
>
> Based on a more frivolous indicator (close examination of the language)
> I think Arc has a chance to take down CL eventually. It will be a close
> call, but Arc has a rock star BDFL and it's Lisp /and/ it has macros
> /and/ they are targeting the Web app space (can you say Rails? sher ya
> can) so it could easily catch on big time, get a big community fast
> leading to lotsa libraries, and once it compiles native... well, CL will
> still be better, but not by enough to stop Arc from taking over.
>
> kt
>
> --http://www.theoryyalgebra.com/
>
> "In the morning, hear the Way;
> in the evening, die content!"
> -- Confucius
On Jan 31, 12:30 pm, Ken Tilton <···········@optonline.net> wrote:
> ...and Ruby now leads Python by 25%. Googlefight tells all.
>
> Based on a more frivolous indicator (close examination of the language)
> I think Arc has a chance to take down CL eventually. It will be a close
> call, but Arc has a rock star BDFL and it's Lisp /and/ it has macros
> /and/ they are targeting the Web app space (can you say Rails? sher ya
> can) so it could easily catch on big time, get a big community fast
> leading to lotsa libraries, and once it compiles native... well, CL will
> still be better, but not by enough to stop Arc from taking over.
>
> kt
>
> --http://www.theoryyalgebra.com/
http://www.googlefight.com/index.php?lang=en_GB&word1=cells&word2=arc
Maybe you should switch to cells instead.
cheers
Slobodan
j.oke wrote:
> On 31 Gen, 12:30, Ken Tilton <···········@optonline.net> wrote:
>
>>let google fight!
>
>
> And 'lst' is more popular than 'list'!
>
> I propose all new Lisps to be lst based. This could possibly save the
> world.
> (Vowels are evil!! Ask PG!)
Peter Gabriel? Paul Graham has (From arc.arc):
(def list args args)
Cute, eh? The equivalent of
(defun my-list (&rest args) args)
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton <···········@optonline.net> writes:
> j.oke wrote:
>> On 31 Gen, 12:30, Ken Tilton <···········@optonline.net> wrote:
>>
>>>let google fight!
>> And 'lst' is more popular than 'list'!
>> I propose all new Lisps to be lst based. This could possibly save
>> the
>> world.
>> (Vowels are evil!! Ask PG!)
>
> Peter Gabriel? Paul Graham has (From arc.arc):
>
> (def list args args)
>
> Cute, eh? [...]
Not really. Too verbose for my taste.
(d l a a) ; would be better.
--
__Pascal Bourguignon__
·························@anevia.com
http://www.anevia.com
Pascal J. Bourguignon wrote:
> Ken Tilton <···········@optonline.net> writes:
>
>
>>j.oke wrote:
>>
>>>On 31 Gen, 12:30, Ken Tilton <···········@optonline.net> wrote:
>>>
>>>
>>>>let google fight!
>>>
>>>And 'lst' is more popular than 'list'!
>>>I propose all new Lisps to be lst based. This could possibly save
>>>the
>>>world.
>>>(Vowels are evil!! Ask PG!)
>>
>>Peter Gabriel? Paul Graham has (From arc.arc):
>>
>>(def list args args)
>>
>>Cute, eh? [...]
>
>
> Not really. Too verbose for my taste.
>
> (d l a a) ; would be better.
That is a reductio adsurbum example that completely misses what Arc is
about. Arc /does/ have def because d would be too short, it /does/ use
list to be more readable.
I think if one wants to be anti-Arc as a CLer the valid target would be
the syntax added to get brevity. PG talked about a language being small
enough to keep it all in one's head. Syntax feels big to me. But PG
talks now about keeping programs short and not so much about supporting
small heads, so...
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Den Fri, 01 Feb 2008 14:21:38 -0500 skrev Ken Tilton:
> Pascal J. Bourguignon wrote:
>> Not really. Too verbose for my taste.
>>
>> (d l a a) ; would be better.
>
> That is a reductio adsurbum example that completely misses what Arc is
> about. Arc /does/ have def because d would be too short, it /does/ use
> list to be more readable.
However, (o foo) and mac are really going too far. (foo . rest) is
pushing it as well. Savings made on shortening "defmacro" (or hell, even
just "macro") to "mac" are purely illusionary. Macros are the hard stuff,
if your typing speed is really the limiting factor in your macrology,
you're definitely doing it wrong. Even more so when reading, you really
don't want to miss the fact that something is a macro. Exactly the same
argument holds for the hideous (o foo) notation, it simply doesn't stand
out enough (and non-trivial optional arguments declarations are
notoriously hard to parse at full speed anyway, even without the extra
added layer of parens coming from o). If you really find &optional
unbearably long, shorten it to &opt, but don't remove the distinctiveness
of &. Not to mention that not supporting keyword arguments is hardly a
nod towards brievity and clarity (which you need all the more in your
super-terse language).
I can't help but think that Arc is pushing for faster travel by painting
speed stripes and removing deadweight such as brakes... except for when
it adds inexplicable bling like the ridiculous let vs. with distinction.
Cheers,
Maciej
Maciej Katafiasz wrote:
> Den Fri, 01 Feb 2008 14:21:38 -0500 skrev Ken Tilton:
>
>
>>Pascal J. Bourguignon wrote:
>>
>>>Not really. Too verbose for my taste.
>>>
>>>(d l a a) ; would be better.
>>
>>That is a reductio adsurbum example that completely misses what Arc is
>>about. Arc /does/ have def because d would be too short, it /does/ use
>>list to be more readable.
>
>
> However, (o foo) and mac are really going too far.
Well, it's like parens, there is no point in offering an opinion until
you have programmed the thing in anger for a month. /Then/ anything that
trips you up or just find unreadable becomes interesting, and not
before, because there is no need for any language to be readable by
someone who does not use it.
A lot of people were bothered by my using c? as the macro to define a
formula for a Cell. I code rules all the time, what is confusing? They
begged me and I produced (c-formula ...). ewwww. But they were happy,
they could show off their touch-typing skills I guess.
Tilton's Law is this: if you use it a lot, you can abbreviate it.
We should continue this after progrmaming Arc for a month.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Den Fri, 01 Feb 2008 15:14:46 -0500 skrev Ken Tilton:
>>>That is a reductio adsurbum example that completely misses what Arc is
>>>about. Arc /does/ have def because d would be too short, it /does/ use
>>>list to be more readable.
>>
>>
>> However, (o foo) and mac are really going too far.
>
> Well, it's like parens, there is no point in offering an opinion until
> you have programmed the thing in anger for a month.
[...]
> We should continue this after progrmaming Arc for a month.
Fair call. I understand you've thus volunteered for a report? :)
Cheers,
Maciej
Maciej Katafiasz wrote:
> Den Fri, 01 Feb 2008 15:14:46 -0500 skrev Ken Tilton:
>
>
>>>>That is a reductio adsurbum example that completely misses what Arc is
>>>>about. Arc /does/ have def because d would be too short, it /does/ use
>>>>list to be more readable.
>>>
>>>
>>>However, (o foo) and mac are really going too far.
>>
>>Well, it's like parens, there is no point in offering an opinion until
>>you have programmed the thing in anger for a month.
>
> [...]
>
>>We should continue this after progrmaming Arc for a month.
>
>
> Fair call. I understand you've thus volunteered for a report? :)
We'll see. I have enjoyed four or more wonderful years doing whatever
damn technology I please but am going broke. It's either Arc and a day
job at Starbucks or Algebra. I might spend a weeked on Arc and the
Giants (forget their opponents' name) before deciding.
kt
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
> We'll see. I have enjoyed four or more wonderful years doing whatever
> damn technology I please but am going broke. It's either Arc and a day
> job at Starbucks or Algebra.
Arc and a day job at Starbucks doesn't sound fun.
Mark
From: Edi Weitz
Subject: Re: Arc already more popular than Python...
Date:
Message-ID: <uir17ta79.fsf@agharta.de>
On Fri, 1 Feb 2008 18:43:30 -0800 (PST), Mark Tarver <··········@ukonline.co.uk> wrote:
>> We'll see. I have enjoyed four or more wonderful years doing
>> whatever damn technology I please but am going broke. It's either
>> Arc and a day job at Starbucks or Algebra.
>
> Arc and a day job at Starbucks doesn't sound fun.
Right. Especially the Arc part.
Edi.
--
European Common Lisp Meeting, Amsterdam, April 19/20, 2008
http://weitz.de/eclm2008/
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
On Feb 2, 1:49 am, Ken Tilton <···········@optonline.net> wrote:
> I have enjoyed four or more wonderful years doing whatever
> damn technology I please but am going broke. It's either Arc and a day
> job at Starbucks or Algebra.
Why does it sound famigliar to me? Hmmm.. Maybe because I'm working on
paip prolog instead on my web project. Oh yes I'm going broke also so
i started looking fo a day job too.
Shame on you Kenny , you should be an example for us. Weren't you
*THE* application programmer of this group. So go make some god damn
application.
Slobodan
Ken Tilton <·········@gmail.com> wrote:
+---------------
| A lot of people were bothered by my using c? as the macro to
| define a formula for a Cell.
+---------------
Right. It obviously should have been c! instead, to remind one
that a "formula" could result in sneaky side-effects to other cells.
Or maybe ·@ for "see at the formula for what it does". Or even c#
[yes, that's a legal identifier] for the visual reference to cells,
though that would *really* confuse the MS weenines. Or c% since you're
"calculating things, like percentages". Or... Or...
+---------------
| Tilton's Law is this: if you use it a lot, you can abbreviate it.
+---------------
And Zipf's Law (q.v.) implies that if you use it a lot,
you *should* abbreviate it.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> Right. It obviously should have been c! instead, to remind one
> that a "formula" could result in sneaky side-effects to other cells.
> Or maybe ·@ for "see at the formula for what it does". Or even c#
> [yes, that's a legal identifier] for the visual reference to cells,
> though that would *really* confuse the MS weenines. Or c% since you're
> "calculating things, like percentages".
> Or... Or...
>
In fact, about the only thing it shouldn't be is c?, because that's
of course how you check if something is c in Scheme.
(define (c? possibly-c) (equal? possibly-c 'c))
(c? 'a) => #f
(c? 'b) => #f
(c? 'c) => #t
(c? 'd) => #f
(c? 'e) => #f
...
Just to annoy further: Actually, my issue with the name is really with
the 'c' more than the '?'
(c-formula ...) is very long yet /still/ fails to shout "this is a cell,
damnit". In fact, it immediately suggests a formula of only c-numbers
[1] to me.
(cell-rule ...) is probably what I would have picked. It would
fuzzy-complete from "cru" in SLIME anyway.
[1] http://en.wikipedia.org/wiki/C-number
David Golden wrote:
> Rob Warnock wrote:
>
>
>>Right. It obviously should have been c! instead, to remind one
>>that a "formula" could result in sneaky side-effects to other cells.
>>Or maybe ·@ for "see at the formula for what it does". Or even c#
>>[yes, that's a legal identifier] for the visual reference to cells,
>>though that would *really* confuse the MS weenines. Or c% since you're
>>"calculating things, like percentages".
>
>
>>Or... Or...
>>
>
>
> In fact, about the only thing it shouldn't be is c?, because that's
> of course how you check if something is c in Scheme.
>
> (define (c? possibly-c) (equal? possibly-c 'c))
>
> (c? 'a) => #f
> (c? 'b) => #f
> (c? 'c) => #t
> (c? 'd) => #f
> (c? 'e) => #f
> ...
>
>
> Just to annoy further: Actually, my issue with the name is really with
> the 'c' more than the '?'
>
> (c-formula ...) is very long yet /still/ fails to shout "this is a cell,
> damnit". In fact, it immediately suggests a formula of only c-numbers
> [1] to me.
>
> (cell-rule ...) is probably what I would have picked. It would
> fuzzy-complete from "cru" in SLIME anyway.
Annoy? This is perfect, this is the difference between A Real Programmer
who Just Did It and you nattering nabobs of negativism with nothing
better to do than hurl tomatos from the cheap seats. You all can fret
over this for another hundred messages, I'll be working. Possibly on
FreeCell.
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
Ken Tilton wrote:
> A lot of people were bothered by my using c? as the macro to define a
> formula for a Cell. I code rules all the time, what is confusing? They
> begged me and I produced (c-formula ...). ewwww. But they were happy,
> they could show off their touch-typing skills I guess.
One of the things that I like about lisp is how rarely I find myself
involved, either as a participant or as an observer, in a debate about
how to format it. This is not true of the C++ to which I am yoked by
the chains of economic necessity. CamelCase vs
underscores_as_separators. Are MACROS the only things which get to yell
at you or are CONSTANTS_LOUD_TOO? IsThis the name of a class or a
function or isThat or it it the_other. "if()" vs "if ()" vs "return
(x)" vs "return x" vs "return(x)". Is pciFoo a better name for "const
int* foo" (or should that be "int const* foo") or is it an abomination?
Should curly brackets always align vertically?
I'm *so* fucking sick of these debates. I'm also sick of the
"reasoning" used to defend the choices. It's always done in the name of
being "more readable" or it makes the "code cleaner" or some other
phrase whose only justification is its own utterance. Of course, these
vague declarations of manifest destiny are usually preferable to
convoluted arguments based in pop physiology. "The human eye tends to
scan yadda yadda and so blather blather is a more natural bullshit
bullshit than this other way of writing it." If I ever quit programming
it will probably be so that I don't have to listen to somebody justify
there personal preference for a variable name or choice of indentation.
Kenny, I give you props for at least being honest and explaining your
dislike of having to use nine keystrokes for "c-formula" instead of two
for "c?" with an argument of the appropriate level of gravitas, "ewww".
> Tilton's Law is this: if you use it a lot, you can abbreviate it.
The thing with abbreviations, though, at least in natural languages, is
that they are an alternative way of spelling something else, and not the
only way of spelling it. One can write either "est" or "established"
but "est" wouldn't be an abbreviation without the "established" behind
it (or should that be in front of it?). But even in "On Lisp", Paul
Graham introduces the macro ABBREV. From these threads here on c.l.l,
I'm starting to get the impression that all we really have is (- (ABBREV
ARC COMMON-LISP) CLOS).
I think that Stroustrup might be sick of all the debates about how to
format his language, too. In _The Design and Evolution of C++_, he writes
<blockquote>
Basing C++ implementations on character-oriented tools has been a major
impediment to progress. [...] dispensing with traditional source text
and basing tools on an abstract internal representation seems to me the
most promising and interesting approach. [...] Naturally, we need text
as input and for people to look at, but such text is easily absorbed
into the system and easily reconstructed upon request. It need not be
fundamental. Text in the C++ syntax formatted according to some
indentation preference is just one of many alternative ways of looking
at a program. The simplest application of this notion is to allow you
to look at a program using your preferred layout style while I at the
same time can look at the same program using my preferences.
A significant use of a non-textual representation would be as a target
for code generation from higher-level languages, program generators,
direct manipulation tools, etc.
</blockquote>
It seems to me that Lisp is already very close to basing itself on "an
abstract internal representation" called the sexp. When Stroustrup
mentions wishing for something that would work well with "program
generators", Lisp already has macros. Lisp also already defines the
reader and printer, which converts between textual representations and
the internal structure in a way which is available to the programmer as
a tool instead of simply being an implementation detail of the compiler.
Personally, I wish that somebody would have taken all the resources
devoted to Arc to create the Lisp version of what Stroustup wants for
the future of C++. (That's a fun train wreck of a collision of a bunch
of ideas which should probably be uncomfortable if they all had to sit
at the same table at a party.) It seems to me that some kind of symbol
translation could be added into the textual manipulation done by
read/print. That way, Kenny would write lots of code with "c?" and send
it to all the ewww yobbos who would load it into this system. They
would then automagically see it presented to them as "c-formula" without
even needing to know that he had used the tainted "c?". After making a
few updates, they could send it back to Kenny, who would be quite
content with "c?", and wouldn't even have to know that someone else had
decided to waste there time with all that extra characterage. And it
seems to me that something like a climacs would be the perfect place to
do something like this. Lisp written as Arc in a Lisp editor written in
Lisp using all the tools of Lisp to write Lisp as Arc. But best of all,
then *I* would never have to be either a witness or participant in yet
another useless debate about what to name a variable or how to indent a
chunk of code.
> We should continue this after progrmaming Arc for a month.
I'm glad you're volunteering to be the canary in this coal mine. The
last time I spent a lot of time in Paul Graham's world was reading _ANSI
Common Lisp_ to try and learn more about Lisp. It left me wanting to
write 'lst' instead of 'list' and wanting to write recursive functions
for everything while fearing LOOP. It took me a couple of months in
rehab at c.l.lisp to clean and a dose of _Practical Common Lisp_ to
clean those toxins from my system.
Damien Kick wrote:
> Ken Tilton wrote:
>
>> A lot of people were bothered by my using c? as the macro to define a
>> formula for a Cell. I code rules all the time, what is confusing? They
>> begged me and I produced (c-formula ...). ewwww. But they were happy,
>> they could show off their touch-typing skills I guess.
c? would fail my "can I grep for it" test. It is too likely to be
a substring of a thing I am not grepping for. But whatever. I'm
not such a fan of verbosity provided that test is met.
> One of the things that I like about lisp is how rarely I find myself
> involved, either as a participant or as an observer, in a debate about
> how to format it.
Mostly because Emacs has strong ideas about formatting lisp code and
the only real choice for an emacs-using lisper is between which tokens
to insert linefeeds. I would guess that 90% of all publicly-available
lisp code (even in other dialects) is formatted according to emacs
conventions.
> Kenny, I give you props for at least being honest and explaining your
> dislike of having to use nine keystrokes for "c-formula" instead of two
> for "c?" with an argument of the appropriate level of gravitas, "ewww".
Heh. Me too.
> It seems to me that some kind of symbol
> translation could be added into the textual manipulation done by
> read/print. That way, Kenny would write lots of code with "c?" and send
> it to all the ewww yobbos who would load it into this system. They
> would then automagically see it presented to them as "c-formula" without
> even needing to know that he had used the tainted "c?". After making a
> few updates, they could send it back to Kenny, who would be quite
> content with "c?", and wouldn't even have to know that someone else had
> decided to waste there time with all that extra characterage.
The problem with this idea is that we don't use names just to
communicate between the programmer and the system, but also between
programmers. Sooner or later Kenny would get an email from somebody
who wanted permission to do something with "c-formula" and he'd have
no idea what that name referred to. Worse yet, Kenny himself might
be using "c-formula" to stand for something he uses very seldom, for
a different purpose, possibly in a different system, and think that
he does know what the name refers to, only to be blindsided by the
forthcoming code change affecting "c?" which he uses all the time.
Bear
Den Sat, 02 Feb 2008 10:54:45 -0800 skrev Ray Dillinger:
>>> A lot of people were bothered by my using c? as the macro to define a
>>> formula for a Cell. I code rules all the time, what is confusing? They
>>> begged me and I produced (c-formula ...). ewwww. But they were happy,
>>> they could show off their touch-typing skills I guess.
>
> c? would fail my "can I grep for it" test. It is too likely to be a
> substring of a thing I am not grepping for. But whatever. I'm not such
> a fan of verbosity provided that test is met.
\bc\?\b
HTH,
Maciej
Ray Dillinger wrote:
> Damien Kick wrote:
>> It seems to me that some kind of symbol
>> translation could be added into the textual manipulation done by
>> read/print. [...]
>
> The problem with this idea is that we don't use names just to
> communicate between the programmer and the system, but also between
> programmers. Sooner or later Kenny would get an email from somebody
> who wanted permission to do something with "c-formula" and he'd have
> no idea what that name referred to. Worse yet, Kenny himself might
> be using "c-formula" to stand for something he uses very seldom, for
> a different purpose, possibly in a different system, and think that
> he does know what the name refers to, only to be blindsided by the
> forthcoming code change affecting "c?" which he uses all the time.
Unfortunately, you make a very good point about names communicating
information between programmers and how everyone using a different name
for the same thing would get confusing. But as something of a counter
example, in the world of trading (stocks, options, etc.), not every
exchange uses the same ticker symbol for a particular instrument.
Reuters, for example, might refer to an instrument as "x" while the
NASDAQ might refer to it as "X" or even "Y", though I can't think of any
particular examples of the names differing by anything other than case
off the top of my head. However, traders who deal with multiple
exchanges are able to apply the appropriate context when using ticker
symbols to name instruments. This kind of thing probably would not
scale well to the number of symbols used in a Lisp program if there was
absolutely no constraints on how any one programmer would define a
symbol translation for any particular symbol, though. However, even the
existing Lisp package system allows for one "canonical" package name and
a number of different nicknames. With a similar constraint for these
hypothetical symbol translations, I think that one would be able to come
up with something rather workable.
Of course, I am not likely to put up so I should probably shut up.
Besides, all of the lisp editors/IDEs with which I've played have some
kind of symbol completion and that tends to work just fine for me.
Looks like we all still get to argue about which names are too long and
which names are too short, which names should have 'p's or 'n's or 'f's
or '?'s or '!'s. Lucky us. At least the default readtable for lisp is
case converting so that we don't have to argue (not very often at least
anyway) about all the CamelCaseNonsense.
On Feb 1, 8:21 pm, Ken Tilton <···········@optonline.net> wrote:
> Pascal J. Bourguignon wrote:
> > Ken Tilton <···········@optonline.net> writes:
> >>(def list args args)
>
> >>Cute, eh? [...]
>
> > Not really. Too verbose for my taste.
>
> > (d l a a) ; would be better.
>
> That is a reductio adsurbum example that completely misses what Arc is
> about.
Nah, that's just the logical evolutionary goal of brevity for
brevity's sake, and it's called MUMPS. ;-)
Christopher Koppler wrote:
> On Feb 1, 8:21 pm, Ken Tilton <···········@optonline.net> wrote:
>
>>Pascal J. Bourguignon wrote:
>>
>>>Ken Tilton <···········@optonline.net> writes:
>>>
>>>>(def list args args)
>>
>>>>Cute, eh? [...]
>>
>>>Not really. Too verbose for my taste.
>>
>>>(d l a a) ; would be better.
>>
>>That is a reductio adsurbum example that completely misses what Arc is
>>about.
>
>
> Nah, that's just the logical evolutionary goal of brevity for
> brevity's sake, and it's called MUMPS. ;-)
You have not seen K. :)
kenny
--
http://www.theoryyalgebra.com/
"In the morning, hear the Way;
in the evening, die content!"
-- Confucius
On Sat, 02 Feb 2008 01:48:05 -0500, Ken Tilton
<···········@optonline.net> wrote:
>
>
>Christopher Koppler wrote:
>> On Feb 1, 8:21 pm, Ken Tilton <···········@optonline.net> wrote:
>>
>>>Pascal J. Bourguignon wrote:
>>>
>>>>Ken Tilton <···········@optonline.net> writes:
>>>>
>>>>>(def list args args)
>>>
>>>>>Cute, eh? [...]
>>>
>>>>Not really. Too verbose for my taste.
>>>
>>>>(d l a a) ; would be better.
>>>
>>>That is a reductio adsurbum example that completely misses what Arc is
>>>about.
>>
>>
>> Nah, that's just the logical evolutionary goal of brevity for
>> brevity's sake, and it's called MUMPS. ;-)
>
>You have not seen K. :)
>
>kenny
Or BrainFuck. http://www.muppetlabs.com/~breadbox/bf/
George
--
for email reply remove "/" from address
On Feb 1, 8:29 pm, Christopher Koppler <········@chello.at> wrote:
> On Feb 1, 8:21 pm, Ken Tilton <···········@optonline.net> wrote:
>
> > Pascal J. Bourguignon wrote:
> > > Ken Tilton <···········@optonline.net> writes:
> > >>(def list args args)
>
> > >>Cute, eh? [...]
>
> > > Not really. Too verbose for my taste.
>
> > > (d l a a) ; would be better.
>
> > That is a reductio adsurbum example that completely misses what Arc is
> > about.
>
> Nah, that's just the logical evolutionary goal of brevity for
> brevity's sake, and it's called MUMPS. ;-)
I thought mumps was awesome!!!
Den Sat, 02 Feb 2008 16:04:48 -0800 skrev gavino:
>> > That is a reductio adsurbum example that completely misses what Arc
>> > is about.
>>
>> Nah, that's just the logical evolutionary goal of brevity for brevity's
>> sake, and it's called MUMPS. ;-)
>
> I thought mumps was awesome!!!
Okay, you impostor, what did you do with the real gavino? Give him back
at once!
Concerned,
Maciej
j.oke wrote:
> On 31 Gen, 12:30, Ken Tilton <···········@optonline.net> wrote:
>> let google fight!
>
> And 'lst' is more popular than 'list'!
>
> I propose all new Lisps to be lst based. This could possibly save the
> world.
> (Vowels are evil!! Ask PG!)
It's true. UNIX hates vowels and see how much more popular UNIX is than
Lisp machines.