OK, I've read several web pages and PDFs on LISP. I think I get the
basics of how to write functions and macros, but just the basics.
That said, what I don't "GET" is how to write a lisp program.
The way I go to learn a new language is to do something fairly basic,
like text processing on a file or processing the output from a basic
Unix utility, like using the output from a few 'ps -eo
pid,pcpu,vsz,args' commands to look for memory leaks. I'm guessing
these are not the standard solution domain for LISP, because I
couldn't believe how difficult it was to just to find out how to read
a file in LISP. The first two books I looked through, "Common LISP,
an Interactive Approach" and "Common LISP: A Gentle Introduction",
didn't even touch on the subject of reading a file. Then I found "On
Lisp" and "Practical Common LISP", and they made more sense to me, and
told me about the "with-open-file" macro among other things, but I
guess I still don't "Get" functional programming. Can anyone suggest
any book or web resource that can, maybe, help me wrap my head around
it?
Thanks,
Bryan
On Jul 20, 8:40 am, Bryan <············@gmail.com> wrote:
> OK, I've read several web pages and PDFs on LISP. I think I get the
> basics of how to write functions and macros, but just the basics.
> That said, what I don't "GET" is how to write a lisp program.
>
> The way I go to learn a new language is to do something fairly basic,
> like text processing on a file or processing the output from a basic
> Unix utility, like using the output from a few 'ps -eo
> pid,pcpu,vsz,args' commands to look for memory leaks. I'm guessing
> these are not the standard solution domain for LISP, because I
> couldn't believe how difficult it was to just to find out how to read
> a file in LISP.
Lisp, not LISP. No, I/O in Lisp is nothing unusual.
> The first two books I looked through, "Common LISP,
> an Interactive Approach" and "Common LISP: A Gentle Introduction",
> didn't even touch on the subject of reading a file. Then I found "On
> Lisp" and "Practical Common LISP", and they made more sense to me, and
> told me about the "with-open-file" macro among other things, but I
> guess I still don't "Get" functional programming. Can anyone suggest
> any book or web resource that can, maybe, help me wrap my head around
> it?
>
> Thanks,
> Bryan
Just use a Common Lisp reference like the Common Lisp HyperSpec to get
an overview.
The CLHS has dictionary pages for the various chapters which list all
the
available functions, macros, variables.
Filenames:
http://www.lispworks.com/documentation/lw50/CLHS/Body/c_filena.htm
Files:
http://www.lispworks.com/documentation/lw50/CLHS/Body/c_files.htm
Streams
http://www.lispworks.com/documentation/lw50/CLHS/Body/c_stream.htm
There is nothing magical.
1. You have a filename: "/foo/bar.text"
2. You use WITH-OPEN-FILE to get a stream of a certain kind (binary/
text, input/output, ...)
3. You use functions like READ-CHAR, READ-LINE, READ-BYTE, READ-
SEQUENCE to read from the stream
For Lisp data there is also the function READ.
4. Printing is done with WRITE, PRINT, WRITE-CHAR, WRITE-BYTE, WRITE-
STRING, WRITE-LINE, WRITE-SEQUENCE and FORMAT.
There is quite a bit functionality. Lisp data can be output
formatted with PPRINT.
Get also the Common Lisp Quick Reference, which gives a good overview
about
the Common Lisp functionality and can be printed and used as a nice
reference - especially handy for newcomers!!
http://clqr.berlios.de/
From there you might want to look for the usual regexp library or some
parser for more complex reading.
Lisp itself also provides a programmable reader, for (mostly) Lisp
like data.
Bryan <············@gmail.com> writes:
> OK, I've read several web pages and PDFs on LISP. I think I get the
> basics of how to write functions and macros, but just the basics.
> That said, what I don't "GET" is how to write a lisp program.
More or less the same way you write a program in any language, in terms
of the final product ebut thanks to some of Lisp's features, programmers
tend to work a little bit differently.
First, since a Lisp is a live environment, we don't batch-compile our
programs. Instead we do it piecemeal, loading (and often compiling)
individual functions as we write them or change them. Second, since Lisp
is an interactive environment, we can call individual functions for
testing without any elaborate testing harness.
The upshot is that there's no need to start with a main()
function. Instead you start with whatever piece of the program seems
best to you. For example, if you want to do some text processing, you
might start with the processing function, before you even deal with
reading from the file. Or you might start with the file-reading
function. Whichever you like. And you just add functions until you've
got something like the functionality you want, at which point you put a
nice interface on it (write your main function) and call it a day.
> The way I go to learn a new language is to do something fairly basic,
> like text processing on a file or processing the output from a basic
> Unix utility, like using the output from a few 'ps -eo
> pid,pcpu,vsz,args' commands to look for memory leaks. I'm guessing
> these are not the standard solution domain for LISP, because I
> couldn't believe how difficult it was to just to find out how to read
> a file in LISP. The first two books I looked through, "Common LISP,
> an Interactive Approach" and "Common LISP: A Gentle Introduction",
> didn't even touch on the subject of reading a file. Then I found "On
> Lisp" and "Practical Common LISP", and they made more sense to me, and
> told me about the "with-open-file" macro among other things,
Common Lisp is fine for text processing. I think this is more a case of
knowing where to look for the appropriate features. Communicating with
Unix programs is not a fundamental part of CL, but most implementations
should provide an extension for this. It's not something you'd find in a
textbook, since it's implementation-dependant.
> but I guess I still don't "Get" functional programming.
Common Lisp isn't a functional language, although calling it one is a
common meme. It's multi-paradigm, and does have good support for some
styles of functional programming. Don't approach it like you have to
write your code in some bizarre way. What you want to do is take
advantage of your newfound freedom to structure your code in a cleaner
way, and take advantage of interactive development to save yourself time
and trouble.
For example, since nearly every form in CL returns a value, you can make
use of fewer variable assignments, and just let values “fall through”,
and this especially includes if statements and loops of various
kinds. Higher-order functions are easy to do, especially since when you
call them you can use lambda to construct single-use function
arguments. You can return any sort of value from a function, so code
that you might not have been able to break into functions in C can now
be made modular. You can write in a compositional style, where most of
each function is just nested function calls.
Start with the part of the program you do know how to write. You can do
it bottom-up, since it's easy to let functions float around in your Lisp
until you connect them together. With a nice environment like SLIME, you
don't even need to copy/paste to the REPL. make your changes and add new
code. Do use the REPL to try things out when you need to know something
(like whether a line of code does what you think it does, or whether the
function you just compiled works right).
> Can anyone suggest any book or web resource that can, maybe, help me
> wrap my head around it?
I think you've found some good resources already. You need to get your
hands dirty to get the hang of it.
On Jul 20, 2:40 am, Bryan <············@gmail.com> wrote:
> OK, I've read several web pages and PDFs on LISP. I think I get the
> basics of how to write functions and macros, but just the basics.
> That said, what I don't "GET" is how to write a lisp program.
>
> The way I go to learn a new language is to do something fairly basic,
> like text processing on a file or processing the output from a basic
> Unix utility, like using the output from a few 'ps -eo
> pid,pcpu,vsz,args' commands to look for memory leaks. I'm guessing
> these are not the standard solution domain for LISP, because I
> couldn't believe how difficult it was to just to find out how to read
> a file in LISP. The first two books I looked through, "Common LISP,
> an Interactive Approach" and "Common LISP: A Gentle Introduction",
> didn't even touch on the subject of reading a file. Then I found "On
> Lisp" and "Practical Common LISP", and they made more sense to me, and
> told me about the "with-open-file" macro among other things, but I
> guess I still don't "Get" functional programming. Can anyone suggest
> any book or web resource that can, maybe, help me wrap my head around
> it?
>
> Thanks,
> Bryan
Bryan,
I'm pretty much in the same situation as you, except maybe a year
ahead. I've followed the advice to learn a new language every year,
and in the past decade I've learned about 12 different languages and
variants (such as C/C++).
I'm also a working programmer and spend my working days writing code,
for which I am paid a salary by my employer, so this isn't just a
hobby for me.
Several years ago when I started Lisp, I hit a brick wall. I made no
headway whatsoever. Since then, I have progressed to the point where I
am now writing Lisp scripts to do useful things. I'm no expert, but at
least I can write and read Lisp on a basic level.
1. You can purchase Lisp books inexpensively or acquire them for free.
Start one and study it until you hit a dead end. Then study another
one. Cycle through several, then start over. This practice has helped
me with the languages that I use on a daily basis, and has helped me
with Lisp. Here are the ones that have proven helpful to me:
Wilensky, Common LISPCraft
Winston and Horn, Lisp, 3rd Edition
Seibel, Practical Common Lisp
Here are three others that aren't for beginners:
Graham, Common Lisp
Keene, OOP in Common Lisp
Lamkins, Successful Common Lisp
2. Use the language. This is the ONLY way you will learn it. If you
don't use it, you won't learn it.
3. Bite the bullet and learn emacs.
CC
ccc31807 wrote:
> Several years ago when I started Lisp, I hit a brick wall. I made no
> headway whatsoever. Since then, I have progressed to the point where I
> am now writing Lisp scripts to do useful things. I'm no expert, but at
> least I can write and read Lisp on a basic level.
Funny, it took me less than two weeks to go from zero to significant
mastery (including a couple of sophisticated macros).
> 1. You can purchase Lisp books inexpensively or acquire them for free.
> Start one and study it until you hit a dead end. Then study another
> one. Cycle through several, then start over. This practice has helped
> me with the languages that I use on a daily basis, and has helped me
> with Lisp. Here are the ones that have proven helpful to me:
> Wilensky, Common LISPCraft
> Winston and Horn, Lisp, 3rd Edition
> Seibel, Practical Common Lisp
The last is recommended and can be read without paying or registering
online. Google the name and you should find it.
> 2. Use the language. This is the ONLY way you will learn it. If you
> don't use it, you won't learn it.
This is true of most, if not all, applied skills.
> 3. Bite the bullet and learn emacs.
Ugly and unnecessary since there are other, more modern development
environments for at least some Lisps.
On Jul 20, 3:52 pm, Tetrahedral Quartz <········@gmail.com> wrote:
> ccc31807 wrote:
> > Several years ago when I started Lisp, I hit a brick wall. I made no
> > headway whatsoever. Since then, I have progressed to the point where I
> > am now writing Lisp scripts to do useful things. I'm no expert, but at
> > least I can write and read Lisp on a basic level.
>
> Funny, it took me less than two weeks to go from zero to significant
> mastery (including a couple of sophisticated macros).
Were you trying to do it in about 30 minutes a week? I had a full time
job, was a full time graduate student, had a part time job, a family
(including a wife which is a really high maintenance item if you ever
picked up one of them), and a couple of organizations that I was
active in. My efforts at learning Lisp were limited to light reading
just before bedtime and most nights I actually fell asleep before
finishing the first page. I remember that it took about three months
to finish one chapter.
By way of contrast, it's common in graduate school for the instructor
to specify a language and expect the students to gain proficiency in
about two weeks, so your experience isn't that unusual. I can't
remember all the languages I encountered in this way, but I remember
learning C, C++, C++CLR, C#, Scheme, Python, MASM, Visual Basic 6.0
and .NET, Z, XSLT, and some others in this way, to say nothing of the
web technologies that you just assumed to know, like PHP, JSP, ASP,
ColdFusion, JavaScript, CSS, UML, and so on.
I wouldn't make any assumptions about reading about a language with no
connection to work or school to draw any conclusions about the reader.
I've got a COBOL book that I've had for many years and a Ruby book
that I bought three years ago, and I've yet to read more than a couple
of chapters in either. Do you care to draw a conclusion from that?
CC
ccc31807 wrote:
> On Jul 20, 3:52 pm, Tetrahedral Quartz <········@gmail.com> wrote:
>> ccc31807 wrote:
>>> Several years ago when I started Lisp, I hit a brick wall. I made no
>>> headway whatsoever. Since then, I have progressed to the point where I
>>> am now writing Lisp scripts to do useful things. I'm no expert, but at
>>> least I can write and read Lisp on a basic level.
>> Funny, it took me less than two weeks to go from zero to significant
>> mastery (including a couple of sophisticated macros).
>
> Were you trying to do it in about 30 minutes a week?
Nah, a couple hours plus a day.
> I wouldn't make any assumptions about reading about a language with no
> connection to work or school to draw any conclusions about the reader.
Neither would I, and indeed, I did not. You're the only one talking
about drawing conclusions about the reader.
> I've got a COBOL book that I've had for many years and a Ruby book
> that I bought three years ago, and I've yet to read more than a couple
> of chapters in either. Do you care to draw a conclusion from that?
COBOL sucks? :)
On Jul 20, 10:52 pm, Tetrahedral Quartz <········@gmail.com> wrote:
> ccc31807 wrote:
> > Several years ago when I started Lisp, I hit a brick wall. I made no
> > headway whatsoever. Since then, I have progressed to the point where I
> > am now writing Lisp scripts to do useful things. I'm no expert, but at
> > least I can write and read Lisp on a basic level.
>
> Funny, it took me less than two weeks to go from zero to significant
> mastery (including a couple of sophisticated macros).
May we see them?
> > 3. Bite the bullet and learn emacs.
>
> Ugly and unnecessary since there are other, more modern development
> environments for at least some Lisps.
What does it mean for software to be modern? Software is either
maintained or not. Emacs is maintained. Unless you meant that those
other environments provide modern features which emacs doesn't have -
or couldn't have, then I'd like to know which evns these are.
vippstar wrote:
> On Jul 20, 10:52 pm, Tetrahedral Quartz <········@gmail.com> wrote:
>> ccc31807 wrote:
>>> Several years ago when I started Lisp, I hit a brick wall. I made no
>>> headway whatsoever. Since then, I have progressed to the point where I
>>> am now writing Lisp scripts to do useful things. I'm no expert, but at
>>> least I can write and read Lisp on a basic level.
>> Funny, it took me less than two weeks to go from zero to significant
>> mastery (including a couple of sophisticated macros).
> May we see them?
Sorry, don't have them handy right now. But one of them performs some
symbol substitutions in the body code (think of something sort of like
with-slots, only implemented without benefit of symbol-macrolet -- won't
handle name collisions gracefully, but what the hey, it works for what I
use it for) and one of them transforms mathematical ASTs into numerical
functions that do certain sophisticated checks (and have certain
sophisticated optimizations) as part of the implementation of a
symbolic-computation DSL (itself part of a larger project).
>>> 3. Bite the bullet and learn emacs.
>> Ugly and unnecessary since there are other, more modern development
>> environments for at least some Lisps.
> What does it mean for software to be modern? Software is either
> maintained or not. Emacs is maintained.
A century-old building might still be maintained and inhabited, but it
is not modern. You wouldn't need to be an architect to look at it and
notice that it is, say, a brownstone with Gothic gabling, arches, and
gargoyles, and not a glass tower reaching halfway to the sky. Nor to
notice its lack of a decent elevator, vs. the glass tower's whole bank
of the things.
> Unless you meant that those other environments provide modern
> features which emacs doesn't have
That century-old building has floorspace, windows, and a door, much like
the glass tower, and perhaps both have an elevator; so nothing stands
out in a direct features-vs.-features comparison. Yet once again I doubt
you'll find it as fast to get to the one's fourth floor as to the
other's fortieth. User interface matters.
Tetrahedral Quartz <········@gmail.com> writes:
> That century-old building has floorspace, windows, and a door, much
> like the glass tower, and perhaps both have an elevator; so nothing
> stands out in a direct features-vs.-features comparison. Yet once
> again I doubt you'll find it as fast to get to the one's fourth floor
> as to the other's fortieth. User interface matters.
Which, I think, is the whole argument for Emacs. Your analogy makes
sense, except for the part where Emacs is implied not to have
elevators. Maybe it's more like shoes. Yeah, running shoes are pretty
fancy. But they're awkward for the foot and don't actually enhance your
running abilities.
Paul Donnelly wrote:
> Tetrahedral Quartz <········@gmail.com> writes:
>
>> That century-old building has floorspace, windows, and a door, much
>> like the glass tower, and perhaps both have an elevator; so nothing
>> stands out in a direct features-vs.-features comparison. Yet once
>> again I doubt you'll find it as fast to get to the one's fourth floor
>> as to the other's fortieth. User interface matters.
>
> Which, I think, is the whole argument for Emacs. Your analogy makes
> sense, except for the part where Emacs is implied not to have
> elevators.
I said "decent" elevators. Maybe it has one of those creaky old
mechanical contraptions operated by a hand crank. :)
> Maybe it's more like shoes. Yeah, running shoes are pretty
> fancy. But they're awkward for the foot and don't actually enhance your
> running abilities.
Actually a lot of ergonomic science goes into a pair of sneakers.
Comfort and bouncy rubber stuff to reduce the amount of energy lost with
each footstep. You can in fact walk or run farther on them before your
feet get tired -- I should know, having walked the same distance over
the same terrain in good running shoes and in boots on separate
occasions (with the difference in footwear owing to weather).
On 2009-07-21 14:36:25 -0400, Tetrahedral Quartz <········@gmail.com> said:
> Actually a lot of ergonomic science goes into a pair of sneakers.
> Comfort and bouncy rubber stuff to reduce the amount of energy lost
> with each footstep. You can in fact walk or run farther on them before
> your feet get tired -- I should know, having walked the same distance
> over the same terrain in good running shoes and in boots on separate
> occasions (with the difference in footwear owing to weather).
Actually, the dirty secret of the atletic footwear industry is that
athletes who use the most "advanced" shoes are more, not less prone to
injury. Barefoot is actually best, and shoes that come the closest to
barefoot are the safest.
<http://www.dailymail.co.uk/home/moslive/article-1170253/The-painful-truth-trainers-Are-expensive-running-shoes-waste-money.html>
--
Raffael Cavallaro
Raffael Cavallaro wrote:
> On 2009-07-21 14:36:25 -0400, Tetrahedral Quartz <········@gmail.com> said:
>
>> Actually a lot of ergonomic science goes into a pair of sneakers.
>> Comfort and bouncy rubber stuff to reduce the amount of energy lost
>> with each footstep. You can in fact walk or run farther on them before
>> your feet get tired -- I should know, having walked the same distance
>> over the same terrain in good running shoes and in boots on separate
>> occasions (with the difference in footwear owing to weather).
>
> Actually, the dirty secret of the atletic footwear industry is that
> athletes who use the most "advanced" shoes are more, not less prone to
> injury. Barefoot is actually best, and shoes that come the closest to
> barefoot are the safest.
>
> <http://www.dailymail.co.uk/home/moslive/article-1170253/The-painful-truth-trainers-Are-expensive-running-shoes-waste-money.html>
>
Fascinating. I knew there was a reason I read this newsgroup.
My tennis buddy has started experiencing inexplicable foot pain, first
on one foot and then the other, using top-flight, new footgear. Just
sent him a link to the Nike Free. No, barefoot tennis on hardcourt does
not sound "best", unless you mean the hot medical practitioners one can
meet in ERs. Well, maybe healthiest because then we would play half as
hard, but that can be a hard sell to weekend jocks.
kt
On 2009-07-21 15:23:53 -0400, Kenneth Tilton <·········@gmail.com> said:
> No, barefoot tennis on hardcourt does not sound "best", unless you mean
> the hot medical practitioners one can meet in ERs. Well, maybe
> healthiest because then we would play half as hard, but that can be a
> hard sell to weekend jocks.
Well not with feet and leg muscles that have been weakened by decades
of wearing athletic shoes. But with proper conditioning, yes. Remember,
Abebe Bikila won the 1960 Olympic Marathon barefoot on asphalt. I don't
think even the longest tennis match equals this amount of running on
such an unforgiving surface. The point is that the foot is an active
shock absorber [1] when properly conditioned; athletic shoes cause the
foot and lower leg to lose proper conditioning by replacing the foot's
natural active shock absorbtion with a passive one.
In the west we have been conditioned to believe that shoes are
necessary for foot support; but they were originally used for warmth
and dryness, not foot support. The human foot is perfectly suited for
running over very difficult terrain without shoes of any kind, and
throughout the warmer, drier parts of the world, aboriginal people
spend much of their lives outdoors with no shoes.
That said, one does want some protection from weather, so the shoe that
is closest to barefoot is best; it causes your feet and lower legs to
become stronger, and allows the foot to sense the running surface, both
of which reduce the chance of injury.
[1] the nerves in the foot sense unevenness/hazards in the terrain and
the brain adjusts foot position/attitude/muscle tension accordingly.
--
Raffael Cavallaro
Tetrahedral Quartz <········@gmail.com> writes:
> vippstar wrote:
>
>> Unless you meant that those other environments provide modern
>> features which emacs doesn't have
>
> That century-old building has floorspace, windows, and a door, much
> like the glass tower, and perhaps both have an elevator; so nothing
> stands out in a direct features-vs.-features comparison. Yet once
> again I doubt you'll find it as fast to get to the one's fourth floor
> as to the other's fortieth. User interface matters.
It may also happen that if you want to add some personal decoration,
you may more easily plant a nail in the walls of the century-old
building than in the glass of your sky scrap. Err...
--
__Pascal Bourguignon__
Pascal J. Bourguignon wrote:
> Tetrahedral Quartz <········@gmail.com> writes:
>
>> vippstar wrote:
>>
>>> Unless you meant that those other environments provide modern
>>> features which emacs doesn't have
>> That century-old building has floorspace, windows, and a door, much
>> like the glass tower, and perhaps both have an elevator; so nothing
>> stands out in a direct features-vs.-features comparison. Yet once
>> again I doubt you'll find it as fast to get to the one's fourth floor
>> as to the other's fortieth. User interface matters.
>
> It may also happen that if you want to add some personal decoration,
> you may more easily plant a nail in the walls of the century-old
> building than in the glass of your sky scrap. Err...
The analogy breaks down there. The last time I checked, modern
environments like NetBeans are quite customizable. While not looking
like something found in the attic that would interest the producers of
Antiques Roadshow, and while handling like a Maserati on steroids
instead of a Stanley Steamer.
Tetrahedral Quartz <········@gmail.com> writes:
> vippstar wrote:
>> On Jul 20, 10:52 pm, Tetrahedral Quartz <········@gmail.com> wrote:
>>> ccc31807 wrote:
>>>> Several years ago when I started Lisp, I hit a brick wall. I made no
>>>> headway whatsoever. Since then, I have progressed to the point where I
>>>> am now writing Lisp scripts to do useful things. I'm no expert, but at
>>>> least I can write and read Lisp on a basic level.
>>> Funny, it took me less than two weeks to go from zero to significant
>>> mastery (including a couple of sophisticated macros).
>> May we see them?
>
> Sorry, don't have them handy right now. symbol substitutions in the body
> code (think of something sort of like with-slots, only implemented
> without benefit of symbol-macrolet -- won't handle name collisions
> gracefully, but what the hey, it works for what I use it for) and one of
> them transforms mathematical ASTs into numerical functions that do
> certain sophisticated checks (and have certain sophisticated
> optimizations) as part of the implementation of a symbolic-computation
> DSL (itself part of a larger project).
No ordinary person has yet "significantly mastered" Common Lisp in two
weeks. Maybe a genius and expert could, but I'm sure that noone who
doesn't post to usenet under a real (and well-known) name can. I think you
do not know what you're talking about. If you do not show us those macros,
and if they should not be beautifully written, I will not believe you.
>>>> 3. Bite the bullet and learn emacs.
>>> Ugly and unnecessary since there are other, more modern development
>>> environments for at least some Lisps.
>> What does it mean for software to be modern? Software is either
>> maintained or not. Emacs is maintained.
>
> A century-old building might still be maintained and inhabited, but it is
> not modern. You wouldn't need to be an architect to look at it and notice
> that it is, say, a brownstone with Gothic gabling, arches, and gargoyles,
> and not a glass tower reaching halfway to the sky. Nor to notice its lack
> of a decent elevator, vs. the glass tower's whole bank of the things.
What concerns me, I prefer living in Buckingham palace to living in the
Sears tower. But, as they say, YMMV.
Nicolas
Nicolas Neuss wrote:
> Tetrahedral Quartz <········@gmail.com> writes:
>
>> vippstar wrote:
>>> On Jul 20, 10:52 pm, Tetrahedral Quartz <········@gmail.com> wrote:
>>>> ccc31807 wrote:
>>>>> Several years ago when I started Lisp, I hit a brick wall. I made no
>>>>> headway whatsoever. Since then, I have progressed to the point where I
>>>>> am now writing Lisp scripts to do useful things. I'm no expert, but at
>>>>> least I can write and read Lisp on a basic level.
>>>> Funny, it took me less than two weeks to go from zero to significant
>>>> mastery (including a couple of sophisticated macros).
>>> May we see them?
>> Sorry, don't have them handy right now. symbol substitutions in the body
>> code (think of something sort of like with-slots, only implemented
>> without benefit of symbol-macrolet -- won't handle name collisions
>> gracefully, but what the hey, it works for what I use it for) and one of
>> them transforms mathematical ASTs into numerical functions that do
>> certain sophisticated checks (and have certain sophisticated
>> optimizations) as part of the implementation of a symbolic-computation
>> DSL (itself part of a larger project).
>
> No ordinary person has yet "significantly mastered" Common Lisp in two
> weeks.
I guess I'm not ordinary then. (I do have more than two decades'
experience in IT, including with C, C++, Java, and other languages.)
> Maybe a genius and expert could, but I'm sure that noone who
> doesn't post to usenet under a real (and well-known) name can.
Apparently you'd be wrong about that.
>>>>> 3. Bite the bullet and learn emacs.
>>>> Ugly and unnecessary since there are other, more modern development
>>>> environments for at least some Lisps.
>>> What does it mean for software to be modern? Software is either
>>> maintained or not. Emacs is maintained.
>> A century-old building might still be maintained and inhabited, but it is
>> not modern. You wouldn't need to be an architect to look at it and notice
>> that it is, say, a brownstone with Gothic gabling, arches, and gargoyles,
>> and not a glass tower reaching halfway to the sky. Nor to notice its lack
>> of a decent elevator, vs. the glass tower's whole bank of the things.
>
> What concerns me, I prefer living in Buckingham palace to living in the
> Sears tower. But, as they say, YMMV.
Why would you want that big drafty old place? It's structurally unsound,
constantly in need of renovations, and one look at the wiring will make
any self-respecting electrician go as white as a sheet. Plus the
toilet's always backing up.
On 21 jul, 15:41, Tetrahedral Quartz <········@gmail.com> wrote:
> Nicolas Neuss wrote:
> > No ordinary person has yet "significantly mastered" Common Lisp in two
> > weeks.
>
> I guess I'm not ordinary then. (I do have more than two decades'
> experience in IT, including with C, C++, Java, and other languages.)
>
> > Maybe a genius and expert could, but I'm sure that noone who
> > doesn't post to usenet under a real (and well-known) name can.
>
> Apparently you'd be wrong about that.
Many people say that they know how to program in Lisp, but they don't.
Doing a couple of simple macros does not prove otherwise. I'm sorry,
but we can't just take your word on that.
On Jul 21, 5:03 pm, gugamilare <··········@gmail.com> wrote:
> On 21 jul, 15:41, Tetrahedral Quartz <········@gmail.com> wrote:
>
> > Nicolas Neuss wrote:
> > > No ordinary person has yet "significantly mastered" Common Lisp in two
> > > weeks.
>
> > I guess I'm not ordinary then. (I do have more than two decades'
> > experience in IT, including with C, C++, Java, and other languages.)
>
> > > Maybe a genius and expert could, but I'm sure that noone who
> > > doesn't post to usenet under a real (and well-known) name can.
>
> > Apparently you'd be wrong about that.
>
> Many people say that they know how to program in Lisp, but they don't.
> Doing a couple of simple macros does not prove otherwise. I'm sorry,
> but we can't just take your word on that.
FFS.
I honestly don't get the entire 'lisp is super hard' thing. I don't
know who started the meme but it is FUD.
I write CL code every day and I use macros and use functional
programming and have to make my code both reliable and fast and I
don't really have a problem doing it.
Throw me into a situation where I am writing C code or Java or C++ and
it turns into profoundly frustrating situation, because I'm used to
writing lisp (and having the power associated with it).
Programming is a craft, and as with any craft, the more you do it, the
better you get, as such saying that there is a certain level where you
'really know how to program in lisp' is crazy. There are quite
obviously going to be different levels of skill associated with
different levels of experience and ability.
However, this too is an empty statement, as it is true of anything
that you can do. (The trombone, fishing, writing C code).
Quit trying to make lisp sound like some sort of weird Jedi mind trick.
Tetrahedral Quartz <········@gmail.com> writes:
>> Maybe a genius and expert could, but I'm sure that noone who
>> doesn't post to usenet under a real (and well-known) name can.
>
> Apparently you'd be wrong about that.
Apparently not, since you didn't post your macros.
Nicolas
On 2009-07-21 04:24:32 +0100, Tetrahedral Quartz <········@gmail.com> said:
> A century-old building might still be maintained and inhabited, but it
> is not modern. You wouldn't need to be an architect to look at it and
> notice that it is, say, a brownstone with Gothic gabling, arches, and
> gargoyles, and not a glass tower reaching halfway to the sky. Nor to
> notice its lack of a decent elevator, vs. the glass tower's whole bank
> of the things.
Except it turns out that the old building contains wormholes in
spacetime which connect all the rooms.
Tim Bradshaw wrote:
> On 2009-07-21 04:24:32 +0100, Tetrahedral Quartz <········@gmail.com> said:
>
>> A century-old building might still be maintained and inhabited, but it
>> is not modern. You wouldn't need to be an architect to look at it and
>> notice that it is, say, a brownstone with Gothic gabling, arches, and
>> gargoyles, and not a glass tower reaching halfway to the sky. Nor to
>> notice its lack of a decent elevator, vs. the glass tower's whole bank
>> of the things.
>
> Except it turns out that the old building contains wormholes in
> spacetime which connect all the rooms.
That's a bug, not a feature. That gets you an ungodly mess and clutter
with no clean separation between different places with different
purpose. Not to mention, you'll get a headache just standing there and
looking around, let alone actually trying to do some kind of useful work.
On 2009-07-21 19:43:02 +0100, Tetrahedral Quartz <········@gmail.com> said:
> That's a bug, not a feature. That gets you an ungodly mess and clutter
> with no clean separation between different places with different
> purpose. Not to mention, you'll get a headache just standing there and
> looking around, let alone actually trying to do some kind of useful
> work.
Trust me, it's a feature. I use "modern" environments (mostly Eclipse)
more than Emacs nowadays, but if I really need to get work done I use
Emacs.
On Jul 21, 12:39 pm, Tim Bradshaw <····@cley.com> wrote:
> On 2009-07-21 19:43:02 +0100, Tetrahedral Quartz <········@gmail.com> said:
>
> > That's a bug, not a feature. That gets you an ungodly mess and clutter
> > with no clean separation between different places with different
> > purpose. Not to mention, you'll get a headache just standing there and
> > looking around, let alone actually trying to do some kind of useful
> > work.
>
> Trust me, it's a feature. I use "modern" environments (mostly Eclipse)
> more than Emacs nowadays, but if I really need to get work done I use
> Emacs.
Why do you use Eclipse, if you are allegedly more productive in Emacs?
On 2009-07-21 20:48:28 +0100, fft1976 <·······@gmail.com> said:
> Why do you use Eclipse, if you are allegedly more productive in Emacs?
Why do I wear a tie to work?
Tim Bradshaw wrote:
> On 2009-07-21 20:48:28 +0100, fft1976 <·······@gmail.com> said:
>
>> Why do you use Eclipse, if you are allegedly more productive in Emacs?
>
> Why do I wear a tie to work?
>
If you had gone to bartender's school when I told you to you wouldn't
have these problems.
Case in point: http://thelaughingstockatpngs.com
kt
On 2009-07-21 21:19:10 +0100, Kenneth Tilton <·········@gmail.com> said:
> If you had gone to bartender's school when I told you to you wouldn't
> have these problems.
It's true. Or put more effort into the second job as Evil Mastermind.
Tim Bradshaw <···@cley.com> wrote:
+---------------
| Kenneth Tilton <·········@gmail.com> said:
| > If you had gone to bartender's school when I told you to you wouldn't
| > have these problems.
|
| It's true. Or put more effort into the second job as Evil Mastermind.
+---------------
But the fuel for the black helicopters is ex*PEN*sive!!
Evil Mastermind executive bonuses aren't nearly what
they used to be...
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
On Jul 21, 1:52 pm, Tim Bradshaw <····@cley.com> wrote:
> Except it turns out that the old building contains wormholes in
> spacetime which connect all the rooms.
That's honestly one of the best lisp analogies yet.
Tetrahedral Quartz <········@gmail.com> writes:
>> 3. Bite the bullet and learn emacs.
>
> Ugly and unnecessary since there are other, more modern development
> environments for at least some Lisps.
I think learning Emacs was listed because it's a great thing to do, not
because you can't code in Lisp without it.
Paul Donnelly wrote:
> Tetrahedral Quartz <········@gmail.com> writes:
>
>>> 3. Bite the bullet and learn emacs.
>> Ugly and unnecessary since there are other, more modern development
>> environments for at least some Lisps.
>
> I think learning Emacs was listed because it's a great thing to do ...
It is?
Could've fooled me. :)
Tetrahedral Quartz <········@gmail.com> writes:
> Paul Donnelly wrote:
>> Tetrahedral Quartz <········@gmail.com> writes:
>>
>>>> 3. Bite the bullet and learn emacs.
>>> Ugly and unnecessary since there are other, more modern development
>>> environments for at least some Lisps.
>>
>> I think learning Emacs was listed because it's a great thing to do ...
>
> It is?
>
> Could've fooled me. :)
Evidently it did. ;)
Paul Donnelly wrote:
> Tetrahedral Quartz <········@gmail.com> writes:
>
>> Paul Donnelly wrote:
>>> Tetrahedral Quartz <········@gmail.com> writes:
>>>
>>>>> 3. Bite the bullet and learn emacs.
>>>> Ugly and unnecessary since there are other, more modern development
>>>> environments for at least some Lisps.
>>> I think learning Emacs was listed because it's a great thing to do ...
>> It is?
>>
>> Could've fooled me. :)
>
> Evidently it did. ;)
I disagree. ;)
ccc31807 <········@gmail.com> writes:
> On Jul 20, 2:40�am, Bryan <············@gmail.com> wrote:
>
> 1. You can purchase Lisp books inexpensively or acquire them for free.
> Start one and study it until you hit a dead end. Then study another
> one. Cycle through several, then start over. This practice has helped
> me with the languages that I use on a daily basis, and has helped me
> with Lisp. Here are the ones that have proven helpful to me:
>
> [snip]
>
> Here are three others that aren't for beginners:
> Graham, Common Lisp
I personally found Paul Graham's "ANSI Common Lisp" very useful as a
beginner. I would also recommend learning Scheme: as an arguably
"purer" Lisp it lacks some of the features I found most confusing when
I was getting started.
> 2. Use the language. This is the ONLY way you will learn it. If you
> don't use it, you won't learn it.
Absolutely true.
Regards,
Peter
--
Peter Brett <·····@peter-b.co.uk>
Remote Sensing Research Group
Surrey Space Centre
Bryan <············@gmail.com> writes:
>
> The way I go to learn a new language is to do something fairly basic,
> like text processing on a file or processing the output from a basic
> Unix utility, like using the output from a few 'ps -eo
> pid,pcpu,vsz,args' commands to look for memory leaks.
That can be a great way to learn the text-processing capabilities of a
language, for certain.
> I'm guessing these are not the standard solution domain for LISP,
> because I couldn't believe how difficult it was to just to find out
> how to read a file in LISP.
Well, I think it's more that that a lot of Lisp tutorials come at it
from the mathematical end of things, and expect that the reader has a
professor who can fill in the gaps between the tutorial and reality.
That is, they get very excited about this nifty way to represent
computation and don't bother to show you how to actually compute with
it...
> Then I found "On Lisp" and "Practical Common LISP", and they made more
> sense to me, and told me about the "with-open-file" macro among other
> things, but I guess I still don't "Get" functional programming. Can
> anyone suggest any book or web resource that can, maybe, help me wrap
> my head around it?
PCL is hands-down the best Lisp reference out there. It's the first to
approach Common Lisp like any other programming language and to show how
Lisp's differentiators make it a better choice than other languages in
many situations.
As for functional programming, Common Lisp really isn't functional,
although you can write functional code in it. You can also write
imperative code, procedural code and object-oriented code. If you
wanted to, you could write libraries for aspect-oriented programming or
design-by-contract or whatever.
Here's an example of how I would write a program in Common Lisp to parse
that ps command you gave.
First off, I have this DEFMACRO in my ~/.sbclrc, because it makes
reading input from programs easier:
(defmacro with-input-from-program ((stream program program-args environment)
&body body)
"Creates an new process of the specified by PROGRAM using
PROGRAM-ARGS as a list of the arguments to the program. Binds the
stream variable to an input stream from which the output of the
process can be read and executes body as an implicit progn.
From <http://cyrusharmon.com/blog/display?id=97>."
(let ((process (gensym)))
`(let ((,process (sb-ext::run-program ,program
,program-args
:output :stream
:environment ,environment
:wait nil)))
(when ,process
(unwind-protect
(let ((,stream (sb-ext:process-output ,process)))
,@body)
(sb-ext:process-wait ,process)
(sb-ext:process-close ,process))))))
Anyway, first I just read it:
cl-user> (with-input-from-program (*standard-input*
"/bin/ps"
'("-eo" "pid,pcpu,vsz,args")
nil)
(loop for line = (read-line *standard-input*)
collect line))
You can see here that I'm giving the full path to /bin/ps and that the
arguments are passed as a list of strings. Then I loop collecting each
line.
When I run this, READ-LINE throws an error when it gets to the
end-of-line. So I take a look at the HyperSpec entry for READ-LINE
(there's a copy at
<http://www.ai.mit.edu/projects/iiip/doc/CommonLISP/HyperSpec/Body/fun_read-line.html>,
but I use hyperspec.el to browse it from emacs with M-x
hyperspec-lookup) and see this:
read-line &optional input-stream eof-error-p eof-value recursive-p
Ah-ha: READ-LINE can throw an error on EOF. But I can just set that to
false (which is nil in Lisp) and then there will be no error; it'll just
return nil for EOF. So next I try:
cl-user> (with-input-from-program (*standard-input*
"/bin/ps"
'("-eo" "pid,pcpu,vsz,args")
nil)
(loop for line = (read-line *standard-input* nil)
collect line))
Hmmm, that runs forever--I have to kill it. Why would that be? Oh
yeah, because there's no termination clause for LOOP: I collect each
line of output from ps, it runs out (so READ-LINE returns nil) and then
I keep on collecting nil forever. So I need to terminate if there's a
nil:
cl-user> (with-input-from-program (*standard-input*
"/bin/ps"
'("-eo" "pid,pcpu,vsz,args")
nil)
(loop for line = (read-line *standard-input* nil)
while line
collect line))
And now I get a nice long list of process lines like this:
(...
"16784 0.0 46856 nm-applet --sm-disable"
"16786 0.0 7564 /usr/libexec/gvfs-gdu-volume-monitor"
"16793 0.0 19052 kerneloops-applet"
"16795 0.0 37228 /usr/libexec/notification-daemon"
"16797 0.0 10036 /usr/libexec/pulse/gconf-helper"
"16798 0.0 19868 bluetooth-applet"
...)
That's pretty cool, but they're just text. Wouldn't it be nice if the
pids were actual integers, the CPU percentages were floats, the virtual
memory sizes were integers too and the command arguments were lists of
strings? Well, I'll write a function that takes a string like "16784
0.0 46856 nm-applet --sm-disable" and parses it. In order to do this,
I'll use the SPLIT-SEQUENCE library to split the string on spaces (don't
worry about the 40; it's the second return value of SPLIT-SEQUENCE, and
not something we care about here):
cl-user> (require :split-sequence)
nil
cl-user> (split-sequence:split-sequence
#\Space
"16784 0.0 46856 nm-applet --sm-disable")
("16784" "" "0.0" "" "46856" "nm-applet" "--sm-disable")
40
Brief note: SPLIT-SEQUENCE is both a package and a symbol within that
package, so SPLIT-SEQUENCE:SPLIT-SEQUENCE means 'the symbol
SPLIT-SEQUENCE in the package SPLIT-SEQUENCE.'
Hmmm, what's that empty string doing between the process ID and the CPU
percentage, and another between the percentage and the ? Oh, it's
because there are multiple spaces in a row. Let's just remove them:
cl-user> (split-sequence:split-sequence
#\Space
"16784 0.0 46856 nm-applet --sm-disable" :remove-empty-subseqs t)
("16784" "0.0" "46856" "nm-applet" "--sm-disable")
40
The result of SPLIT-SEQUENCE is almost exactly what we want, except for
converting some strings to numbers. For integers like the process IDs
we could use PARSE-INTEGER, but the easiest way to turn the CPU
percentage into a float is to use READ-FROM-STRING, which also works for
integers:
cl-user> (destructuring-bind
(pid cpu vm-size command &rest args)
(split-sequence:split-sequence
#\Space
"16784 0.0 46856 nm-applet --sm-disable" :remove-empty-subseqs t)
(list (read-from-string pid)
(read-from-string cpu)
(read-from-string vm-size)
command
args))
(16784 0.0 46856 "nm-applet" ("--sm-disable"))
This does exactly what I want. Now, to combine it with the LOOP above I
could either define a function or just do it by hand. Since it's likely
that this is a one-off, it probably makes sense just to do it by hand:
cl-user> (with-input-from-program (*standard-input*
"/bin/ps"
'("-eo" "pid,pcpu,vsz,args")
nil)
(loop for line = (read-line *standard-input* nil)
while line
collect (destructuring-bind
(pid cpu vm-size command &rest args)
(split-sequence:split-sequence
#\Space
line
:remove-empty-subseqs t)
(list (read-from-string pid)
(read-from-string cpu)
(read-from-string vm-size)
command
args))))
Which generates output like:
((pid %cpu vsz "COMMAND" nil)
(1 0.0 2012 "/sbin/init" nil)
(2 0.0 0 "[kthreadd]" nil)
(3 0.0 0 "[migration/0]" nil)
(4 0.0 0 "[ksoftirqd/0]" nil)
(5 0.0 0 "[watchdog/0]" nil)
...)
You'll notice that the header line from ps gets decomposed into symbols
and a string; that's ugly so you might want to call REST on the results:
cl-user> (rest (with-input-from-program (*standard-input*
"/bin/ps"
'("-eo" "pid,pcpu,vsz,args")
nil)
(loop for line = (read-line *standard-input* nil)
while line
collect (destructuring-bind
(pid cpu vm-size command &rest args)
(split-sequence:split-sequence
#\Space
line
:remove-empty-subseqs t)
(list (read-from-string pid)
(read-from-string cpu)
(read-from-string vm-size)
command
args)))))
And from here you could do things like sort based on, say, the virtual
memory size:
cl-user> (defvar *processes*
(rest (with-input-from-program (*standard-input*
"/bin/ps"
'("-eo" "pid,pcpu,vsz,args")
nil)
(loop for line = (read-line *standard-input* nil)
while line
collect (destructuring-bind
(pid cpu vm-size command &rest args)
(split-sequence:split-sequence
#\Space
line
:remove-empty-subseqs t)
(list (read-from-string pid)
(read-from-string cpu)
(read-from-string vm-size)
command
args))))))
cl-user> (sort (copy-list *processes*) #'< :key #'third)
((2 0.0 0 "[kthreadd]" nil)
(3 0.0 0 "[migration/0]" nil)
...
(4597 0.0 1260344
"/usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0/jre/lib/i386/../../bin/java"
("sun.applet.PluginMain")))
The sky is, of course, the limit.
--
Robert A. Uhl
Libertarianism is, essentially, the idea that: a Protestant and a Catholic;
a white man and a black man; a believer and an atheist can live together.
Liberal cosmopolitanism is the idea that some subset of these should go away.
Bryan <············@gmail.com> writes:
> OK, I've read several web pages and PDFs on LISP. I think I get the
> basics of how to write functions and macros, but just the basics.
> That said, what I don't "GET" is how to write a lisp program.
>
> The way I go to learn a new language is to do something fairly basic,
> like text processing on a file or processing the output from a basic
> Unix utility, like using the output from a few 'ps -eo
> pid,pcpu,vsz,args' commands to look for memory leaks.
> I'm guessing
> these are not the standard solution domain for LISP, because I
> couldn't believe how difficult it was to just to find out how to read
> a file in LISP. The first two books I looked through, "Common LISP,
> an Interactive Approach" and "Common LISP: A Gentle Introduction",
> didn't even touch on the subject of reading a file. Then I found "On
> Lisp" and "Practical Common LISP", and they made more sense to me, and
> told me about the "with-open-file" macro among other things, but I
> guess I still don't "Get" functional programming.
This is a pedagogical problem. These book authors assume that their
readers are autonomous students who already know something about
computers, but foremost, about using a library, books, references and
indices. They don't spend time talking about file processing (and
other such mundane subjects) because these are not what discriminate
Lisp from the other programming language: you can do file I/O with any
programming language, so you are expected to know already this kind of
things. And you are expected to know how to find the details using
the indices of the reference
http://www.lispworks.com/documentation/HyperSpec/Front/Contents.htm
These university courses mostly deal with what is specific to Lisp,
list processing, recursion, functional paradigm, meta-linguistic
abstraction, etc.
But as you have noted "Practical Common Lisp" begin written not by a
university professor, and targeting people more like you do indeed
mention file I/O and other practical subjects.
> Can anyone suggest
> any book or web resource that can, maybe, help me wrap my head around
> it?
You also have to realize that there are several layers. We may speak
of Common Lisp, the language, as defined in the standard. This core
lacks some important features that are provided by the specific
implementations (and unfortunately in general in implementation
specific ways). Application delivery is one of these implementation
specific features. There are often libraries to provide a common API
over these implementation specific features, in the case of
application delivery, there's cl-launch (I never tried it myself).
To write little unix tools, I use clisp which, like most other lisp
implementation, and most other language implementations let you write
unix scripts by starting the file with #!/usr/bin/clisp
See also the implementation specific documentation, in the case of
clisp: http://clisp.cons.org/impnotes/quickstart.html for details
about how to produce a binary executable for programs more complex
than a simple script.
Similar documentation and features exist for the other lisp
implementations.
Here is a quick example of a clisp script:
[···@simias :0.0 ~]$ cat bin/upcase
#!/usr/bin/clisp -norc -ansi -Kfull
;; -*- mode:lisp -*-
(loop
:for line = (read-line *standard-input* nil nil)
:while line
:do (write-line (string-upcase line)))
[···@simias :0.0 ~]$ ls -l /tmp | bin/upcase
TOTAL 360
DRWXRWXRWT 15 ROOT ROOT 16384 2009-07-20 11:37 ./
DRWXR-XR-X 24 ROOT ROOT 4096 2009-07-03 23:37 ../
DRWXRWXRWT 2 ROOT ROOT 4096 2009-07-09 16:47 .ICE-UNIX/
-R--R--R-- 1 ROOT ROOT 11 2009-07-09 16:47 .X0-LOCK
DRWXRWXRWT 2 ROOT ROOT 4096 2009-07-09 16:47 .X11-UNIX/
SRWXRWXRWX 1 POSTGRES POSTGRES 0 2009-07-20 10:53 .S.PGSQL.5432=
-RW------- 1 POSTGRES POSTGRES 30 2009-07-20 10:53 .S.PGSQL.5432.LOCK
-RW-RW-R-- 1 PJB PJB 861 2009-07-20 10:57 2-24231.NASATV
DRWX------ 2 PJB PJB 4096 2009-07-15 15:10 ACROREAD_1031_1031/
DRWX------ 2 ROOT ROOT 4096 2009-07-13 03:12 EMACS0/
DRWX------ 2 PJB PJB 4096 2009-07-15 17:47 EMACS1031/
DRWX------ 2 PJB PJB 4096 2009-07-20 10:58 GCONFD-PJB/
DRWX------ 2 PJB PJB 4096 2009-07-20 10:58 ORBIT-PJB/
DRWX------ 2 PJB PJB 4096 2009-07-16 12:23 PLUGTMP/
--
__Pascal Bourguignon__
Lisp is tough to get into, I had to get used to slime, Emacs and a
whole new way of doing things - but it was worth it.
I found myself using 2 books - firstly the Lisp Hyperspec, as other
mentioned, but also http://www.psg.com/~dlamkins/sl/ or Successful
Lisp: How to Understand and Use Common Lisp. It's grouped in chapters
on various subjects, so I found myself skimming say, the chapter on
iteration, then jumping to the hyperspec to get the full details.
Good luck, and don't mind the trolls that this place seems to collect.
- Chris
maximinus wrote:
> Lisp is tough to get into, I had to get used to slime, Emacs and a
> whole new way of doing things - but it was worth it.
Try Clojure. There's a NetBeans plugin for it, so with Clojure you can
use a modern IDE if you don't want to deal with things like emacs.
Clojure isn't Common Lisp but it is a Lisp. More at http://clojure.org.
> I found myself using 2 books - firstly the Lisp Hyperspec, as other
> mentioned, but also http://www.psg.com/~dlamkins/sl/ or Successful
> Lisp: How to Understand and Use Common Lisp. It's grouped in chapters
> on various subjects, so I found myself skimming say, the chapter on
> iteration, then jumping to the hyperspec to get the full details.
Practical Common Lisp would be useful too. There's a copy on the web
somewhere with no paywall in front of it.
> Good luck, and don't mind the trolls that this place seems to collect.
To some posters here, "trolls" means anyone pushing some dialect of Lisp
that isn't CL, particularly if it is Clojure.
Me, I'd classify as trolls only the wackos that start crossposted fights
like HASKELL VS. LISP VS. PROLOG or that blather on about prime numbers
or some such topic (there's some nut in comp.programming flooding it
with numerical nonsense; and everyone here is surely familiar with Xah
Lee). I'm not sure who to consider the worst. The guy that crossposted
HASKELL VS. LISP VS. PROLOG here got lots of replies, on the other hand
"l�rs" cross-posted what look to be some pretty nasty personal attacks
aimed at someone or other, but got basically zero attention for doing
so. Is the troll worse who uses more unpleasant tactics, or who uses
more effective ones? You decide.
On Jul 20, 8:18 am, Tetrahedral Quartz <········@gmail.com> wrote:
> maximinus wrote:
> Try Clojure. There's a NetBeans plugin for it, so with Clojure you can
> use a modern IDE if you don't want to deal with things like emacs.
Isn't there a NetBeans thing for Common Lisp?
If so, any SLIME users converted to it?
fortunatus wrote:
> On Jul 20, 8:18 am, Tetrahedral Quartz <········@gmail.com> wrote:
>
>> maximinus wrote:
>
>> Try Clojure. There's a NetBeans plugin for it, so with Clojure you can
>> use a modern IDE if you don't want to deal with things like emacs.
>
> Isn't there a NetBeans thing for Common Lisp?
I don't know.
On Jul 20, 1:40 am, Bryan <············@gmail.com> wrote:
Wow! I'd like to thank everyone for the help and information. I will
try to get to all of the websites and documents mentioned as soon as
possible. The only one I have really looked at so far today is the
Common Lisp HyperSpec, and I am suffering from information overload
from that.
Also I would like to thank you for the code and style examples. They
look different than the other Lisp examples I've seen because they use
the Loop Facility. Just looking that up in the HyperSpec had me cross
eyed after a few minutes. Lots to learn.
I now need to digest all of this information and then move forward
with some coding. Once again, thanks.
Bryan