Hi. Im an 18 year old student who have programming as a hobby. I know C++
and Java and have made some programs in Visual Basic. I am interested in
trying to learn some lisp. Not because I have any applications suited for
it, but because I want to try something new.
I wondered if you have any recomendations on tutorials for lisp and any
sugestions for a compiler and linker. I cannot afford a too expensive
software kit, but then I will not need the most advanced or cutting edge
tools.
I simply want to make some simple applications and play around with the
language.
Thankful in advance:
Jonatan Ring
"Jonatan Ring" <········@online.no> writes:
> Forgot to mention that I am using Windows ME.
ICK...
Try the demo's at lispworks(www.lispworks.com) or franz(www.franz.com) or
corman lisp(http://www.cormanlisp.com/).
marc
> > Forgot to mention that I am using Windows ME.
Sorry to hear that ... really!
I really like Clisp on cygwin on win32 although its available as a native
windoze executable. http://clisp.cons.org/ . A lot of lispers, especially
anyone on Debian like CMU CL which is also free. You should find a
lot of links at http://www.alu.org/ as well.
Emacs is a must have for almost any lisper if you are planning on using
any of the free lisps. Get emacs, learn some basic keystrokes, get and
configure Ilisp and you should be good to go.
Setting up Ilisp with Emacs step by step. Follow the guide and it should
help you get started.
http://cl-cookbook.sourceforge.net/windows.html
You can try some of the commercial IDE's like Allegro CL as well. It
will give you a more VB like look and feel to design screens etc. The
Lispworks free stuff is ok to play with for about 4 hours. The you lose
everything.
http://www.franz.com/
And if you are a or planning to be a professional programmer/hacker
then I would advise you to not learn Lisp. After working in any flavor
of CL, you would probably find working in anything else suffocating
and lacking in power and it only becomes frustrating. That happens to
Smalltalk programmers moving to Java as well.
Good luck with your experiences.
Take Care
> Sorry to hear that ... really!
Yeah, it hangs all the time, and it sucks in other ways too. It is not my
computer, however, and hence I have little choice but to use the crappy
windows version (unless I manage to knock some sense into my father who fear
that all programes will fail to work at XP due to lack of backward
compatability)
"Jonatan Ring" <········@online.no> writes:
> Hi. Im an 18 year old student who have programming as a hobby. I
> know C++ and Java and have made some programs in Visual Basic. I am
> interested in trying to learn some lisp. Not because I have any
> applications suited for it, but because I want to try something new.
>
> I wondered if you have any recomendations on tutorials for lisp and
> any sugestions for a compiler and linker. I cannot afford a too
> expensive software kit, but then I will not need the most advanced
> or cutting edge tools.
>
> I simply want to make some simple applications and play around with
> the language.
>
> Thankful in advance:
A good decision, congratulations! It'll certainly broaden your
horizon. (See Raymond quote below.)
If you're on Windows my personal recommendation would be to start with
the free "Personal Edition" of LispWorks from Xanalys which is
available for download at
<http://www.lispworks.com/products/lww.html>.
Other high-quality commercial Lisps which offer free trial versions
for Windows are AllegroCL by Franz, Inc. <http://www.franz.com/> and
Corman Lisp <http://www.cormanlisp.com/>. A "free" (GPL) alternative
is CLISP <http://clisp.sf.net/> but it currently doesn't offer
a graphical IDE.
Other platforms (notably Linux and Mac OS X) will offer even more
choice of implementations but this should be enough to start with.
Some people are concerned by the fact that some of the commercial
trial version are "crippled" (i.e. they have limited heap size or may
have to be manually re-licensed every couple of months) and/or won't
create "stand-alone" executables (EXEs) but that shouldn't be a
problem if you just want to learn the language.
A list of freely available online Lisp tutorials and other sources of
information can be found at the bottom of
<http://cl-cookbook.sourceforge.net/>
but I'd recommend you start with a good book (maybe your local library
has one or can get it for you) like Paul Graham's "ANSI Common Lisp"
or Steven Slade's "Object-oriented Common Lisp". A very good second
book would be Peter Norvig's "Artificial Intelligence Programming -
Case Studies in Common Lisp".
Make sure to visit CLiki <http://www.cliki.net/> from time to time to
see which Lisp-related libraries and documents are available online.
For a Windows user this might also be interesting
<http://cl-cookbook.sourceforge.net/windows.html>,
although you might prefer the IDEs which come with LispWorks or
AllegroCL.
Good luck,
Edi.
"Lisp is worth learning for the profound enlightenment experience you
will have when you finally get it; that experience will make you a
better programmer for the rest of your days, even if you never
actually use Lisp itself a lot."
- Eric Raymond, "How to Become a Hacker"
Edi Weitz <···@agharta.de> wrote:
> A "free" (GPL) alternative
> is CLISP <http://clisp.sf.net/> but it currently doesn't offer
> a graphical IDE.
...but one that can be used with it does exist:
http://jabberwocky.sourceforge.net/
Cheers,
-- Nikodemus
I see I have some to chose from here.
I read an online introduction, and I gotta say that this looks nothin like
any other programming language I've ever seen. =)
Thanks
Jonatan Ring wrote:
> I see I have some to chose from here.
> I read an online introduction, and I gotta say that this looks nothin like
> any other programming language I've ever seen. =)
Yeah, and aren't () prettier than ,[;*%}^&? <g>
Hey, I'm doing an informal survey of any newbie I run into:
1. How did you pick Lisp when you went looking for something new?
2. And why not, say, Python or Ruby?
3. Any particular reason you were looking for something new to learn?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
>Yeah, and aren't () prettier than ,[;*%}^&? <g>
Well, I dont know about prettier, but its certainly smoother.
> 1. How did you pick Lisp when you went looking for something new?
I was looking for articles about AI and I run into a site which mentioned
LISP as the programmable programming language. Not that I plan to create an
AI or something, I just thought the language sounded interesting. One reason
I found LISP appealing may have been the fact that I recently read G�del
Esher Bash, an Eternal Golden Braid, which dealt among other things with the
difference between a programme and the data (sounds familiar?). When I read
about the way LISP worked I immediatly came to think of this book (which btw
is a masterpiece, I recomend anyone who like logic and/or mathematics to
read it).
> 2. And why not, say, Python or Ruby?
First of all, I havnt heard of neither Python nor Ruby ( Did I just reveal a
complete lack of programming skills or knowledge here?), also I found the
flexibility in LISP to be atractive. I dont know how many times Ive been
anoyed bye the fact that I cant create my own operators, symbols, keywords
and the like in C++.
> 3. Any particular reason you were looking for something new to learn?
I got to hear about LISP, and since it sounded interesting I decided to try
it.
Jonatan Ring wrote:
>>Yeah, and aren't () prettier than ,[;*%}^&? <g>
>
>
> Well, I dont know about prettier, but its certainly smoother.
Indeed. I like that:
"Parentheses, the Aerodynamically-efficient Delimiters"
>
>
>>1. How did you pick Lisp when you went looking for something new?
>
> I was looking for articles about AI and I run into a site which mentioned
> LISP as the programmable programming language. Not that I plan to create an
> AI or something,
Yeah, my interest in AI was also why I heard about Lisp the very first
time back in the late 70's when I was shopping my first microcomputer. I
even ended snagging a Lisp 1.5 Manual from one of the little hobby shops.
> I just thought the language sounded interesting. One reason
> I found LISP appealing may have been the fact that I recently read G�del
> Esher Bach, an Eternal Golden Braid, which dealt among other things with the
> difference between a programme and the data (sounds familiar?). When I read
> about the way LISP worked I immediatly came to think of this book
Nice catch, as we baseballers say.
>>2. And why not, say, Python or Ruby?
>
> First of all, I havnt heard of neither Python nor Ruby ( Did I just reveal a
> complete lack of programming skills or knowledge here?)
LOL. No, just great luck. :) One Lisp guru argues Python is just like
Lisp, but he is just sucking up to the Pythonistas so he can sell more
books.
Thanks for responding, and thanks also for the email I got from someone
who saw my survey and offered his answers.
I thought of some additional questions, some of which might be "not
applicable":
> If you had heard Bad Things about Lisp, what were they and why did
you look at Lisp anyway?
> If you have now had a chance to get familiar with Lisp, what are your
first impressions?
This process would be easier if I could just add a Survey thing to Cliki
-- I gather that Ikis work that way, yes? I could just go over there and
add a survey page? True that? Good idea?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> >>2. And why not, say, Python or Ruby?
> > First of all, I havnt heard of neither Python nor Ruby ( Did I just reveal
> > a complete lack of programming skills or knowledge here?)
>
> LOL. No, just great luck. :) One Lisp guru argues Python is just like Lisp,
> but he is just sucking up to the Pythonistas so he can sell more books.
I find your attitude disgusting.
To the OP:
http://www.norvig.com/python-lisp.html
'as
Alexander Schmolck wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
>
>
>>>>2. And why not, say, Python or Ruby?
>>>
>>>First of all, I havnt heard of neither Python nor Ruby ( Did I just reveal
>>>a complete lack of programming skills or knowledge here?)
>>
>>LOL. No, just great luck. :) One Lisp guru argues Python is just like Lisp,
>>but he is just sucking up to the Pythonistas so he can sell more books.
>
>
> I find your attitude disgusting.
>
OK, OK, if Marc can do it I can do it:
Sorry, Peter, I should have had a <g> in there.
> To the OP:
>
> http://www.norvig.com/python-lisp.html
>
From that link: "I looked into Python because I was considering
translating the Lisp code for the Russell & Norvig AI textbook into
Java. Some instructors and students wanted Java..."
Java would not hunt, so he ended up with Python:
"Python supports all of Lisp's essential features except macros, and you
don't miss macros all that much because it does have eval, and operator
overloading, and regular expression parsing, so you can create custom
languages that way."
Puh-lease. That does not seem like a reach to you?
But the reason I should have had a smiley in there is that I
wholeheartedly endorse doing whatever it takes to reach the unsaved
and/or make money, witness my own attempt to find a bigger audience for
Cells by porting it to... wait for it... Python! (And Java, and C++...)
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
"Kenny Tilton" <·······@nyc.rr.com> wrote in message ·····················@nyc.rr.com...
> > First of all, I havnt heard of neither Python nor Ruby ( Did I just reveal a
> > complete lack of programming skills or knowledge here?)
>
> LOL. No, just great luck. :) One Lisp guru argues Python is just like
> Lisp, but he is just sucking up to the Pythonistas so he can sell more
> books.
Do you always try to hurt people like this?
Flippant self projection.
Wade
Wade Humeniuk wrote:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message ·····················@nyc.rr.com...
>
>>>First of all, I havnt heard of neither Python nor Ruby ( Did I just reveal a
>>>complete lack of programming skills or knowledge here?)
>>
>>LOL. No, just great luck. :) One Lisp guru argues Python is just like
>>Lisp, but he is just sucking up to the Pythonistas so he can sell more
>>books.
>
>
> Do you always try to hurt people like this?
My playful dig was aimed at Norvig the public figure. You and Alexander
are the ones making it personal. When you hear sports announcers
shredding a failed athlete, do you worry that the athlete's mother might
be watching? I do, when the commentary gets especially brutal, but then
I remind myself that such are the vicissitudes of a public life.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
> If you have now had a chance to get familiar with Lisp, what are your
first impressions?
Since Ive programmed much in C++ it seems to me that lisp is more "liberal"
when it comes to type controll and type casting. I also find the prefix
notation of the arithmic operators to be a bit anoying, however I suspect
there is a good reason why all functions must be the first element in a list
( I woant start any "religious war" here, will I?
The main difference is however the freedom in choice of symbols, names and
values. I also was really happy when I saw that there is support for
fractional numbers ( I will not have to use floating point numbers, which I
considder "ugly". : - )
Or for short:
(defun like (person language)
(If (eql person Jonatan)
(If (eql language LISP)
'T
'())
'()))
Jonatan Ring wrote:
> > If you have now had a chance to get familiar with Lisp, what are your
> first impressions?
>
> Since Ive programmed much in C++ it seems to me that lisp is more "liberal"
> when it comes to type controll and type casting.
Oh, yeah. But lispniks like to point out that at runtime Lisp is pretty
fussy over types. The C++ crowd used to say that was not good enough,
but they seem to be coming around to the idea that if they can program
an order of magnitude faster with a more "liberal" language, that gives
them more than enough time to test to find the bugs strong static typing
is meant to head off.
> I also find the prefix
> notation of the arithmic operators to be a bit anoying, however I suspect
> there is a good reason why all functions must be the first element in a list
> ( I woant start any "religious war" here, will I?
heh-heh, nope, but i think you can expect some of the better-informed
lispniks to fill you in on the details of why prefix notation roolz. you
don't need your asbestos shorts, but you do need to take notes, this
/will/ be on the test.
> The main difference is however the freedom in choice of symbols, names and
> values. I also was really happy when I saw that there is support for
> fractional numbers ( I will not have to use floating point numbers, which I
> considder "ugly". : - )
oh, well if you are into numbers, how about the seamless jump to bignums
when your integers try to overflow?
>
> Or for short:
>
> (defun like (person language)
> (If (eql person Jonatan)
> (If (eql language LISP)
> 'T
> '())
> '()))
ahem:
(defun like (person language)
(and (eq person 'jonatan) (eq language 'lisp)))
If you care about case, it's '|Jonatan| and '|Lisp|. LISP (all caps,
that is) is deprecated.
Thx again for the survey responses.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
"Jonatan Ring" <········@online.no> writes:
> > If you have now had a chance to get familiar with Lisp, what are your
> first impressions?
>
> Since Ive programmed much in C++ it seems to me that lisp is more "liberal"
> when it comes to type controll and type casting.
What do you mean "liberal" ?
Even compiled with g++ instead of gcc:
-----------------------------(test.c++)-----------------------------------
#include <stdio.h>
int main(void)
{
printf("\"toto\"+2=%d\n","toto"+2);
return(0);
}
------------------------------------------------------------------------
% g++ -o test++ test.c++ ; ./test++
"toto"+2=134513910
While:
% clisp -q
[1]> (+ "toto" 2)
*** - argument to + should be a number: "toto"
And for type casting, I don't know what it is in Lisp. I don't think
it's possible to cast anything. The closest I find in CLHS is COERCE:
[3]> (coerce "toto" 'integer)
*** - COERCE: "toto" cannot be coerced to type INTEGER
1. Break [4]>
[5]> (coerce 1/3 'integer)
*** - COERCE: 1/3 cannot be coerced to type INTEGER
1. Break [6]>
Do you call that "liberal" ???
> I also find the prefix
> notation of the arithmic operators to be a bit anoying, however I suspect
> there is a good reason why all functions must be the first element in a list
> ( I woant start any "religious war" here, will I?
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
Pascal Bourguignon wrote:
> "Jonatan Ring" <········@online.no> writes:
>
>
>> > If you have now had a chance to get familiar with Lisp, what are your
>>first impressions?
>>
>>Since Ive programmed much in C++ it seems to me that lisp is more "liberal"
>>when it comes to type controll and type casting.
>
>
> What do you mean "liberal" ?
I at any rate took the first bit to mean strong compile-time checking.
Not sure about the casting, esp. since that actually lets one sneak
around the former (speaking loosely, I'm no C expert and spent about a
day on C++ before busting a gut laughing).
>
> Even compiled with g++ instead of gcc:
> -----------------------------(test.c++)-----------------------------------
> #include <stdio.h>
> int main(void)
> {
> printf("\"toto\"+2=%d\n","toto"+2);
> return(0);
> }
> ------------------------------------------------------------------------
> % g++ -o test++ test.c++ ; ./test++
> "toto"+2=134513910
Is that a good example? "toto" is syntactic sugar for a pointer to a
string, ie char*, and addition is a well-defined operation on pointers.
It only looks like a string is being added to an integer.
Mind you, this is just a quibble. Lisp indeed has that perfect mix of
letting me work without demanding type declarations at coding-time, then
enforcing types strictly at runtime.
//EOPREACHINGTOTHECHOIR
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In article <···················@news4.e.nsc.no>,
"Jonatan Ring" <········@online.no> wrote:
>One reason
>I found LISP appealing may have been the fact that I recently read G�del
>Esher Bash, an Eternal Golden Braid, which dealt among other things with the
>difference between a programme and the data (sounds familiar?). When I read
>about the way LISP worked I immediatly came to think of this book (which btw
>is a masterpiece, I recomend anyone who like logic and/or mathematics to
>read it).
Hofstadter also waxes enthusiastic about Lisp in three chapters of
his fantastic "Metamathematical Themas" -- specifically, pp. 396-
454.
{Hofstadter mentions in one of his books that he spent a year
hanging out at MIT and chatting with Minsky. Out of curiosity,
what was his relationship (if any) to the local hacker culture?)
sv0f <····@vanderbilt.edu> writes:
> Hofstadter also waxes enthusiastic about Lisp in three chapters of
> his fantastic "Metamathematical Themas" -- specifically, pp. 396-
> 454.
Could it be "Metamagical Themas: Questing for the Essence of Mind and
Pattern"?
"Lars Brinkhoff" <·········@nocrew.org> wrote in message ···················@junk.nocrew.org...
> sv0f <····@vanderbilt.edu> writes:
> > Hofstadter also waxes enthusiastic about Lisp in three chapters of
> > his fantastic "Metamathematical Themas" -- specifically, pp. 396-
> > 454.
>
> Could it be "Metamagical Themas: Questing for the Essence of Mind and
> Pattern"?
I suppose all math fans know how the title 'Metamagical Themas' came to be.
--
Geoff
"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> "Lars Brinkhoff" <·········@nocrew.org> wrote in message ···················@junk.nocrew.org...
> > sv0f <····@vanderbilt.edu> writes:
> > > Hofstadter also waxes enthusiastic about Lisp in three chapters of
> > > his fantastic "Metamathematical Themas" -- specifically, pp. 396-
> > > 454.
> >
> > Could it be "Metamagical Themas: Questing for the Essence of Mind and
> > Pattern"?
>
> I suppose all math fans know how the title 'Metamagical Themas' came to be.
Can you say: "Martin Gardener"?
--
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
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
>"Geoffrey Summerhayes" <·············@hotmail.com> writes:
>
>> "Lars Brinkhoff" <·········@nocrew.org> wrote in message
>> ···················@junk.nocrew.org...
>> > sv0f <····@vanderbilt.edu> writes:
>> > > Hofstadter also waxes enthusiastic about Lisp in three chapters of
>> > > his fantastic "Metamathematical Themas" -- specifically, pp. 396-
>> > > 454.
>> >
>> > Could it be "Metamagical Themas: Questing for the Essence of Mind and
>> > Pattern"?
>>
>> I suppose all math fans know how the title 'Metamagical Themas' came to be.
>
>Can you say: "Martin Gardener"?
Yeah, but I pronouned it "Mathematical Games" ;-)
sv0f <····@vanderbilt.edu> writes:
> In article <·············@beta.franz.com>,
> Duane Rettig <·····@franz.com> wrote:
>
> >"Geoffrey Summerhayes" <·············@hotmail.com> writes:
> >
> >> "Lars Brinkhoff" <·········@nocrew.org> wrote in message
> >> ···················@junk.nocrew.org...
> >> > sv0f <····@vanderbilt.edu> writes:
> >> > > Hofstadter also waxes enthusiastic about Lisp in three chapters of
> >> > > his fantastic "Metamathematical Themas" -- specifically, pp. 396-
> >> > > 454.
> >> >
> >> > Could it be "Metamagical Themas: Questing for the Essence of Mind and
> >> > Pattern"?
> >>
> >> I suppose all math fans know how the title 'Metamagical Themas' came to be.
> >
> >Can you say: "Martin Gardener"?
>
>
> Yeah, but I pronouned it "Mathematical Games" ;-)
M. G. / M. G. Same difference. Gardener was like that...
--
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
In article <·············@beta.franz.com>,
Duane Rettig <·····@franz.com> wrote:
>sv0f <····@vanderbilt.edu> writes:
>
>> In article <·············@beta.franz.com>,
>> Duane Rettig <·····@franz.com> wrote:
>>
>> >"Geoffrey Summerhayes" <·············@hotmail.com> writes:
>> >>
>> >> I suppose all math fans know how the title 'Metamagical Themas' came to
>> >> be.
>> >
>> >Can you say: "Martin Gardener"?
>>
>>
>> Yeah, but I pronouned it "Mathematical Games" ;-)
>
>M. G. / M. G. Same difference. Gardener was like that...
Sorry to be obtuse. What I meant was: Hofstadter titled
his column "Metamagical Themas" as an homage to Gardner's
"Mathematical Games" -- the two are anagrams of one
another! See the preface to Hofstadter's book.
sv0f <····@vanderbilt.edu> writes:
> Sorry to be obtuse. What I meant was: Hofstadter titled
> his column "Metamagical Themas" as an homage to Gardner's
> "Mathematical Games" -- the two are anagrams of one
> another! See the preface to Hofstadter's book.
Right. This always stuck in my brain as a nice choice. What's really
cool about this is that he thought to do it at all. Once you decide to
do an anagram, it falls out pretty naturally as the best of the available
choices. ... Although there are quite a number of other options he had
to get past. Just even pushing it around by hand for a few minutes,
I see:
A Magic Math Set Meal
A Math Mage Claim Set
Cage That AM Sea Mail
Malice At The Magmas
State Hemic Amalgam
and my personal favorite:
Ma, I'm at the CL age. --Sam
I believe it is "Gardner". I also believe he "is" like that. I almost
had to call the ambulance when I read "was", Duane. I'm hoping the
rumor was greatly exaggerated.
http://www.mathsnet.net/resource/martingardner.html
The first several Google pages had no bad news and news.google.com found
nothing.
Jeff
Duane Rettig wrote:
...
>>>Can you say: "Martin Gardener"?
>>
>>
>>Yeah, but I pronouned it "Mathematical Games" ;-)
>
>
> M. G. / M. G. Same difference. Gardener was like that...
>
Jeff Caldwell <·····@yahoo.com> writes:
> I believe it is "Gardner". I also believe he "is" like that. I almost
> had to call the ambulance when I read "was", Duane. I'm hoping the
> rumor was greatly exaggerated.
>
>
> http://www.mathsnet.net/resource/martingardner.html
>
> The first several Google pages had no bad news and news.google.com
> found nothing.
Ah, yes, my memory fails me. It was, however, over 20 years ago -
I had also thought he had passed on, but it must have been someone
else I had been thinking of.
Interestingly, you get quite a few hits from "Martin Gardener", but
a little indirection will take you finally to the correct spellings,
indirection that I had not bothered to do. Sorry about that...
--
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
"Kenny Tilton" <·······@nyc.rr.com> wrote in message
·····················@nyc.rr.com...
>
>
> Yeah, and aren't () prettier than ,[;*%}^&? <g>
>
Yes, but I do miss the simple days of being able to do:
screen->BitsPerPixel
instead of (In Corman Lisp, when dealing with the FFI):
(ct:cref SDL_PixelFormat (ct:cref SDL_Surface screen format) BitsPerPixel))
There is still something to be said for infix notation.
> Hey, I'm doing an informal survey of any newbie I run into:
>
> 1. How did you pick Lisp when you went looking for something new?
I read "Ask Kent M. Pitman about Lisp" on Slashdot
> 2. And why not, say, Python or Ruby?
Tried Ruby, liked it, even bought the book. Thought my scripts ran too slow
though.
> 3. Any particular reason you were looking for something new to learn?
Looking for the next big thing. Seem to have found it. (Except for -> ,
which I really, really miss)
-Luke
In article <·······················@twister.socal.rr.com>, "Luke J Crook"
<····@NO-SPAM.balooga.com> wrote:
> There is still something to be said for infix notation.
...
> Looking for the next big thing. Seem to have found it. (Except for -> ,
> which I really, really miss)
I have good news for you: if you really want infix syntax in Lisp you can
have it. However, I'd start out with something like this:
(defmacro -> (object slot-name)
`(slot-value ,object ',slot-name))
If that doesn't do it for you, there are various infix parsers available. See:
http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/
E.
"Erann Gat" <···@jpl.nasa.gov> wrote in message
·························@192.168.1.51...
> In article <·······················@twister.socal.rr.com>, "Luke J Crook"
> <····@NO-SPAM.balooga.com> wrote:
>
> > Looking for the next big thing. Seem to have found it. (Except for -> ,
> > which I really, really miss)
>
> I have good news for you: if you really want infix syntax in Lisp you can
> have it. However, I'd start out with something like this:
It's not that I am completely against prefix notation. It's just that after
a couple of months of using Lisp on and off, I still feel as though some
things are specified backwards. But this is probably just years of ingrained
C/Java/COBOL.
Now that I'm on the subject of backwards.... Is there a reason for NTH being
different to all the other accessors ?
(nth 1 a-list)
(elt a-list 1)
(aref an-array 1)
> If that doesn't do it for you, there are various infix parsers available.
See:
>
>
http://www-2.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/code/syntax/
>
Thanks very much.
-Luke
"Luke J Crook" <····@NO-SPAM.balooga.com> writes:
> "Erann Gat" <···@jpl.nasa.gov> wrote in message
> ·························@192.168.1.51...
> > In article <·······················@twister.socal.rr.com>, "Luke J Crook"
> > <····@NO-SPAM.balooga.com> wrote:
> >
> > > Looking for the next big thing. Seem to have found it. (Except for -> ,
> > > which I really, really miss)
> >
> > I have good news for you: if you really want infix syntax in Lisp you can
> > have it. However, I'd start out with something like this:
>
> It's not that I am completely against prefix notation. It's just that after
> a couple of months of using Lisp on and off, I still feel as though some
> things are specified backwards. But this is probably just years of ingrained
> C/Java/COBOL.
>
> Now that I'm on the subject of backwards.... Is there a reason for NTH being
> different to all the other accessors ?
>
> (nth 1 a-list)
> (elt a-list 1)
> (aref an-array 1)
NTH can only ever (usefully) take a single index (or count, if you
wish). AREF can take more than one index at a time (for
multi-dimensional arrays). ELT... Don't know why.
Also note that GETHASH is similar to NTH, in that it is called as
(GETHASH <hash key> <hash table> [<default>])
//Ingvar
--
Coffee: Nectar of gods / Aesir-mead of sysadmins / Elixir of life
Ingvar Mattsson <······@cathouse.bofh.se> writes:
>
> "Luke J Crook" <····@NO-SPAM.balooga.com> writes:
>
> >
> > Now that I'm on the subject of backwards.... Is there a reason for NTH being
> > different to all the other accessors ?
> >
> > (nth 1 a-list)
> > (elt a-list 1)
> > (aref an-array 1)
>
> NTH can only ever (usefully) take a single index (or count, if you
> wish). AREF can take more than one index at a time (for
> multi-dimensional arrays). ELT... Don't know why.
>
> Also note that GETHASH is similar to NTH, in that it is called as
> (GETHASH <hash key> <hash table> [<default>])
I also think that NTH ended up the way it did was because of history.
It already existed in pre-Common Lisp, whereas ELT was added to the
language. For consistency, one may have liked to change the argument
order for NTH, but since that would have broken existing lisp code, it
was eventually decided that consistency wasn't as important as allowing
smooth migration.
There was also at least one (and probably more than one) function which
had opposite argument order in MacLisp and InterLisp. This then
required making a choice, which IIRC went in favor of the MacLisp order.
--
Thomas A. Russ, USC/Information Sciences Institute ···@isi.edu
From: Christopher C. Stacy
Subject: Re: Thanks everyone
Date:
Message-ID: <u65ngprih.fsf@dtpq.com>
>>>>> On Sun, 08 Jun 2003 08:28:44 GMT, Luke J Crook ("Luke") writes:
Luke> Yes, but I do miss the simple days of being able to do:
Luke> screen-> BitsPerPixel
Luke> instead of (In Corman Lisp, when dealing with the FFI):
Luke> (ct:cref SDL_PixelFormat (ct:cref SDL_Surface screen format) BitsPerPixel))
Luke> There is still something to be said for infix notation.
This isn't a problem with language syntax, it's that you are missing
some functionality. You should not be programming the API using
foreign function calls. There's supposed to be a library on top of it.
At the very least, there should be a macro called BITS-PER-PIXEL or maybe
SCREEN-BITS-PER-PIXEL that expands into the above code, so you could
write your function call more like (BITS-PER-PIXEL SCREEN).
"Christopher C. Stacy" <······@dtpq.com> wrote in message
··················@dtpq.com...
> This isn't a problem with language syntax, it's that you are missing
> some functionality. You should not be programming the API using
> foreign function calls. There's supposed to be a library on top of it.
I'll send a nasty email to the developer.... oh wait, that's me ;)
A library of some kind is somewhere on my todo list.
-Luke
"Luke J Crook" <····@NO-SPAM.balooga.com> writes:
> Yes, but I do miss the simple days of being able to do:
>
> screen->BitsPerPixel
>
> instead of (In Corman Lisp, when dealing with the FFI):
>
> (ct:cref SDL_PixelFormat (ct:cref SDL_Surface screen format) BitsPerPixel))
>
> There is still something to be said for infix notation.
But this is less to do with infixness vs. prefixness and more to do
with using an FFI. FFIs tend to be more cumbersome than native code.
It is possible to generate easier accessor functions, such that that
would be (bits-per-pixel screen format), and to some degree this can
be done automatically (I believe that OpenMCL does that, for instance,
for its interface database), but C code and headers are rather
difficult to parse, unfortunately. There are tools to do it, but none
"just work" in all cases, AFAIK.
Of course you may find (bits-per-pixel screen format) less
aesthetically pleasing than screen->BitsPerPixel (I'm not sure where
the format bit came from in the CCL example?), but it's much less
unwieldy than the raw FFI version.
······@nordebo.com writes:
> for its interface database), but C code and headers are rather
> difficult to parse, unfortunately. There are tools to do it, but none
> "just work" in all cases, AFAIK.
You mean noone has written the equivalent of Bison (or Lex & Yacc) in
Lisp? I know C headers can get quite yucky (I mentioned an example of
a project in ELisp to implement cpp in another newsgroup). C
compilers have been around for quite sometime now for translating C
into object code.
At a very high level, and skipping some important details, there are
two basic things you need to do to generage FFI code in Lisp to a C
library.
The first thing is to process the header files cpp style and then
parse the resulting C code. Complexities here would be consts that
are implimented as #defines instead of C++ consts and perhaps also
some macros faking functiones, ie MAX & MIN.
The other thing you have to do is have a definition of the ABI
(Application Binary Interface) so that you can dynamicly link with the
C code.
The one part that I don't see getting around doing manually is
creating a nice Lisp wrapper to the nasty output you will end up with
in Lisp. I have seen other programs that convert say Perl to C so
that you can have a compiled version for speed. That C code can
hardly be called human readable.
Perhaps this is another project for me to add to my forever growing
TODO list of vaporware.
Now that I think about it, another interesting tack to take on the
problem would be to avoid FFI altogether by having a program that can
translate object code with debug info (ie STABS) into Lisp. I don't
know if this is possible to do as compiling down to machine code is an
information lossy process. But the presence of the debug info might
provide the required information to do the job. I expect the output
will be still less than pretty.
--
One Editor to rule them all. One Editor to find them,
One Editor to bring them all and in the darkness bind them.
David Steuber <·············@verizon.net> writes:
> The first thing is to process the header files cpp style and then
> parse the resulting C code. Complexities here would be consts that
> are implimented as #defines instead of C++ consts and perhaps also
> some macros faking functiones, ie MAX & MIN.
I assume that by "cpp style" you mean "in exactly the same way as the
system's C compiler would do, including identical include paths,
predfefined constants and #include_next behaviour".
From Linux bits/errno.h -
# if !defined _LIBC || defined _LIBC_REENTRANT
/* When using threads, errno is a per-thread value. */
# define errno (*__errno_location ())
# endif
# endif /* !__ASSEMBLER__ */
#endif /* _ERRNO_H */
Or from the gethostbyname man page -
#define h_addr h_addr_list[0] /* for backward compatibility */
> The other thing you have to do is have a definition of the ABI
> (Application Binary Interface) so that you can dynamicly link with the
> C code.
Which includes endianness conventions, struct/union packing rules, etc...
You need most of a C compiler, in short. And if you;'re going to
borrow gcc for the purpose, you probably need to fork it, as they
don't much like to add anything that would make it easier to use gcc
as a frontend to a proprietary backend or vice versa.
> Perhaps this is another project for me to add to my forever growing
> TODO list of vaporware.
I'd suggest you should look at cparse <http://www.cliki.net/cparse>
and FFIGEN (somewhere in OpenMCL) before starting out to reinvent the
wheel. I hear that FFIGEN works pretty well
> Now that I think about it, another interesting tack to take on the
> problem would be to avoid FFI altogether by having a program that can
> translate object code with debug info (ie STABS) into Lisp. I don't
> know if this is possible to do as compiling down to machine code is an
> information lossy process. But the presence of the debug info might
You'd lose anything that was #defined, for a start.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
David Steuber <·············@verizon.net> writes:
> ······@nordebo.com writes:
>
> > for its interface database), but C code and headers are rather
> > difficult to parse, unfortunately. There are tools to do it, but none
> > "just work" in all cases, AFAIK.
>
> You mean noone has written the equivalent of Bison (or Lex & Yacc) in
> Lisp?
Package: lang/lisp/code/parsing/zebu/
Name: ZEBU
Summary: Zebu parser/unparser generator for Common Lisp
Version: 3.4.8 (8-MAR-96); 3.3.6 (30-AUG-94); 3.3.2 (28-JUL-94)
Description:
Zebu is part of a set of tools for the translation of formal
languages. Zebu contains a LALR(1) parser generator like Yacc does.
Aside from generating a parser, Zebu will also generate the inverse of
a parser (unparser). In contrast to Yacc, the semantics is not given
in terms of ``routines'' but declaratively in terms of typed feature
structures. Syntax is specified using BNF-like productions and
lexical categories are specified using regular expressions.
Zebu generates a LALR(1) parsing table. To parse a string with a
grammar, only this table and a driver need to be loaded. The present
version of Zebu contains the ability to define several grammars and
parsers simultaneously, a declarative framework for specifying the
semantics, capabilities to define and use meta-grammars (grammars to
express a grammar in), as well as efficiency related improvements.
The current version compiles a grammar with 300 productions (including
dumping of the tables to disk) in approx 2 minutes and 30 seconds on a
HP 9000/370.
The current version can also produce a generator using a 'reversible
grammar' notation, in addition to a parser.
Documentation is included with the distribution.
This implementation is an extension written in Common Lisp of the
Scheme version. (The Scheme version was originally implemented by
William M. Wells III.)
The 3.4.8 version contains changes that make it work with Allegro
CL in Windows.
Requires:
Ports: Tested in Lucid CL and Allegro CL under HP-UX, and MCL
2.0b on the Macintosh
Origin: ftp.cs.cmu.edu:/user/ai/lang/lisp/code/parsing/zebu/
as the file zebu_332.tgz
cambridge.apple.com:/pub/mcl2/contrib/zebu-2.9.tar.Z
Copying: Copyright (c) 1989 by William M. Wells III
Copyright (c) 1990-93 by Hewlett-Packard Company.
Use, copying, modification and distribution permitted
for non-commercial purposes. (See the file named
COPYRIGHT in the package for details.)
Updated: Mon Mar 11 14:35:16 1996
CD-ROM: Prime Time Freeware for AI, Issue 1-1
Bug Reports: ·······@hplabs.hpl.hp.com
Mailing List:
Author(s): Joachim H. Laubsch <·······@hplabs.hpl.hp.com>
Contact:
Keywords:
Lisp!Parsing, Parsing, Zebu, Parser Generator, Authors!Laubsch, HP, NLG,
Formal Languages, LALR, Translation, Interoperability, LEX, YACC,
Unparsing
Contains:
doc/Zebu_intro.ps
COMPILE-ZEBU.lisp
ZEBU-init.lisp
See Also:
areas/nlp/parsing/
References:
Joachim Laubsch, "ZEBU: A Tool for Specifying Reversible {LALR}(1)
Parsers", Technical Report HPL-92-147, Hewlett Packard Laboratories,
Palo Alto, CA, November 1992.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
<······@nordebo.com> wrote in message
···················@pluto.elizium.org...
> "Luke J Crook" <····@NO-SPAM.balooga.com> writes:
> > Yes, but I do miss the simple days of being able to do:
> >
> > screen->BitsPerPixel
> >
> > instead of (In Corman Lisp, when dealing with the FFI):
> >
> > (ct:cref SDL_PixelFormat (ct:cref SDL_Surface screen format)
BitsPerPixel))
> >
> > There is still something to be said for infix notation.
>
> Of course you may find (bits-per-pixel screen format) less
> aesthetically pleasing than screen->BitsPerPixel (I'm not sure where
> the format bit came from in the CCL example?)
It does take some getting used to.
The 'format' is the variable within the struct.
So:
SDL_Surface = the name of the C struct in the C headers
screen = an instance of the struct in memory
format = the variable you want to get hold of in the struct.
-Luke
"Luke J Crook" <····@NO-SPAM.balooga.com> writes:
> "Kenny Tilton" <·······@nyc.rr.com> wrote in message
> ·····················@nyc.rr.com...
> >
> >
> > Yeah, and aren't () prettier than ,[;*%}^&? <g>
> >
>
> Yes, but I do miss the simple days of being able to do:
>
> screen->BitsPerPixel
>
> instead of (In Corman Lisp, when dealing with the FFI):
>
> (ct:cref SDL_PixelFormat (ct:cref SDL_Surface screen format) BitsPerPixel))
(defmacro -> (record field)
`(ct:cref (gethash ,field field-to-sdl_format)
(ct:cref (gethash (typeof ,record) record-to-sdl_type)
,record format) ,field))
(-> screen BitsPerPixel)
> There is still something to be said for infix notation.
See the recent Lisp-1.5 thread.
--
__Pascal_Bourguignon__ http://www.informatimago.com/
----------------------------------------------------------------------
Do not adjust your mind, there is a fault in reality.
"Pascal Bourguignon" <····@thalassa.informatimago.com> wrote in message
···················@thalassa.informatimago.com...
> (defmacro -> (record field)
> `(ct:cref (gethash ,field field-to-sdl_format)
> (ct:cref (gethash (typeof ,record) record-to-sdl_type)
> ,record format) ,field))
>
> (-> screen BitsPerPixel)
>
Thanks. This is something I am going to have to implement or go out of my
mind.
-Luke
Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
>
> Hey, I'm doing an informal survey of any newbie I run into:
I think I'll participate in your survey. And, yes, I think formalizing
it on Cliki would be a good idea for anyone in your "community" who
would like to see Lisp survive and even grow. (And I find that I am
slowly becoming one of them.)
The first thing you might want to do in your survey is ask us what
kind of "newbie" we are. I'm a long-time programmer, a newbie only to
Lisp.
> 1. How did you pick Lisp when you went looking for something new?
I realize that you're responding to the poster's comments, but in the
Cliki survey I would ask this as "how did you become interested in
Lisp?" without the assumption of an answer, because I wasn't looking
for something new. I stumbled across Paul Graham's one-sided yet
intriguing essays on the advantages of Lisp. My experience as a
(non-Lisp) programmer resonated with some of Graham's observations, so
even though it was clear that he wasn't looking at, or at least
admitting, the whole picture, I still decided to investigate further.
The last time I looked at Lisp was so long ago that I wouldn't have
been able to see the advantages I'm seeing now.
> 2. And why not, say, Python or Ruby?
I'm looking at them, too, but despite the one-sideness of Graham's
arguments, it appears as though he may be correct about the
specialness of Lisp. It looks to me as though worthy contenders such
as Python or Ruby are designed more for the convenience type of power
than for the extra reach type of power that Lisp offers. It looks as
though Python and Ruby are designed to make my daily work much easier,
which is nothing to sneeze at. But it appears that Lisp is designed to
make it possible to do harder types of daily work, and that interests
me more.
I suspect that Lisp's annoying syntax buys one the ability to do some
very unusual and powerful things that Python and Ruby sacrifice for
significant added convenience. At least that's my impression at this
point.
> 3. Any particular reason you were looking for something new to learn?
Just trying to stay sharp so that I'll still have a place in an
industry where experience doesn't count for much in most segments.
You asked some additional questions in a later message:
> I thought of some additional questions, some of which might be
> "not applicable":
> If you had heard Bad Things about Lisp, what were they and why
> did you look at Lisp anyway?
I heard that Lisp hasn't had a significant upgrade since the 80's and
that it has long since been abandoned by most of its former users.
As far as I can tell, that's true. I'm looking at it anyway because
I've often heard that just learning it enabled whole new ways of
looking at problems, and that interests me. I'm hoping it turns out to
be practical for real-life use, too. We'll see.
> If you have now had a chance to get familiar with Lisp, what are
> your first impressions?
My first impressions -- SUBJECT TO CHANGE -- are as follows:
It's much more flexible than today's common languages. I can see why
it would be called a "programmable programming language". Very nice
for tackling interesting, hard, niche problems. Probably not very
practical for big teams tackling common problems. I'm more interested
in the former, so I like this. Most companies are more interested in
the latter.
I can see how I can apply lessons from Lisp to work in other
languages, and that's interesting.
The community appears to be on life-support. (Remember, subject to
change, first impression, etc.) Not very encouraging, but you can't
buy low and sell high if you don't find things that are undervalued by
the market at large. I'd like to see a hero emerge, start from scratch
with the best ideas from Lisp and no legacy baggage, look at the
software world today, and come up with a new killer Lisp-like
language. But then it wouldn't be a secret weapon, so it might be
better if it remained un(re)discovered, as long as CMUCL or SBCL turn
out to be solid enough for real commercial use.
Tuang wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote in message news:<················@nyc.rr.com>...
>
>
>>Hey, I'm doing an informal survey of any newbie I run into:
>
>
> I think I'll participate in your survey. And, yes, I think formalizing
> it on Cliki would be a good idea for anyone in your "community" who
> would like to see Lisp survive and even grow. (And I find that I am
> slowly becoming one of them.)
That is a pretty consistent result. But maybe I have to go trolling on
other NGs to find survey respondents who tried CL and did not like it
(probably because they did not inhale).
>
> The first thing you might want to do in your survey is ask us what
> kind of "newbie" we are. I'm a long-time programmer, a newbie only to
> Lisp.
That info seems to come out anyway, but I agree: the longer I run this
survey the more questions I think to ask. I guess with Cliki the survey
can be malleable, which is nice.
>
>
>>1. How did you pick Lisp when you went looking for something new?
>
>
> I realize that you're responding to the poster's comments, but in the
> Cliki survey I would ask this as "how did you become interested in
> Lisp?" without the assumption of an answer, because I wasn't looking
> for something new.
Good point. Christ, now I have to buy a book on how to do a survey which
does not bias the outcome with its questions. :(
> I stumbled across Paul Graham's one-sided yet
> intriguing essays on the advantages of Lisp. My experience as a
> (non-Lisp) programmer resonated with some of Graham's observations, so
> even though it was clear that he wasn't looking at, or at least
> admitting, the whole picture, I still decided to investigate further.
And to think I thought Paul Graham was a traitor to CL! Doh!! That is a
pretty impressive tesimonial, viz. that you were not moivated by
discontent with the status quo, but by a simple description of the
language's advantages.
> It looks to me as though worthy contenders such
> as Python or Ruby are designed more for the convenience type of power
> than for the extra reach type of power that Lisp offers.
Ah, very nicely put. I'll be using that when pythonistas and javans
start crowing about their many libraries.
> But it appears that Lisp is designed to
> make it possible to do harder types of daily work, and that interests
> me more.
Yeah, it's that harder stuff that kills. Hacking FFI to get to C
libraries is a linear hassle, the unknown is exponential.
>
> I suspect that Lisp's annoying syntax buys one the ability to do some
> very unusual and powerful things that Python and Ruby sacrifice for
> significant added convenience. At least that's my impression at this
> point.
At the risk of drawing down flames on you, what annoys you about the
syntax? Second, do you not groove on auto-indentation of your code by
the editor?
> I heard that Lisp hasn't had a significant upgrade since the 80's and
> that it has long since been abandoned by most of its former users.
>
> As far as I can tell, that's true.
I think because it is Done. perl, python, and java need regular upgrades
because they are still rising from the sea.
> Very nice
> for tackling interesting, hard, niche problems. Probably not very
> practical for big teams tackling common problems.
This got discussed in the post-lisp-nyc schmoozefest. We concluded one
would never need a big team if one used Lisp. :)
> The community appears to be on life-support. (Remember, subject to
> change, first impression, etc.)
I like to say we are huddling together for warmth. But impending-death
predictions have lotsa huge problems. Lisp has been microscopic for
years--why is it still alive, and why is it getting out of its death bed
to stroll about the ward? Why are young programmers latching on to it?
They sure as hell ain't jumping on a bandwagon. And their enthusiasm is
over the top, nothing halfway about it (but the survey is young, we
night turn up some lukewarm newbies in time.)
> I'd like to see a hero emerge, start from scratch
> with the best ideas from Lisp and no legacy baggage, look at the
> software world today, and come up with a new killer Lisp-like
> language.
Could you take a Lisp hardcopy reference and rip out whatever you
consider baggage, then sell that on a CD with CMUCL?
Thx for the survey responses!
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton wrote:
>
>
> Tuang wrote:
>
>> Kenny Tilton <·······@nyc.rr.com> wrote in message
>> news:<················@nyc.rr.com>...
>
>> I'd like to see a hero emerge, start from scratch
>> with the best ideas from Lisp and no legacy baggage, look at the
>> software world today, and come up with a new killer Lisp-like
>> language.
>
>
> Could you take a Lisp hardcopy reference and rip out whatever you
> consider baggage, then sell that on a CD with CMUCL?
First post also from a relative Lisp newbie (and new reader of cll), but
programmer of lesser languages for 15 years:
It would be nice if the CL providers did standardize on a few things,
specifically sockets and regexes though, because when (ok, I still am) I
was trying to decide which CL environment to use (I'm torn between SBCL
and CLISP) it's not a trivial exercise. I guess there is an advantage
to having a single implementation (ala Python, Ruby).
BTW: where is this survey? I couldn't find it on Google.
But I agree with Kenny, that I'd like to see a hero emerge. Perhaps it
will be Arc if Paul Graham ever gets around to it, or perhaps something
else. I've been thinking about this a lot lately, and have a number of
ideas, but am probably terribly underqualified to write such a thing --
ok, I could write it and it would probably work, but it would suck
CPU/memory like a Hoover and nobody would use it (including myself).
Drew
* Drew Csillag <············@yahoo.com>:
> It would be nice if the CL providers did standardize on a few things,
> specifically sockets and regexes though, because when (ok, I still am) I
> was trying to decide which CL environment to use (I'm torn between SBCL
> and CLISP) it's not a trivial exercise. I guess there is an advantage to
> having a single implementation (ala Python, Ruby).
I once had that "problem", until I realised that things like CLOCC exist and
that #+ and #- really are quite useful. Moreover, you can also pretend that
CL only has a single implementation and then get on with using it. If the
code you want to write is useful to other people and they want it to work
with other implementations then I'm sure they'd help make it more portable.
--
Dave Pearson
http://www.davep.org/lisp/
Drew Csillag wrote:
> BTW: where is this survey? I couldn't find it on Google.
I was only thinking about getting it somewhere accessible. But there has
been a lot of response (some emails in confidence) so I have been to
Cliki and am trying to figure out how it works.
I am thinking:
Edit a similar page like new lispers. Select all. Copy. Cancel edit.
Hit "Create new page". Paste. Edit as suitable, including pasting in an
HTML survey developed in an HTML editor to replace a "new lisper" entry.
Of course delete the rest of the entries.
That would have all survey responses accessible only by scrolling
through the whole shebang. Or there each respondent could create their
own page, and the survey page could have a list widget that
automatically picks those up.
ie, Hellllppppppppp!!!!!
Unless I am on the right track. :) I'm just a little leery of learning
by experimenting on a live page.
>
> But I agree with Kenny, that I'd like to see a hero emerge.
OK, but that was someone else. If by hero you mean "that which will win
over a nice fat mindshare for CL", you have Java, Perl, and Python to
choose from. They are all adding Lisp features left and right. This
makes an implicit case for Lisp, introduces people in effect to Lisp,
shortens the leap to Lisp, and creates demand for Lisp. These languages
are conditioning everyone's immune systems to recognize Lisp as "self",
and one day these people will DL a Lisp implementation and think they
have been using it all their lives.
Evolution, not revolution. Something like that.
Back to Cliki...
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
> I was only thinking about getting it somewhere accessible. But there has
> been a lot of response (some emails in confidence) so I have been to
Cliki
> and am trying to figure out how it works
..snip..
Would it be possible to just make it an email (I'm sure you don't get
enough yet <.2 wink>) response and you can post the results somewhere,
or something like that?
>> But I agree with Kenny, that I'd like to see a hero emerge.
>
> OK, but that was someone else. If by hero you mean "that which will win
> over a nice fat mindshare for CL", you have Java, Perl, and Python to
> choose from. They are all adding Lisp features left and right.
Agreed, and now that I've started programming in CL, the lack of /real/
macros in Python and C, etc. has become downright maddening!!! And
usable macros are the one thing that really requires the parentheses, so
I don't see these languages growing real macros any time soon.
> This
> makes an implicit case for Lisp, introduces people in effect to Lisp,
> shortens the leap to Lisp, and creates demand for Lisp. These languages
> are conditioning everyone's immune systems to recognize Lisp as "self",
> and one day these people will DL a Lisp implementation and think they
> have been using it all their lives.
I don't know if I'd go quite that far, but "different" languages that become
more mainstream definitely do help. I think maybe Python's use of
whitespace
may help break enough preconceived notions about syntax that maybe the
parentheses may not be next, but something that will ready people for
the parens later.
> Evolution, not revolution. Something like that.
Yeah, I know, it's just that when you've seen the promised land, it's
frustrating waiting (ok, I've not been waiting that long yet) for the
rest of the world (or just enough of it anyway) to see it.
Apologies for sounding like somebody who has recently seen a great light.
Drew
Drew Csillag wrote:
>> I was only thinking about getting it somewhere accessible. But there has
>
> > been a lot of response (some emails in confidence) so I have been to
> Cliki
> > and am trying to figure out how it works
> ..snip..
>
> Would it be possible to just make it an email (I'm sure you don't get
> enough yet <.2 wink>) response and you can post the results somewhere,
> or something like that?
I thought if it was on Cliki it would be more open and accessible, and
more people would find their way to it by accident. Bad idea?
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Kenny Tilton <·······@nyc.rr.com> writes:
> I am thinking:
> Edit a similar page like new lispers. Select all. Copy. Cancel edit.
>
> Hit "Create new page". Paste. Edit as suitable, including pasting in
> an HTML survey developed in an HTML editor to replace a "new lisper"
> entry. Of course delete the rest of the entries.
If you're intending to create html form elements (checkboxes etc) on a
cliki page, it won't work. It may appear to work, but if it does
it'll break horribly when anyone next tries to edit it and it puts all
those form contents inside the cliki edit form. This is arguably a
cliki bug. Fixing it would involve caring, though.
If you just want personal testimonials a la 'YoungLispers', that's not
a problem, though.
> That would have all survey responses accessible only by scrolling
> through the whole shebang. Or there each respondent could create their
> own page, and the survey page could have a list widget that
> automatically picks those up.
If each person who takes the survey creates his own page (please,
using your real name, not your 3733t s00per-sekr1t haxx0r handle),
he could link to the "New User Survey" page by saying something like
"I first found Lisp in May 2003. My *(New User Survey) answers are as
follows:"
on it. Then the New User Survey page contains the questions and the magic
token
/("New User Survey" :attribute :topic :match :exact)
which will render as a list of all the pages in the New User Survey
topic - i.e. the pages with answers on. I'd favour this approach over
all-on-one-page, probably.
-dan
--
http://www.cliki.net/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> If you just want personal testimonials a la 'YoungLispers', that's not
> a problem, though.
yeah, just vanilla stuff like headers, bold,...
>
>
>>That would have all survey responses accessible only by scrolling
>>through the whole shebang. Or there each respondent could create their
>>own page, and the survey page could have a list widget that
>>automatically picks those up.
>
>
> If each person who takes the survey creates his own page (please,
> using your real name, not your 3733t s00per-sekr1t haxx0r handle),
> he could link to the "New User Survey" page by saying something like
>
> "I first found Lisp in May 2003. My *(New User Survey) answers are as
> follows:"
>
> on it. Then the New User Survey page contains the questions and the magic
> token
>
> /("New User Survey" :attribute :topic :match :exact)
>
super. thanx much.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
Drew Csillag wrote:
> It would be nice if the CL providers did standardize on a few things,
> specifically sockets and regexes though, because when (ok, I still am) I
> was trying to decide which CL environment to use (I'm torn between SBCL
> and CLISP) it's not a trivial exercise. I guess there is an advantage
> to having a single implementation (ala Python, Ruby).
Don't overestimate the importance of portability in the Lisp world. Just
choose the Common Lisp implementation that has the right feature set
(beyond ANSI) for your specific needs and go with it. If your
applications turn out to be successful, the extreme flexibility of Lisp
helps a lot to port them to other platforms. This has been accomplished
successfully in the past (see allogroserve and acl-compat).
In other languages, standards are much more important - that's why, for
example, Sun insisted that Microsoft keeps to the original Java APIs.
Common Lisp is way more flexible than that.
Pascal
--
Pascal Costanza University of Bonn
···············@web.de Institute of Computer Science III
http://www.pascalcostanza.de R�merstr. 164, D-53117 Bonn (Germany)
On Wed, 11 Jun 2003 04:32:31 GMT, Kenny Tilton <·······@nyc.rr.com> wrote:
> Good point. Christ, now I have to buy a book on how to do a survey which
> does not bias the outcome with its questions. :(
You might try phrasing questions and answers like this:
Do you like Lisp?
[ ] Yes
[ ] Sure
[ ] You bet
[ ] Yep
[ ] Da
Paolo
--
Paolo Amoroso <·······@mclink.it>
Kenny Tilton <·······@nyc.rr.com> wrote:
>
> > I stumbled across Paul Graham's one-sided yet
> > intriguing essays on the advantages of Lisp. My experience as a
> > (non-Lisp) programmer resonated with some of Graham's observations, so
> > even though it was clear that he wasn't looking at, or at least
> > admitting, the whole picture, I still decided to investigate further.
>
> And to think I thought Paul Graham was a traitor to CL! Doh!! That is a
> pretty impressive tesimonial, viz. that you were not moivated by
> discontent with the status quo, but by a simple description of the
> language's advantages.
Well, not quite. I was motivated by his claim that using a relatively
uncommon language was an advantage to him, not a disadvantage. If I
could get away with using Lisp for real work, then its advantages,
which I had heard about from time to time, were worth investigating.
>
> > It looks to me as though worthy contenders such
> > as Python or Ruby are designed more for the convenience type of power
> > than for the extra reach type of power that Lisp offers.
>
> Ah, very nicely put. I'll be using that when pythonistas and javans
> start crowing about their many libraries.
Thanks. Libraries still matter, of course. I don't know enough about
CL to comment on its libraries other than to say that if they don't
cover the major work areas (of today, not of the 1980s), then that
would be a serious handicap.
>
> > But it appears that Lisp is designed to
> > make it possible to do harder types of daily work, and that interests
> > me more.
>
> Yeah, it's that harder stuff that kills. Hacking FFI to get to C
> libraries is a linear hassle, the unknown is exponential.
I definitely agree. I think Lisp was hurt by its failure to solve the
hardest problems we've attempted (AI), but I attribute that to our
lack of understanding of the domain, not to any flaw in Lisp. If
experienced people think of Lisp when they think of hard problems like
those in AI, then I'd like to know more about Lisp.
> >
> > I suspect that Lisp's annoying syntax buys one the ability to do some
> > very unusual and powerful things that Python and Ruby sacrifice for
> > significant added convenience. At least that's my impression at this
> > point.
>
> At the risk of drawing down flames on you, what annoys you about the
> syntax? Second, do you not groove on auto-indentation of your code by
> the editor?
Yeah, well.... I find that the use of ((())()((())))(()))) definitely
impairs the readability of Lisp. As I try to mentally parse the code
snippets in some lesson in a textbook, for example, I often have to
resort to counting parens, which is a pain. Or I don't resolve my
confusion about the meaning of some code until I realize that I was
mentally misgrouping something. Once again, an annoyance that ranks up
there with mentally parsing C function pointer declarations, though
it's not as bad as Perl (which I often use.)
Also, I get tired of always writing backwards. A unix pipe sequence of
operations A | B | C is written in the order of execution (do A, send
the result to B, then send that to C and output). In Lisp it's
(C (B (A foo))). So to do ABC to foo I have to write CBA foo with lots
of parentheses. Annoying.
I *do* see the point of it, however, and I can't honestly see a better
way to do it, at least right now. You're writing in the raw tree
structure, which makes writing the code a little harder than using
some nice syntax that gets translated into a tree internally. But
doing so then makes it easier to write macros and other code that
reads and writes code.
Since I can't think of a cognitively cheaper way to get that same
power, I'll be okay with it.
And yes, I find that having a Lisp-savvy editor is a huge help, but
indentation levels also get hard to mentally interpret when procedures
get long and complicated, and a lot of code that I'm seeing (at least
while learning) is outside the world of my editor, so I have to parse
by eye. In comparison, longish sequences of imperative instructions
are easier to follow. At least for me.
>
>
> > I heard that Lisp hasn't had a significant upgrade since the 80's and
> > that it has long since been abandoned by most of its former users.
> >
> > As far as I can tell, that's true.
>
> I think because it is Done. perl, python, and java need regular upgrades
> because they are still rising from the sea.
I'm quite skeptical of this claim, but given my inexperience with Lisp
and the temperament of some participants in this forum, I think I'll
just leave it at that.
> > Very nice
> > for tackling interesting, hard, niche problems. Probably not very
> > practical for big teams tackling common problems.
>
> This got discussed in the post-lisp-nyc schmoozefest. We concluded one
> would never need a big team if one used Lisp. :)
Nice theory. :) I suspect that Lisp's great flexibility would make it
hard to keep a large team coordinated without lots of meetings and
oppressive coding standards and bickering over personal preferences.
It would be like herding cats.
>
> > I'd like to see a hero emerge, start from scratch
> > with the best ideas from Lisp and no legacy baggage, look at the
> > software world today, and come up with a new killer Lisp-like
> > language.
>
> Could you take a Lisp hardcopy reference and rip out whatever you
> consider baggage, then sell that on a CD with CMUCL?
Sure, maybe someday I'll be qualified. Not today. If it ever happened,
my guess is that the changes wouldn't be limited to leaving out parts.
> Thx for the survey responses!
You're welcome.
Tuang <········@hotmail.com> wrote:
> Yeah, well.... I find that the use of ((())()((())))(()))) definitely
> impairs the readability of Lisp. As I try to mentally parse the code
> snippets in some lesson in a textbook, for example, I often have to
> resort to counting parens, which is a pain. Or I don't resolve my
Tip that was my personal salvation:
"The parens are for the computer. You should be able to read by
indentation. If you can't you need to split some lines (and start using an
auto-indenting editor). If you still can't you need to split your
functions into smaller pieces. If you still can't you're doing something
wrong."
>> I think because it is Done. perl, python, and java need regular upgrades
>> because they are still rising from the sea.
> I'm quite skeptical of this claim, but given my inexperience with Lisp
> and the temperament of some participants in this forum, I think I'll
> just leave it at that.
Skeptical about CL not needing or skeptical about other needing?
Cheers,
-- Nikodemus
Nikodemus Siivola <········@kekkonen.cs.hut.fi> wrote in message news:<··············@midnight.cs.hut.fi>...
> Tuang <········@hotmail.com> wrote:
>
> > Yeah, well.... I find that the use of ((())()((())))(()))) definitely
> > impairs the readability of Lisp. As I try to mentally parse the code
> > snippets in some lesson in a textbook, for example, I often have to
> > resort to counting parens, which is a pain. Or I don't resolve my
>
> Tip that was my personal salvation:
>
> "The parens are for the computer. You should be able to read by
> indentation. If you can't you need to split some lines (and start using an
> auto-indenting editor). If you still can't you need to split your
> functions into smaller pieces. If you still can't you're doing something
> wrong."
Thanks. I agree that indentation solves enough of it that I can live
with the rest.
>
> >> I think because it is Done. perl, python, and java need regular upgrades
> >> because they are still rising from the sea.
>
> > I'm quite skeptical of this claim, but given my inexperience with Lisp
> > and the temperament of some participants in this forum, I think I'll
> > just leave it at that.
>
> Skeptical about CL not needing or skeptical about other needing?
I'm skeptical of the claim that Lisp is "Done" in the sense that
Common Lisp is (approximately, within reason) as good as a Lisp-like
language could ever be. Given the changes in issues of concurrency,
internationalization, security, Internet usage, OS APIs, etc., I'm
skeptical that a standard that was frozen in the 80s is every bit as
good as a Lisp redesigned from scratch today could be.
However, this is just the basis for my skepticism. I don't know enough
CL to criticize anything specific.
Hi Tuang,
> I'm skeptical of the claim that Lisp is "Done" in the sense that Common
> Lisp is (approximately, within reason) as good as a Lisp-like language
> could ever be. Given the changes in issues of concurrency,
> internationalization, security, Internet usage, OS APIs, etc., I'm
> skeptical that a standard that was frozen in the 80s is every bit as
> good as a Lisp redesigned from scratch today could be.
>
> However, this is just the basis for my skepticism. I don't know enough
> CL to criticize anything specific.
These are all important issues that can typically be implemented as ANSI
CL compatible extensions. For an example of superb internationalisation
check out CLISP's character handling. It knows a stack of different
character sets and encodings and most Unicode characters are even known by
name. Try this in CLISP:
(dotimes (i 1000) (write (code-char i)) (write-line ""))
I would have liked all the underscores to have been converted to minus
signs so for example #\greek_phi_symbol could be written
#\greek-phi-symbol (it feels more lispy as you may soon understand).
A Lisp designed from scratch today would be nothing like as useful as
ANSI Common Lisp. One needs years for a community to decide upon stable
semantics--and have the time to implement them--before one even has an
opportunity to be able to write code that will be as reliable today as it
is in ten years time.
Building a community around multiple conforming implementations is a lot
more difficult than hacking up a new kind of Lisp and calling its one
implementation with all its bugs and quirks a better Lisp standard.
There is a limit to how many useful structures one can build when the
basic building blocks are in flux.
Regards,
Adam
Adam Warner <······@consulting.net.nz> wrote in message news:<·····························@consulting.net.nz>...
> Hi Tuang,
>
> > I'm skeptical of the claim that Lisp is "Done" in the sense that Common
> > Lisp is (approximately, within reason) as good as a Lisp-like language
> > could ever be. Given the changes in issues of concurrency,
> > internationalization, security, Internet usage, OS APIs, etc., I'm
> > skeptical that a standard that was frozen in the 80s is every bit as
> > good as a Lisp redesigned from scratch today could be.
> >
> > However, this is just the basis for my skepticism. I don't know enough
> > CL to criticize anything specific.
>
> These are all important issues that can typically be implemented as ANSI
> CL compatible extensions.
Hi Adam,
Well, there's no doubt that most things can be implemented as
extensions in most languages. As checkbox items, most of the things
that attract me to Lisp are available in C via some sort of extension,
so why use Lisp?
The reason (it appears to me) is that Lisp takes a particularly nice
set of them and puts them right in the foundation of the language. Not
only are they part of the foundation, but they are designed as an
integrated set that complement one another, rather than as a
collection of independent extensions.
I think that we probably both agree that most things belong in
libraries, not in the core language. And I think that no two people
will ever agree on what belongs in the core language, what belongs in
the standard libraries, and what belongs in non-standard extensions.
Even so, priorities change over the years and I would bet that a
Lisp-like language designed by a group of experts in various
specialties today, with no legacy constraints, would set things up
somewhat differently today than back in the late 80s.
This is just a sense that I have based on observations of changes in
languages and libraries (and the types of projects everyone seemed to
be working on) as they have evolved over the years.
It's not a specific criticism of CL, which may turn out to have been
designed so cleverly that none of this applies to it. I doubt it, but
I suppose it's possible.
> For an example of superb internationalisation
> check out CLISP's character handling. It knows a stack of different
> character sets and encodings and most Unicode characters are even known by
> name. Try this in CLISP:
> (dotimes (i 1000) (write (code-char i)) (write-line ""))
>
> I would have liked all the underscores to have been converted to minus
> signs so for example #\greek_phi_symbol could be written
> #\greek-phi-symbol (it feels more lispy as you may soon understand).
Thanks for the info. :)
> A Lisp designed from scratch today would be nothing like as useful as
> ANSI Common Lisp. One needs years for a community to decide upon stable
> semantics--and have the time to implement them--before one even has an
> opportunity to be able to write code that will be as reliable today as it
> is in ten years time.
>
> Building a community around multiple conforming implementations is a lot
> more difficult than hacking up a new kind of Lisp and calling its one
> implementation with all its bugs and quirks a better Lisp standard.
> There is a limit to how many useful structures one can build when the
> basic building blocks are in flux.
Well, yes, the first implementations of a superior technology are
usually inferior to the last implementations of an inferior
technology. I'm going to learn the CL form of Lisp for now, because
that appears to the be only one currently suitable for real production
work. It's clearly a great technology. Since I'll certainly need help,
I should probably just stop there and keep my mouth shut, but... if I
had to guess, I'd guess that if Lisp is popular 20 years from now, it
won't be a 40-yr-old standard with extensions. It will be a new Lisp.
But that's only a guess, and I wouldn't have predicted that people
would still be using COBOL, so what do I know? :)
········@hotmail.com (Tuang) writes:
> As I try to mentally parse the code snippets in some lesson in a
> textbook, for example, I often have to resort to counting parens,
> which is a pain.
Don't. Look at the indentation.
> Also, I get tired of always writing backwards. A unix pipe sequence
> of operations A | B | C is written in the order of execution (do A,
> send the result to B, then send that to C and output). In Lisp it's
>
> (C (B (A foo))). So to do ABC to foo I have to write CBA foo with
> lots of parentheses. Annoying.
(defmacro pipe (input &rest functions)
(pipe-aux input functions))
(defun pipe-aux (input functions)
(if functions
(pipe-aux (list (first functions) input)
(rest functions))
input))
(macroexpand '(pipe foo a b c d e f g)) ==> (G (F (E (D (C (B (A FOO)))))))
So, now you just write
(pipe foo a b c d e f g)
Well, that's removed that annoyance for you :-)
> Yeah, well.... I find that the use of ((())()((())))(()))) definitely
> impairs the readability of Lisp.
[...]
> You're writing in the raw tree structure, which makes writing the
> code a little harder than using some nice syntax that gets
> translated into a tree internally.
Funny, I looked at some (OCa)ML code yesterday (I'm no ML expert, and
haven't seen any ML code for a while) ... and my strongest emotional
reaction was that I wanted some parentheses to help me see how things
are grouped; the "nice", "natural", "intuitive" syntax that is
supposed to make the code more readable for me made it very difficult
to see how things were grouped, what applied/referred to what, etc.
> But doing so then makes it easier to write macros and other code
> that reads and writes code.
>
> Since I can't think of a cognitively cheaper way to get that same
> power,
Cue Bruce Hoult ... :-)
> indentation levels also get hard to mentally interpret when
> procedures get long and complicated
Many things can get hard to mentally interpret when procedures get
long and complicated ... the indentation, however, should make it
unnecessary to count parentheses. (Remember, people do somehow manage
to write complicated procedures in Python (tllotbafir))
> a lot of code that I'm seeing (at least while learning) is outside
> the world of my editor, so I have to parse by eye.
Presumably, you are referring to books, tutorials ... in which case it
should be indented correctly, and there should be no need to count
parentheses.
> In comparison, longish sequences of imperative instructions are
> easier to follow. At least for me.
(let* ((b (a foo))
(c (c b))
(d (d c))
(e (some complicated code here which uses d))
(f (more stuff which uses e and even d,c etc))
...)
...)
I don't think there is anything wrong with writing in such a style
when it is appropriate. Just don't assume from the start that it is
_always_ appropriate.
Jacek Generowicz <················@cern.ch> wrote in message news:<···············@pcepsft001.cern.ch>...
> ········@hotmail.com (Tuang) writes:
>
> > As I try to mentally parse the code snippets in some lesson in a
> > textbook, for example, I often have to resort to counting parens,
> > which is a pain.
>
> Don't. Look at the indentation.
I've already learned to do so and I agree that it solves the majority
of the problem. Some of it still remains, though. When things get
complicated and you get expressions that open with double parens
(maybe conditionals returning functions inside a macro or another
conditional, or whatever) I often lose track of what is part of what,
regardless of indentation. And if it's on paper or a Web page, I can't
reformat it or match parens without using my finger. :)
But remember that I'm not saying that the syntax is bad. Though it's
sometimes confusing (which is annoying), I find it quite useful.
Unlike the syntactic annoyances in other languages, I see the point of
this one and I can't think of a better way.
Let me put it this way. Since I see the benefits of it, and I want
those benefits, and I can't think of a better alternative, the parens
are not going to make me less likely to use Lisp. I'm just responding
to a request for clarification of what I found annoying about the
syntax.
>
> > Also, I get tired of always writing backwards. A unix pipe sequence
> > of operations A | B | C is written in the order of execution (do A,
> > send the result to B, then send that to C and output). In Lisp it's
> >
> > (C (B (A foo))). So to do ABC to foo I have to write CBA foo with
> > lots of parentheses. Annoying.
>
> (defmacro pipe (input &rest functions)
> (pipe-aux input functions))
>
> (defun pipe-aux (input functions)
> (if functions
> (pipe-aux (list (first functions) input)
> (rest functions))
> input))
>
> (macroexpand '(pipe foo a b c d e f g)) ==> (G (F (E (D (C (B (A FOO)))))))
>
> So, now you just write
>
> (pipe foo a b c d e f g)
>
> Well, that's removed that annoyance for you :-)
:) Thanks. I think I'll keep that code snippet. It doesn't really
solve much of the problem, because the rest of the world will go on
writing backwards. It's like being frustrated that the basic
navigation keys in vi (HJKL) are linear instead of being an inverted T
(JIKL), like modern arrow keys, and being told that I can customize
the key bindings. Well, sure, but then I'll be unable to use any vi
except my own. The more you customize, the less comfortable you are
with the way everyone else does things and the less usable your stuff
is by anyone else.
I'll probably be better off just getting more used to the standard
backwards notation (CDDAR means do A,D,D not D,D,A). But your macro is
a great example of what interests me so much about Lisp. I'm delighted
by the power of macros. I just need to learn to use them wisely and
not just to satisfy every whim.
>
> > Yeah, well.... I find that the use of ((())()((())))(()))) definitely
> > impairs the readability of Lisp.
> [...]
> > You're writing in the raw tree structure, which makes writing the
> > code a little harder than using some nice syntax that gets
> > translated into a tree internally.
>
> Funny, I looked at some (OCa)ML code yesterday (I'm no ML expert, and
> haven't seen any ML code for a while) ... and my strongest emotional
> reaction was that I wanted some parentheses to help me see how things
> are grouped; the "nice", "natural", "intuitive" syntax that is
> supposed to make the code more readable for me made it very difficult
> to see how things were grouped, what applied/referred to what, etc.
I don't think anyone would say that beautiful syntax is a feature of
Ocaml. Just powerful semantics (I hear.) I'm thinking more along the
lines of Ruby, which I don't know, but I've seen code snippets
illustrating the syntax.
I know what you mean about the parens, though. Although it's annoying
when I have to take my finger and count them, at least I *can*. The
explicit parens usually resolve my question, so I admit that there are
times when I'm glad they're there.
>
> > indentation levels also get hard to mentally interpret when
> > procedures get long and complicated
>
> Many things can get hard to mentally interpret when procedures get
> long and complicated ... the indentation, however, should make it
> unnecessary to count parentheses. (Remember, people do somehow manage
> to write complicated procedures in Python (tllotbafir))
I'm thinking specifically of some macros that I've seen that span more
than one page in a book. While I'm amazed at how much can be
accomplished with 50 lines of macro code, it gets pretty hard for me
to follow. I can't tell whether we're in 6 levels of indentation or 5
or 7.
Still, it's an awful lot easier to figure out than the equivalent
thousand or so lines of C, regardless of syntax!
>
> > a lot of code that I'm seeing (at least while learning) is outside
> > the world of my editor, so I have to parse by eye.
>
> Presumably, you are referring to books, tutorials ... in which case it
> should be indented correctly, and there should be no need to count
> parentheses.
You're correct about "books, tutorials, ..." so maybe the problem will
go away in real practice, but as I said, a 50-line macro spanning two
pages still loses me. One line will end with a whole bunch of "))))"s
and the next line will indent several tabs (how many?) and keep going.
But this is definitely the exception, and it's not a big issue for me.
>
> > In comparison, longish sequences of imperative instructions are
> > easier to follow. At least for me.
>
> (let* ((b (a foo))
> (c (c b))
> (d (d c))
> (e (some complicated code here which uses d))
> (f (more stuff which uses e and even d,c etc))
> ...)
> ...)
>
> I don't think there is anything wrong with writing in such a style
> when it is appropriate. Just don't assume from the start that it is
> _always_ appropriate.
Right. Pretty much everything else I do is (and has been) imperative
style, but that makes me enjoy using Lisp in a functional way, not
hate it. It will take me a while to learn when to use one or the
other.
········@hotmail.com (Tuang) writes:
> Jacek Generowicz <················@cern.ch> wrote:
> > > Also, I get tired of always writing backwards.
> > (macroexpand '(pipe foo a b c d e f g)) ==> (G (F (E (D (C (B (A FOO)))))))
> >
> > So, now you just write
> >
> > (pipe foo a b c d e f g)
> >
> > Well, that's removed that annoyance for you :-)
>
> :) Thanks. I think I'll keep that code snippet. It doesn't really
> solve much of the problem, because the rest of the world will go on
> writing backwards.
Aaaah, but you said you were tired of _writing_ backwards ... you
didn't mention reading in this context :-)
I wouldn't suggest that you use a macro such as this all the time; I
would use it in situations where what you are doing somehow
conceptually matches a pipe-like process. For example, compare:
(log (square (sin x)))
to
(pipe x sin square log)
Now, I certainly prefer the former in this context. The _latter_ looks
backwards to me. And guess what ... in C, Python etc. you would write
it thus:
log(square(sin(x)))
Would you say that it looks backwards in those languages ?
> It's like being frustrated that the basic navigation keys in vi
> (HJKL) are linear instead of being an inverted T (JIKL), like modern
> arrow keys, and being told that I can customize the key
> bindings. Well, sure, but then I'll be unable to use any vi except
> my own.
To quote someone's signature: "Wherever I lay my .emacs, that's my $HOME".
> The more you customize, the less comfortable you are with the way
> everyone else does things and the less usable your stuff is by
> anyone else.
I have a lot of sympathy for this ... but ultimately, I spend most of
my time editing in _my_ environment. The cumulative benefits of my
customization outweigh the problems I have when I use someone else's
environment. (A side effect is that when people watch me edit in my
env. they think I am a wizard; when they watch me in theirs, they
wonder whether I've ever touched a computer before.)
But getting back on-topic ... well ... I don't need to preach to you
about the benefits of creating your custom languages "on lisp", as you
seem to have grasped this point already.
> I'll probably be better off just getting more used to the standard
> backwards notation (CDDAR means do A,D,D not D,D,A).
I don't mean this in any condescending way: how much mathematics have
you "done"? My point is that "cddar" meaning "first apply 'a', then
apply 'd' etc." seems perfectly natural to me.
> But your macro is a great example of what interests me so much about
> Lisp. I'm delighted by the power of macros. I just need to learn to
> use them wisely and not just to satisfy every whim.
Wise words, IMHO.
> I'm thinking specifically of some macros that I've seen that span more
> than one page in a book. While I'm amazed at how much can be
> accomplished with 50 lines of macro code, it gets pretty hard for me
> to follow. I can't tell whether we're in 6 levels of indentation or 5
> or 7.
But I suspect that one single 50-line-long block of code, gets pretty
hard to follow in _any_ language.
> Still, it's an awful lot easier to figure out than the equivalent
> thousand or so lines of C, regardless of syntax!
:-)
> a 50-line macro spanning two pages still loses me.
Just like a 50 line (C|C++|Python|whatever) function spanning two
pages still loses me.
> One line will end with a whole bunch of "))))"s and the next line
> will indent several tabs (how many?)
You don't care ... you look vertically upwards to see where this level
starts. (But I'm sure you know that already)
>
> Right. Pretty much everything else I do is (and has been) imperative
> style, but that makes me enjoy using Lisp in a functional way, not
> hate it. It will take me a while to learn when to use one or the
> other.
Yup. As we've both mentioned before ... you should chose the style
which is appropriate to the situation in question.
And now I'll stop preaching to the converted.
In article <···············@pcepsft001.cern.ch>,
Jacek Generowicz <················@cern.ch> wrote:
> > But doing so then makes it easier to write macros and other code
> > that reads and writes code.
> >
> > Since I can't think of a cognitively cheaper way to get that same
> > power,
>
> Cue Bruce Hoult ... :-)
<lurch>
You rang??
</lurch>
As Jacek knows I'm a fan of the CL-derivative language, Dylan, which has
a more "conventional" syntax, and a macro system based on token pattern
matching and rewrite rules.
CL's macros are more powerful than Dylan's, but I believe that Dylan's
are easier to use in the easy-to-medium cases, and capable of doing 90+%
of what CLs macros are usually used for e.g. just about everything in
Paul Graham's _On Lisp_
There is also a very interesting design proposal for using Dylan's
existing macro pattern matching engine to do most of the work of more
complex macros, and enhance it with a procedural facility to cover the
rest of what CL macros can do:
http://www.ai.mit.edu/~jrb/Projects/dexprs.pdf
This hasn't yet been implemented, so for the moment at least CL's macros
remain strictly more powerful in a practical sense (Dylan's macros are
in fact Turing complete, but you have to implement Church Numerals or
similar to get arithmetic, so some things would be rather inconvenient).
> > Also, I get tired of always writing backwards. A unix pipe sequence
> > of operations A | B | C is written in the order of execution (do A,
> > send the result to B, then send that to C and output). In Lisp it's
> >
> > (C (B (A foo))). So to do ABC to foo I have to write CBA foo with
> > lots of parentheses. Annoying.
>
> (defmacro pipe (input &rest functions)
> (pipe-aux input functions))
>
> (defun pipe-aux (input functions)
> (if functions
> (pipe-aux (list (first functions) input)
> (rest functions))
> input))
>
> (macroexpand '(pipe foo a b c d e f g)) ==> (G (F (E (D (C (B (A
> FOO)))))))
>
> So, now you just write
>
> (pipe foo a b c d e f g)
>
> Well, that's removed that annoyance for you :-)
Or you could just use "compose":
define method pipe(arg, #rest fns)
apply(compose, fns.reverse)(arg)
end;
pipe(foo, a, b, c, d, e, f, g);
Or, you can use the "syntactic sugar" of . notation for calling a
function of a single argument (most commonly used for object slot
access):
foo.a.b.c.d.e.f.g;
Just for completeness, here is a Dylan macro using essentially the same
expansion strategy as your CL macro:
define macro pipe
{pipe ?args end} => {?args}
args:
{?arg:expression} => {?arg}
{?arg:expression ?fn:expression ?rest:*} =>
{pipe ?fn(?arg) ?rest end}
end;
format-out(
"%=\n",
pipe 5 - 2 method(n) n + 1 end curry(\*,10) negative end
)
=> -40
The Dylan parser/macro engine can happily sort out the rather messy
stuff betwen "pipe" and "end" into its argument "5 - 2" and three
function expressions ("method(n) n + 1 end", "curry(\*,10)", and
"negative"). People can't do it so easily and therefore in an actual
Dylan macro I'd normally put in some more sugar such as commas or a
noise-word such as "into":
define macro pipe
{pipe ?args end} => {?args}
args:
{?arg:expression} => {?arg}
{?arg:expression into ?fn:expression into ?rest:*} =>
{pipe ?fn(?arg) into ?rest end}
end;
pipe 5 - 2 into method(n) n + 1 end into curry(\*,10) into negative end
The Dylan compiler I use (http://www.gwydiondylan.org) doesn't have a
"macroexpand" feature, but here's the C code produced by the above use
of the "pipe" macro:
L_temp_3.heapptr = pipeZliteral.heapptr;
L_temp_3.dataword.l = (- (10 * ((5 - 2) + 1)));
Not too bad.
> > In comparison, longish sequences of imperative instructions are
> > easier to follow. At least for me.
>
> (let* ((b (a foo))
> (c (c b))
> (d (d c))
> (e (some complicated code here which uses d))
> (f (more stuff which uses e and even d,c etc))
> ...)
> ...)
>
> I don't think there is anything wrong with writing in such a style
> when it is appropriate. Just don't assume from the start that it is
> _always_ appropriate.
In fact I miss Dylan's non-(visually)-nesting "let" (and C++'s and
Java's and Perl's...) so much when I'm writing Lisp code (mostly elisp)
that I often use a little macro that turns stuff like this...
(letblock
(stuff1)
(let b = (a foo))
(stuff2)
(let c = (c b))
(stuff3)
(let d = (d c))
...)
... into ...
(let* ((b (progn (stuff1) (a foo)))
(c (progn (stuff2) (c b)))
(d (progn (stuff3) (d c))))
...)
I find this kind of unnesting jujitsu extremely valuable in
understanding code. It may seem un-lisp like to some here, but I'd
point them to a long history of similar unnesting constructs in Lisp
such as "cond" vs the more traditional nested "if" statements. The
let*/progn combination itself isn't too bad, except that the new
variable gets mentioned at the start and if the body of the progn is
many lines long then it can be a long way until the actual expression
bound to that variable is seen.
-- Bruce
Tuang wrote:
> Kenny Tilton <·······@nyc.rr.com> wrote:
>>And to think I thought Paul Graham was a traitor to CL! Doh!! That is a
>>pretty impressive tesimonial, viz. that you were not moivated by
>>discontent with the status quo, but by a simple description of the
>>language's advantages.
>
>
> Well, not quite. I was motivated by his claim that using a relatively
> uncommon language was an advantage to him, not a disadvantage.
Move fast, CL has started to charge from the back of the pack and Funny
C++ is fading fast.
> I don't know enough about
> CL to comment on its libraries other than to say that if they don't
> cover the major work areas (of today, not of the 1980s), then that
> would be a serious handicap.
Yep, but it covers whatever C covers and, if you use ACL, whatever Java
covers. Just have to slog thru that FFI annoyance, but I got OpenGL
working nicely as a total FFI newby with just one smashed keyboard (two
under par). The eagle came about because I wrote a macro which parsed
slightly-and-globally edited C header code into UFFI code.
> I definitely agree. I think Lisp was hurt by its failure to solve the
> hardest problems we've attempted (AI), but I attribute that to our
> lack of understanding of the domain,...
That would do it. :) But CliniSys successfully applied CL to another
Very Hard Problem, viz., large business application development, and
success stories like this will help CL leapfrog the procedural dinosaurs.
>>At the risk of drawing down flames on you, what annoys you about the
>>syntax? Second, do you not groove on auto-indentation of your code by
>>the editor?
>
>
> Yeah, well.... I find that the use of ((())()((())))(()))) definitely
> impairs the readability of Lisp.
How long have you been looking at them? No serious user of Lisp even
sees the parenthese, and I would say a month of full-time use gets one
to that level. No Lispnik dislikes parentheses, and every Lispnik (I
wager) hates editing without them when they work on other languages.
> As I try to mentally parse the code
> snippets in some lesson in a textbook...
What others said. But again, give your brain time to rewire. and if the
author doesn't use many linebreaks, you have my sympathy. I often take
others' Lisp and add linebreaks until I can read it. Of course cut and
paste with real paper...
> Also, I get tired of always writing backwards. A unix pipe sequence of
> operations A | B | C is written in the order of execution (do A, send
> the result to B, then send that to C and output). In Lisp it's
>
> (C (B (A foo))). So to do ABC to foo I have to write CBA foo with lots
> of parentheses. Annoying.
But that is a boring example, because it could just as well be:
(let (temp)
(setf temp (a foo))
(setf temp (b temp))
(c temp))
What if A, B and C take multiple inputs? asta la vista pipe, and:
(let (t1 t2)
(setf t1 (a foo 'up))
(setf t2 (b foo 'down))
(c t1 t2))
Or you can do:
(c (b (a foo 'up)
'down)) ;; linebreak overkill?
...and it reads like a book. Besides, i think, read, and design
top-down, not bottom up, even in COBOL. The pipe example is procedural
and antithetical to top-down, while the functional is all about top-down.
Maybe we should talk again in a few months; I'd like to see the language
(syntax and modality(?)) variable controlled for in your observations.
>
> You're writing in the raw tree
> structure, which makes writing the code a little harder than using
> some nice syntax that gets translated into a tree internally.
God no! The syntax /must/ map isomorphically to the semantics, the
resulting runnable.
I think what runs, I code what I think, what I think runs. Move over,
Descartes.
Lisp supports an incremental, evolutionary model of program design. I
think, I code, I run, I learn, I refactor. Second verse, same as the
first. That means I am forever grabbing chunks of the tree and moving
them around, conceptually and syntactically, possible only because of
the syntax-runnable isomorphism.
> indentation levels also get hard to mentally interpret when procedures
> get long and complicated,...
Yep. I keep my functions small. Hell, I even keep my source files small.
>... and a lot of code that I'm seeing (at least
> while learning) is outside the world of my editor, so I have to parse
> by eye. In comparison, longish sequences of imperative instructions
> are easier to follow. At least for me.
OK, it all makes sense now. Stop reading, start coding. But that is just
my style. I am enjoying the growing list of respondents to the Road of
Lisp survey:
http://www.cliki.net/The%20Road%20to%20Lisp%20Survey
... including the reminder i get that everyone learns differently. Some
folks talk about reading entire books! More than once!! I read a chapter
once....
>>>I heard that Lisp hasn't had a significant upgrade since the 80's and
>>>that it has long since been abandoned by most of its former users.
>>>
>>>As far as I can tell, that's true.
>>
>>I think because it is Done. perl, python, and java need regular upgrades
>>because they are still rising from the sea.
>
> I'm quite skeptical of this claim,
Guessing you mean "Lisp is not done", look, defsystem and FFI could be
standardized, pathnames suck, etc etc... nothing fundamental (and you
said "significant upgrade"). Now look at the changes Perl, Python, and
Java are going thru. Still rising from the sea, chasing the Mt Everest
of CL.
>
>>>Very nice
>>>for tackling interesting, hard, niche problems. Probably not very
>>>practical for big teams tackling common problems.
>>
>>This got discussed in the post-lisp-nyc schmoozefest. We concluded one
>>would never need a big team if one used Lisp. :)
>
> Nice theory. :)
When I look at what CliniSys accomplished in four man-years with CL, I
think "bring on that air traffic control RFP!". Of course we used Cells
(my pet project <g>).
Besides, The Mythical Man-Month is right, small teams will always do
better than big teams.
> I suspect that Lisp's great flexibility would make it
> hard to keep a large team coordinated without lots of meetings and
> oppressive coding standards and bickering over personal preferences.
> It would be like herding cats.
Unlike with other languages?! <g> Again, that is why small is good, and
why good teams divide systems up into subsystems with finite interfaces.
And you know, those personal differences are just the result of
programming still being a young discipline. We have not yet worked out
how to do it, so who is to say my style is worse than theirs? and there
is an unfortunate history of go-it-alone development even on large
teams. With any language.
Thx again for sharing and risking the wrath of the Savages of CLL (it's
a long story).
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
From: Kenny Tilton
Subject: Java to Get Parentheses! [was Re: Thanks everyone]
Date:
Message-ID: <3EEB2B48.3000905@nyc.rr.com>
Kenny Tilton wrote:
>
>
> Tuang wrote:
>> (C (B (A foo))). So to do ABC to foo I have to write CBA foo with lots
>> of parentheses. Annoying. You're writing in the raw tree
>> structure, which makes writing the code a little harder than using
>> some nice syntax that gets translated into a tree internally.
>
>
> God no! The syntax /must/ map isomorphically to the semantics, the
> resulting runnable.
>
> I think what runs, I code what I think, what I think runs. Move over,
> Descartes.
>
> Lisp supports an incremental, evolutionary model of program design. I
> think, I code, I run, I learn, I refactor. Second verse, same as the
> first. That means I am forever grabbing chunks of the tree and moving
> them around, conceptually and syntactically, possible only because of
> the syntax-runnable isomorphism.
uh-oh, Java may be getting parens soon:
http://www.artima.com/intv/jackpot.html
"For the past several years, Java's creator James Gosling has been
working at Sun Labs, researching ways to analyze and manipulate programs
represented as annotated parse trees, a project called Jackpot.
Compilers have long built parse trees when they translate source code
into binary. But traditionally, programmers have worked with source code
primarily by manipulating text with editors. The goal of the Jackpot
project is to investigate the value of treating the parse tree as the
program at development time, not just at compile time.
...snip....
"James Gosling: It's a very different world when a program is an
algebraic structure rather than a bag of characters, when you can
actually do algebra on programs rather than just swizzling characters
around. A lot of things become possible."
Bingo.
--
kenny tilton
clinisys, inc
http://www.tilton-technology.com/
---------------------------------------------------------------
"Everything is a cell." -- Alan Kay
In article <················@nyc.rr.com>,
Kenny Tilton <·······@nyc.rr.com> wrote:
> uh-oh, Java may be getting parens soon:
>
> http://www.artima.com/intv/jackpot.html
>
No, it won't - parse trees will get an object-oriented interface
instead, and you will be able to navigate through the parse tree with
visitors. Not quite the same thing as in Lisp.
Of course, things will be much simpler when they are based on XML:
jex-project.sourceforge.net/ [1]
Some more news on the Java front - here's an interview with Guy Steele: http://java.sun.com/features/2003/05/steele_qa.html
Don't know what to think about it...
Pascal
[1] I am not serious here.
On Fri, Jun 13, 2003 at 02:40:52AM -0700, Tuang wrote:
> Also, I get tired of always writing backwards. A unix pipe sequence of
> operations A | B | C is written in the order of execution (do A, send
> the result to B, then send that to C and output). In Lisp it's
>
> (C (B (A foo))). So to do ABC to foo I have to write CBA foo with lots
> of parentheses. Annoying.
I would like to point out that this is hardly a unique characteristic of
Lisp. It is a characteristic of all function-supporting languages which
have function calls of that similar form.
Composition of functions: c(b(a(foo))) or (c (b (a foo)))
There sometimes exists composition operators so that (in SML): (c o b o
a) (foo) <=> c(b(a(foo))) but in general the more deeply nested a form
is, the sooner it is evaluated; a consequence of call-by-value semantics
(Haskell being an exception to this, naturally).
Unix's pipe operator breaks down with multiple arguments to the same
`function'; when the evaluation graph is a tree rather than linear. So
it is really not equivalent to function calls.
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Matthew Danish <·······@andrew.cmu.edu> wrote in
···························@lain.mapcar.org:
> On Fri, Jun 13, 2003 at 02:40:52AM -0700, Tuang wrote:
>> Also, I get tired of always writing backwards. A unix pipe sequence
>> of operations A | B | C is written in the order of execution (do A,
>> send the result to B, then send that to C and output). In Lisp it's
>>
>> (C (B (A foo))). So to do ABC to foo I have to write CBA foo with
>> lots of parentheses. Annoying.
>
> I would like to point out that this is hardly a unique characteristic
> of Lisp. It is a characteristic of all function-supporting languages
> which have function calls of that similar form.
>
> Composition of functions: c(b(a(foo))) or (c (b (a foo)))
>
I also must laugh and comment that the form FOO A B C is reverse polish,
which if the OP was coding in Forth would probably end up finding just
as annoying...
--
Best regards,
Jeff ··········@mfire.com
http://www.simforth.com
Matthew Danish <·······@andrew.cmu.edu> wrote:
> On Fri, Jun 13, 2003 at 02:40:52AM -0700, Tuang wrote:
>> Also, I get tired of always writing backwards. A unix pipe sequence of
>> operations A | B | C is written in the order of execution (do A, send
>> the result to B, then send that to C and output). In Lisp it's
>>
>> (C (B (A foo))). So to do ABC to foo I have to write CBA foo with lots
>> of parentheses. Annoying.
>
> I would like to point out that this is hardly a unique characteristic of
> Lisp. It is a characteristic of all function-supporting languages which
> have function calls of that similar form.
>
> Composition of functions: c(b(a(foo))) or (c (b (a foo)))
Heck, even in "natural-language-like" Perl we have:
print reverse sort @list;
... which is to say, sort first, then reverse, then print. However, it
also suggests the "natural" (snicker) way of reading compositions like
this: "Print a reversed version of a sorted version of @list."
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
On 10 Jun 2003 18:21:34 -0700, ········@hotmail.com (Tuang) wrote:
> I heard that Lisp hasn't had a significant upgrade since the 80's and
> that it has long since been abandoned by most of its former users.
>
> As far as I can tell, that's true. I'm looking at it anyway because
Lisp didn't have any significant upgrade since the publication of the ANSI
Common Lisp standard in 1994. Another way of looking at this is that Lisp
is a family of mature, stable languages.
> My first impressions -- SUBJECT TO CHANGE -- are as follows:
[...]
> The community appears to be on life-support. (Remember, subject to
> change, first impression, etc.) Not very encouraging, but you can't
Much more is going on in the Lisp world than even experienced users
suspect. If you have the opportunity, you might consider attending ILC
2003:
http://www.international-lisp-conference.org
Paolo
--
Paolo Amoroso <·······@mclink.it>
"Tuang" <········@hotmail.com> wrote in message
·································@posting.google.com...
> I heard that Lisp hasn't had a significant upgrade since the 80's and
> that it has long since been abandoned by most of its former users.
>
Since you say you are a long time programmer, answer this question.
Can the programming languages from the 80's be used to program all of
today's current applications? If they can, what does that say about
today's state of the art.
I would have to say the programmers of the 60s, 70s and 80s were very
sharp tacks. They are the one's that lay the foundations of the
computing. You know, Logic has not had a major upgrade for 2500 years
or so. It still seems useful.
> As far as I can tell, that's true. I'm looking at it anyway because
> I've often heard that just learning it enabled whole new ways of
> looking at problems, and that interests me. I'm hoping it turns out to
> be practical for real-life use, too. We'll see.
>
Well here you are after exposure to modern programming languages
LOOKING for something better. Somehow dissatisfied with what is,
but currently unable to place your finger on it. Why is that, hmmm?
> > If you have now had a chance to get familiar with Lisp, what are
> > your first impressions?
>
> My first impressions -- SUBJECT TO CHANGE -- are as follows:
>
> It's much more flexible than today's common languages. I can see why
> it would be called a "programmable programming language". Very nice
> for tackling interesting, hard, niche problems. Probably not very
> practical for big teams tackling common problems. I'm more interested
> in the former, so I like this. Most companies are more interested in
> the latter.
>
Hmm, lets take a look at the big team comment. Dispite repeated
attempts with more modern tools things like the US air traffic control
system defy successful reimplementation. Archaiac programming
practices and languages originally succeeded and modernism has
failed to reimplement. Last I heard, 50% of "large" projects still
outright fail.
http://www.rothstein.com/slbooks/sl287.htm
> I can see how I can apply lessons from Lisp to work in other
> languages, and that's interesting.
>
> The community appears to be on life-support. (Remember, subject to
> change, first impression, etc.) Not very encouraging, but you can't
> buy low and sell high if you don't find things that are undervalued by
> the market at large. I'd like to see a hero emerge, start from scratch
> with the best ideas from Lisp and no legacy baggage, look at the
> software world today, and come up with a new killer Lisp-like
> language. But then it wouldn't be a secret weapon, so it might be
> better if it remained un(re)discovered, as long as CMUCL or SBCL turn
> out to be solid enough for real commercial use.
Common Lisp has in it the best ideas from Lisp (that is why its called
Common), you just have to use them. You do not have to use all of it
and if you need a a new Killer Lisp-Like language, implement it using
CL.
You are full of doubt and need some assurance. I can assure you that
you are doing the right thing.
Wade
Wade Humeniuk <····@nospam.nowhere> wrote:
>
> I would have to say the programmers of the 60s, 70s and 80s were very
> sharp tacks. They are the one's that lay the foundations of the
> computing. You know, Logic has not had a major upgrade for 2500 years
> or so. It still seems useful.
Logic has had -many- upgrades in just the past few centuries, including
Boolean algebra, the predicate calculus (Frege), modal logic (Kripke),
and the relational algebra (Codd) which is the basis of modern database
systems.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
"Karl A. Krueger" <········@example.edu> writes:
> Wade Humeniuk <····@nospam.nowhere> wrote:
> >
> > I would have to say the programmers of the 60s, 70s and 80s were very
> > sharp tacks. They are the one's that lay the foundations of the
> > computing. You know, Logic has not had a major upgrade for 2500 years
> > or so. It still seems useful.
>
> Logic has had -many- upgrades in just the past few centuries, including
> Boolean algebra, the predicate calculus (Frege), modal logic (Kripke),
> and the relational algebra (Codd) which is the basis of modern database
> systems.
But none of these displaced the original.
No logician sat around saying "I can no longer use this old,
decayed stuff because it hasn't been upgraded recently."
It simply isn't logical, in any of these logical schemes, to conclude
that lack of recent update to the theory is evidence that the theory is
a bad idea.
Kent M Pitman <······@world.std.com> wrote:
> "Karl A. Krueger" <········@example.edu> writes:
>> Logic has had -many- upgrades in just the past few centuries, including
>> Boolean algebra, the predicate calculus (Frege), modal logic (Kripke),
>> and the relational algebra (Codd) which is the basis of modern database
>> systems.
>
> But none of these displaced the original.
>
> No logician sat around saying "I can no longer use this old,
> decayed stuff because it hasn't been upgraded recently."
And yet they do -not- use the old stuff, because it is not as general or
as practical as the new. Logicians today do not sit around composing
syllogisms in Aristotle's Greek, or sorites in the Victorian English of
Lewis Carroll.
This is even more the case when one considers practical applications of
logic (such as relational databases): "industry" rather than "research"
to use the eminently deconstructible dichotomy that's often played in
this froup.
> It simply isn't logical, in any of these logical schemes, to conclude
> that lack of recent update to the theory is evidence that the theory is
> a bad idea.
Modern logic does not reject the syllogism, but neither does it stop
with the syllogism and say "this is the standard, we need no more than
this".
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
"Karl A. Krueger" <········@example.edu> writes:
> Modern logic does not reject the syllogism, but neither does it stop
> with the syllogism and say "this is the standard, we need no more than
> this".
Has someone made such a statement about Lisp?
Kent M Pitman <······@world.std.com> wrote:
> "Karl A. Krueger" <········@example.edu> writes:
>> Modern logic does not reject the syllogism, but neither does it stop
>> with the syllogism and say "this is the standard, we need no more than
>> this".
>
> Has someone made such a statement about Lisp?
I have no idea. I was correcting the impression the previous poster had
given, that logic was a static affair for 2500 years.
--
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped. s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
"Karl A. Krueger" <········@example.edu> writes:
> Kent M Pitman <······@world.std.com> wrote:
> > "Karl A. Krueger" <········@example.edu> writes:
> >> Modern logic does not reject the syllogism, but neither does it stop
> >> with the syllogism and say "this is the standard, we need no more than
> >> this".
> >
> > Has someone made such a statement about Lisp?
>
> I have no idea. I was correcting the impression the previous poster had
> given, that logic was a static affair for 2500 years.
And in the process distracting from the key point that the poster was
trying to make.
The remark was simply an attempt to show that stability != death.
If you disagree, the correct thing is not to try to correct the remark
about logic, because in so doing you appear to suggest that you think
stability DOES equal death. The correct thing is to suggest a better
example where something has lived for a long time without being dead.
Maybe the Bible is a better example. ;) I keep getting told that it is
a living document even though its text never changes.
>>>>> "Kent" == Kent M Pitman <······@world.std.com> writes:
Kent> The remark was simply an attempt to show that stability != death.
Kent> If you disagree, the correct thing is not to try to correct the remark
Kent> about logic, because in so doing you appear to suggest that you think
Kent> stability DOES equal death. The correct thing is to suggest a better
Kent> example where something has lived for a long time without being dead.
Euclidean geometry?
Ray
"Karl A. Krueger" <········@example.edu> writes:
> > No logician sat around saying "I can no longer use this old,
> > decayed stuff because it hasn't been upgraded recently."
>
> And yet they do -not- use the old stuff, because it is not as general or
> as practical as the new. Logicians today do not sit around composing
> syllogisms in Aristotle's Greek, or sorites in the Victorian English of
> Lewis Carroll.
Despite the great success of mathematical logic in the last century or
so, some of the fundamental stuff needed for an adequate formal
semantics for natural language hasn't moved very far since
Aristotle. E.g. the logic of (natural language) conditionals is still
quite poorly understood (if there hasn't been any major works that
I've missed since I left academia 8 years ago).
--
(espen)
"Karl A. Krueger" <········@example.edu> wrote in message ·················@baldur.whoi.edu...
> Wade Humeniuk <····@nospam.nowhere> wrote:
> >
> > I would have to say the programmers of the 60s, 70s and 80s were very
> > sharp tacks. They are the one's that lay the foundations of the
> > computing. You know, Logic has not had a major upgrade for 2500 years
> > or so. It still seems useful.
>
> Logic has had -many- upgrades in just the past few centuries, including
> Boolean algebra, the predicate calculus (Frege), modal logic (Kripke),
> and the relational algebra (Codd) which is the basis of modern database
> systems.
Have these been major upgrades (1.0 to 2.0) or just 1.1 to 1.2? :)
So even upgrades to formal representations to Logic have accelerated
in the past few centuries. I hope we are not entering upgrade hell.
But seriously I was trying to make a point that OLD does not mean
irrelevant and that the idea that something 20 years old in the computing
world makes it passe. I am unsure of where this mentality is coming
from (disposable society?).
Wade
On Wed, Jun 11, 2003 at 06:50:28PM +0000, Wade Humeniuk wrote:
> "Karl A. Krueger" <········@example.edu> wrote in message
> ·················@baldur.whoi.edu...
> > Wade Humeniuk <····@nospam.nowhere> wrote:
> > > I would have to say the programmers of the 60s, 70s and 80s were
> > > very sharp tacks. They are the one's that lay the foundations of
> > > the computing. You know, Logic has not had a major upgrade for
> > > 2500 years or so. It still seems useful.
> > Logic has had -many- upgrades in just the past few centuries,
> > including Boolean algebra, the predicate calculus (Frege), modal
> > logic (Kripke), and the relational algebra (Codd) which is the basis
> > of modern database systems.
> Have these been major upgrades (1.0 to 2.0) or just 1.1 to 1.2? :)
The syllogism is basically useless, so everything that came after it is
a major upgrade, indubitably. I wouldn't consider it a linear upgrade
path after predicate logic, though, it is more like having many
applications with different views of the world. Just because
higher-order logics exist doesn't negate the usefulness of first-order
logic (for one thing, they may be too powerful).
It is interesting to note that the logic world was held back by the
"industry standard" for about 2000 years, from Aristotle til the 19th
century logicians. I wonder how many "computer years" that is.
> But seriously I was trying to make a point that OLD does not mean
> irrelevant
The syllogism is irrelevant as far as modern logic is concerned. It can
happen. How about Leibniz's theory of monads, created to accomodate
Aristotle's logic system? The only people still using that are the
Haskellers. ;-)
--
; Matthew Danish <·······@andrew.cmu.edu>
; OpenPGP public key: C24B6010 on keyring.debian.org
; Signed or encrypted mail welcome.
; "There is no dark side of the moon really; matter of fact, it's all dark."
Wade Humeniuk wrote:
> But seriously I was trying to make a point that OLD does not mean
> irrelevant and that the idea that something 20 years old in the computing
> world makes it passe. I am unsure of where this mentality is coming
> from (disposable society?).
from hardware and software manufacturers, who have found that it is a great
way to sell their products to people who don't really need them.
--
Joost Kremers
since when is vi an editor? a discussion on vi belongs in
comp.tools.unusable or something...
"Wade Humeniuk" <····@nospam.nowhere> wrote in message news:<·······················@news0.telusplanet.net>...
> "Tuang" <········@hotmail.com> wrote in message
> ·································@posting.google.com...
> > I heard that Lisp hasn't had a significant upgrade since the 80's and
> > that it has long since been abandoned by most of its former users.
> >
>
> Since you say you are a long time programmer, answer this question.
> Can the programming languages from the 80's be used to program all of
> today's current applications?
I'm not sure I understand the question. The answer is certainly yes in
the Turing completeness sense, though it would be odd if that's what
you were asking. But getting a Fortran applet to run securely inside a
sandboxed VM on most of the world's browsers, regardless of platform,
wouldn't be a task I'd want to take on.
> If they can, what does that say about
> today's state of the art.
I'm guessing that you're suggesting that we haven't made much progress
in programming languages between the 80s and now. If so then for the
most part I agree.
>
> I would have to say the programmers of the 60s, 70s and 80s were very
> sharp tacks. They are the one's that lay the foundations of the
> computing. You know, Logic has not had a major upgrade for 2500 years
> or so. It still seems useful.
Yes, but security, concurrency, networking protocols,
internationalization, and so on have moved ahead significantly in the
last decade, and these need to be a part of the foundation now, too.
(I don't know what their status is specifically in CL, so I'm just
responding generally, not criticizing CL.)
>
> > As far as I can tell, that's true. I'm looking at it anyway because
> > I've often heard that just learning it enabled whole new ways of
> > looking at problems, and that interests me. I'm hoping it turns out to
> > be practical for real-life use, too. We'll see.
> >
>
> Well here you are after exposure to modern programming languages
> LOOKING for something better. Somehow dissatisfied with what is,
> but currently unable to place your finger on it. Why is that, hmmm?
Again, not quite clear about your meaning, but I have some very
specific complaints about each of the big, popular languages of today,
and I'm always watching for solutions of whatever sort.
>
>
> > > If you have now had a chance to get familiar with Lisp, what are
> > > your first impressions?
> >
> > My first impressions -- SUBJECT TO CHANGE -- are as follows:
> >
> > It's much more flexible than today's common languages. I can see why
> > it would be called a "programmable programming language". Very nice
> > for tackling interesting, hard, niche problems. Probably not very
> > practical for big teams tackling common problems. I'm more interested
> > in the former, so I like this. Most companies are more interested in
> > the latter.
> >
>
> Hmm, lets take a look at the big team comment. Dispite repeated
> attempts with more modern tools things like the US air traffic control
> system defy successful reimplementation. Archaiac programming
> practices and languages originally succeeded and modernism has
> failed to reimplement. Last I heard, 50% of "large" projects still
> outright fail.
>
> http://www.rothstein.com/slbooks/sl287.htm
Large projects are larger than they used to be, by virtue of Moore's
Law. I think languages like C# and Java are best for big team projects
for a number of reasons, not least being their *lack* of Lisp-style
flexibility.
As I gain more experience with Lisp, I may change my mind about that,
of course.
>
>
> > I can see how I can apply lessons from Lisp to work in other
> > languages, and that's interesting.
> >
> > The community appears to be on life-support. (Remember, subject to
> > change, first impression, etc.) Not very encouraging, but you can't
> > buy low and sell high if you don't find things that are undervalued by
> > the market at large. I'd like to see a hero emerge, start from scratch
> > with the best ideas from Lisp and no legacy baggage, look at the
> > software world today, and come up with a new killer Lisp-like
> > language. But then it wouldn't be a secret weapon, so it might be
> > better if it remained un(re)discovered, as long as CMUCL or SBCL turn
> > out to be solid enough for real commercial use.
>
>
> Common Lisp has in it the best ideas from Lisp (that is why its called
> Common), you just have to use them. You do not have to use all of it
> and if you need a a new Killer Lisp-Like language, implement it using
> CL.
That's probably what I would do, at least thru several prototypes, if
I ever decided I had to create my own language. I'm VERY impressed
with how easy it seems to be to create custom languages within Lisp.
>
> You are full of doubt and need some assurance. I can assure you that
> you are doing the right thing.
Thanks.
Kenny Tilton <·······@nyc.rr.com> wrote:
> Hey, I'm doing an informal survey of any newbie I run into:
> 1. How did you pick Lisp when you went looking for something new?
It wasn't really all that new. I'd run into Scheme in CS years ago --
never got particularly good at it, but saw enough to find it
interesting. C++ was just coming out when I was in college, I mostly
worked in Pascal (blech) and C. Since, I stopped programming for a
while, did typesetting/graphics stuff -- started programming again when
everything became applescriptable. I really got to like applescript as
a language (much better than C or Pascal), but the implentation had too
many arbitrary "it's only a glue language" restrictions, and because it
was strictly interpreted, certain kinds of things were just too slow to
be workable.
So a couple years ago, I decided it would be good to learn some general
purpose programming again. I noticed that very few people were using
raw C anymore, and trying to hack the mac with it got very tedious. I
took a crack at C++ and some standard frameworks, and this helped, but
it felt kind of ugly. It seemed like you had to do an awful lot of
bookeeping. After years of working with applescript, I got used to data
carrying type information rather than variables. Having worked that way
for a while, doing static typing felt like wearing a straitjacket. I
listened to the static type pundits talk about how much easier that made
your life, and wondered whether it was really worth all the hassle.
As I got back into reading programming literature, occasional mentions
of non-mainstream languages piqued my interest. I took a look around to
see what kinds of languages were available cheaply for macs. I took a
look at smalltalk after seeing some XP stuff. I was never particularly
interested in Java because every piece of software I'd ever used that
was written in Java or required the java VM, was flaky beyond belief.
Quick looks didn't show me anything I couldn't do in C++.
Then I remembered Scheme, and how I often saw programs in it that seemed
like they were written in domain languages. I had only become briefly
acquainted with it in college, never taking a course that required me to
hack extensively in it. I loaded up comp.lang.lisp and I googled around
to see what people were still doing with lisp or scheme and discovered
that it was "dead", but the body was obviously very warm. People still
used it all the time, and quality implementations were available for
most platforms. Not only that, the people writing in it seemed to think
a lot more like me than the typical C++ programmer did.
When I started to learn them for real, I realized what I'd been missing
all these years. When I was a boy and first learned to use and program
computers (in TRS-80 and applesoft BASIC, then 6502 and Z80 assembly), I
was constantly trying to extrapolate principles and thinking "I should
be able to do *this* too, in this way", but always running into
implementation limitations. I actually decided I liked *assembler* in
spite of the low-level agony, because there were no restrictions.
Lisp took me back to that point and let me go all those places that
other languages feared to tread and other programmers simply told me
"You don't want to look in there."
But I've since discovered that "real" languages let you do these as a
matter of course. I was hardly the first person to yearn for a higher
level of abstraction -- that yearning appears to be common to nearly all
good programmers, and a great number of them have apparently found their
way to some form of lisp as a result. Now I finally understand why most
of the *serious* hackers I knew in college used some form of lisp.
I gravitated to CL primarily because of the apparent stability and the
commercial concerns of the standard vendors, even though I think I like
scheme syntax better. I'm still not a serious lispnik, so I may feel
differently once I start making more powerful use of macros.
> 2. And why not, say, Python or Ruby?
They don't seem to be *fundamentally* different from what else is
available in the way that lisp is. It took learning lisp and then
looking at something like Norvig's "Python for lisp programmers" for me
to even realize that Python was more than just an interpreted C variant.
I might consider learning Python now, only because there's an OSA Python
out there.
Also it took looking at lisp to realize that the late-binding and
dynamism which I loved in AS don't necessarily imply that a language is
slow and non-industrial-strength.
Yes, I know that premature optimization is evil, but when you work in
purely interpreted languages (applescript) as a matter of course, you
run into a need for optimization so often that I got used to optimizing
as a matter of habit. One of the things I was looking for in a new
language was the speed necessary to allow me to do computationally
intensive things in my programs.
Michael
On 8403 day of my life Kenny Tilton wrote:
> Hey, I'm doing an informal survey of any newbie I run into:
>
> 1. How did you pick Lisp when you went looking for something new?
First time I saw Lisp when I was 14 (9 year ago! my god!). Someone
brought CDROM with different compilers sources to computer class, and
there were 3 lisp translaters. I guess one of them was CLisp (I
remember I tried to understand something like LISP-tutorial.txt from
CLisp distro, but failed :)
I tried sample programs from the compilers; one of samples drew Dragon
Tail fractal.
But I haven't wrote any program at that time.
Though I found Lisp syntax very funny and remembered the name. :)
Later I found book "Mir Lispa" (World of Lisp) -- translation form
Finnish 8-0, authors are Huvennen and Seppanen :)
> 2. And why not, say, Python or Ruby?
When I heared about them first time, I knew Lisp quite well :)
> 3. Any particular reason you were looking for something new to learn?
Just for fun I tried Forth last week but I do not like it.
--
Ivan Boldyrev
Perl is a language where 2 x 2 is not equal to 4.
Jonatan Ring wrote:
> Hi. Im an 18 year old student who have programming as a hobby. I know C++
> and Java and have made some programs in Visual Basic. I am interested in
> trying to learn some lisp. Not because I have any applications suited for
> it, but because I want to try something new.
>
> I wondered if you have any recomendations on tutorials for lisp and any
> sugestions for a compiler and linker. I cannot afford a too expensive
> software kit, but then I will not need the most advanced or cutting edge
> tools.
>
> I simply want to make some simple applications and play around with the
> language.
>
> Thankful in advance:
>
> Jonatan Ring
>
>
Jonathan--
I would look first here: http://www.lisp.org/table/contents.htm and this
guy seems to know more programming languages than anyone I've come
across: http://cbbrowne.com/info/lisp.html
Thomas Rivas