As an experienced programmer, I've heard a lot about how good Lisp is,
and I like getting to grips with new languages. After conversations
with friend who's keen I decided I should learn Common Lisp.
I thought I'd share some of my experiences here. While much of what
I'm going to say is critical, I'd like to emphasize that I'm not
giving up on Lisp. I like what I've seen so far, and the hurdles are
more entrance barriers than they are problems for serious work - but
they are quite time-consuming, and nowadays we are all in a hurry.
So without futher ado, let me summarise my key point:
* Documentation for introducing Lisp to existing programmers is poor;
existing tutorials are old or at least outdated.
A comprehensive resource aimed at contemporary non-Lisp programmers
is urgently needed. I was going to started an article on the CLiki
with some pointers and discussion, but as I've written this article
I've realised that the answers I have found are not really usefully
transferrable to other people new to Lisp unless they have
circumstances very like my own.
Secondarily:
* Infrastructure for performing tasks which are routine in
modern programming is often lacking and/or hard to find.
* Support for Common Lisp development in Debian stable is
surprisingly poor, given how mature the Lisp world is.
Below I'll try to justify these assertions, but first here's a list of
questions that current `Lisp tutorials' fail to address. I think that
the world needs someone who knows more about this than I do to write a
single opinionated introduction that answers at least these questions:
Q. If I am using a modern Unix system, which Common Lisp
implementation should I choose ? Do I need to be using a
particular operating system to get a good CL development
environment ? What if I prefer a different OS (or have
a different version) ?
Q. Which development tools should I be using ? Summary of the
key features of SLIME. What if I'm a vi (vim) user ?
Q. Quick introduction to installing the relevant development tools
and libraries (eg, list of Debian packages to install). If this
turns into a list of instructions of the form `compile this',
`edit the system definition' etc., then the answer is wrong.
Q. Which tutorial on the Common Lisp language itself, and which
reference, should I be using ? Answer: one tutorial book or
webpage (I don't know what would be good to recommend) and one
reference (the Hyperspec, obviously). Provide only one answer to
each, not any lists; the web is full of lists of Lisp
information.
Q. Which libraries should I definitely be looking at using, and what
are they generally good for ?
Q. How do I turn my program into an executable ? NB that most Lisp
FAQs seem to answer this question with either a blank space (!)
or with some waffle. The answer seems to be: "Sorry, this is not
properly supported by anything yet; you must write a wrapper
script. Here is an example."
Q. How do I package my program in such a way that non-Lisp people
will not be freaked out by the installation instructions ?
I stress that *I don't need the answers to these questions any more*
because I have struggled through without (and will be able to solve
the remaining problems myself if need be, I'm sure).
I promised some justification for my assertions. This is probably
best done in a narrative style, which will demonstrate the
difficulties I faced and how I overcame them. This will naturally
make the result rather disjointed in terms of the relationship to my
suggestions above.
When I first settled on learning CL I thought I would read a standard
reference work. This is my usual way of approaching new programming
languages - I'm one of the minority of people who find they get on very
well with reference manuals, and find tutorials distressingly vague
about details.
A Lisp-using friend lent me their copy of CLtL2, and I started reading
through that. I quickly gave up because of Guy Steele's absurd habit
of writing `and the thingum does the wossname to the doobry - no wait,
it doesn't, in 1987 X3J13 voted that in fact the thingum does
something completely different'. This is all very well once or twice
but constantly reading, understanding and internalising complex
descriptions, only to be told in the next paragraph that it's all
false and I had to forget it all again, was too much like hard work.
(There are some typographical indications but they are too weak to
interrupt the flow of concentrated reading and in any case the text
only does original-version-and-diff rather than an integrated
description.)
My next approach was to try to read the Hyperspec through. Well, I'm
still doing that - but the Hyperspec is poorly structured for this.
The number of forward references is much higher than for most other
language specifications. It's possible that a different reading order
for the Hyperspec would improve this but I suppose since most people
prefer to learn languages from tutorials I'm probably out of luck.
It was evident that attempting to find a spec to just read wasn't
going to be very fruitful. Since I've used Lisp variants before on
occasion, I decided it would be better to pick some project and
just write a program.
Quickly, I encountered a suitable project: a non hideously broken
ip-over-http implementation. Given the way it has to fit into my
existing arrangements, this requires a single-process webserver
extensible to implement additional functionality. Ie, similar to CGI
programs, but my additional code has to run in the same process
because all the URL serving needs to share state, file descriptors,
etc. Some quick research showed that the standard approaches to
webservers in most scripting languages weren't ideal (Python might
have worked but I have lately got very annoyed with Python), and I
didn't want to have to patch one of the written-in-C webservers. My
searches led me to AllegroServe, of which a portable implementation is
available in Debian. A browse of the documentation in the cl-aserve
package suggested that it could do what I wanted so I decided to
write my application in Common Lisp.
So, now I wanted to actually write some programs in Lisp, a
precondition was getting as far as being able to run `hello world' and
test my basic understanding of use of the extension packages. I also
wanted a reasonable development environment, and my Lisp advocate
friend had mentioned the Emacs mode SLIME, so I knew I would want
that.
First I thought I'd try starting my favourite lisp and playing with
the REPL like many of the online tutorials suggest. This was all very
well but it all seemed very primitive. Several of the lisps I ended
up trying didn't have command line editing by default in Debian
stable. Absurd !
Also, there were evidently many useful CL packages in Debian, some of
which I wanted to use, but it seemed difficult to get documentation
for them. For example, I installed cl-md5, and I could say (require
'md5) and have it work, but what to do next ? I wrote a one-liner to
list the symbols in the package and then extracted their docstrings
but it was a total pain. Surely, I thought, people can't really go
about things this way in this day and age ? (I wouldn't even have
thought of this approach if I wasn't so familiar with Emacs's builtin
documentation system.)
There was also this nagging question: which lisp did I want to use ?
Debian stable comes with cmucl, sbcl, clisp and gcl. Etch (Debian
testing) has ecl too; non-free has an installer for some acl variant.
But this turned out to be less of a problem because bu then I knew
that I needed one which 1. worked with SLIME and 2. worked with
cl-aserve, and I wanted it on Debian stable.
So I decided I needed to try out SLIME. Note that SLIME isn't in
Debian stable. Being an experienced Debian developer made solving
this situation straightforward for me (if slightly tedious) but for
many people it would have been hard or even impossible. (I have no
idea what the situation is like on other Linux distributions, let
alone on non-GNU systems.)
I tried out various lisps at random, applying a shotgun debugging
approach; I compiled (and recompiled) packages to try to generate
appropriate backports. I ended up deciding that sbcl would be a good
answer (I can't remember why). One particularly silly situation was
that the sbcl in Debian stable was too old for unstable's slime and
the sbcl in Debian unstable had a build-dependency only satisfiable by
the sbcl in unstable ! I was able to solve this by bootstrapping with
an sbcl binary package from backports.org.
With this technique, and one source code change to deal with a renamed
symbol (I had to change disable-process to process-disable in a few
files in cl-portable-aserve-1.2.42+cvs.2006.04.24-dfsg-1), I was able
to procure working and compatible versions of sbcl, cl-aserve and
slime. This allowed me to start actually programming - obviously
beginning by playing about with the pieces I knew I would need and
making them work for me.
SLIME is a fantastically useful tool - although of course I don't know
how people who go without it solve the same problems. In particular,
tab completion over symbol names and easy docstring and arglist lookup
seem indispensible.
But I still find myself amazed at obvious things that appear to be
missing from the CL standard and the libraries I was using:
I had to write a function to convert a string of bytes (as produced by
cl-md5) to hex. Newer (non-broken!) hash functions and so on don't
seem to be available at all. I couldn't find a library for
manipulating IP address ranges and masks, and when I tried to write
the code myself I found that there wasn't even a standard function for
splitting a string into substrings based on a delimiter ! There is a
cornucopia of functionality available for meddling with the innards of
lisp, but hardly any of the pieces used for solving the kinds of
problems encountered in the modern Internet.
I presume that other people have already written much of the necessary
code, but it is really hard to know where to look. Debian is
well-supplied with CL packages and the infrastructure for loading them
is good, but it's obviously only of limited use when choosing which
one I should use.
Finally, one problem that I still haven't tackled: Lisp systems all
seem to have the idea that the way to run lisp programs is to invoke
the lisp interpreter and type some runes into the REPL; they also
think that this is the way to compile them too.
For someone who has been working with Unix, the inability to turn a
small lisp program into a proper executable, quickly and easily, is
like returning to the stone age (or to Windows, heaven help us).
It is all very well for large projects to involve learning a lot of
`system definition' facilities and to expect complicated and
hard-to-install infrastructure on the computers involved. But often
it is important to be able to ship small programs, in a form the
recipient will be able to execute; it is also important to be able to
make Lisp programs look and work like any other executable on the
system.
Naturally some of these problems can be addressed with wrapper scripts
and a few extra tools. That's fine. But where is the standard
facility for wrapper scripts, that I can put in a #! line ? Where are
the standard facilities for building *portably-deployable* CL
programs: by which I mean not `portable to a different Lisp' but
`a whole distribution bundle which is portable to a computer which
does not yet have a Lisp system' ? How do I integrate Lisp
compilation into the build system of a large project using many
languages and tools, all driven by something like make ?
Obviously I could write my own answers but I want to concentrate on
writing my application, not impedance matching to an approach to
programming that feels like a 1960's timewarp. Wouldn't it be nice if
Lisp were dragged kicking and screaming into the mid-1990's ?
Thanks for your attention. This has been a public service rant. I
hope that the community here will take it the right way. Don't get me
wrong; I like CL as a language and hope to increase my use of it.
I'm posting here to try to document some of the things that make it
difficult for even an experienced programmer to get involved with
Common Lisp. If the entrance barriers could be lowered, I think you
might find it easier to encourage new and useful people to join the
Lisp community.
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
Not attempting to answer your questions, but as a fellow lisp
enthusiast I feel the same way you do. Recently I've been playing with
Cusp and Eclipse for lisp development with SBCL (I'm emacs-impaired).
http://www.paragent.com/lisp/cusp/cusp.htm Do check it out if you
haven't already. It comes closest to a good free IDE for lisp I think.
From: Robert Uhl
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m3odqjjasz.fsf@latakia.dyndns.org>
Ian Jackson <········@chiark.greenend.org.uk> writes:
>
> * Documentation for introducing Lisp to existing programmers is poor;
> existing tutorials are old or at least outdated.
Very true up until the publication of Practical Common Lisp. It's well
worth the modest price, and is also available free online.
> * Infrastructure for performing tasks which are routine in
> modern programming is often lacking and/or hard to find.
The old library problem. The answer from old-timers is 'write it
yourself,' and Lisp does make that more of an option than would be the
case in other languages--but it's still not a bloody great option.
> Q. If I am using a modern Unix system, which Common Lisp
> implementation should I choose ?
SBCL.
> Q. Which development tools should I be using ?
emacs+SLIME
> What if I'm a vi (vim) user ?
Come over to the light side of the force;-)
> Q. Which tutorial on the Common Lisp language itself, and which
> reference, should I be using ?
Practical Common Lisp and the HyperSpec (which links into SLIME nicely).
> Q. Which libraries should I definitely be looking at using, and what
> are they generally good for ?
Anything by Edi Weitz is excellent and suitable for its stated purpose.
> Q. How do I turn my program into an executable ?
SBCL does this now--see sb-ext:save-lisp-and-die.
> One particularly silly situation was that the sbcl in Debian stable
> was too old for unstable's slime and the sbcl in Debian unstable had a
> build-dependency only satisfiable by the sbcl in unstable !
ISTR that kind of thing used to happen a fair amount in Debian,
particularly in the Three Dark Years. Lisp not being as popular as
other languages, it's unsurprising (albeit annoying) that errors persist
longer than elsewhere.
> Finally, one problem that I still haven't tackled: Lisp systems all
> seem to have the idea that the way to run lisp programs is to invoke
> the lisp interpreter and type some runes into the REPL; they also
> think that this is the way to compile them too.
>
> For someone who has been working with Unix, the inability to turn a
> small lisp program into a proper executable, quickly and easily, is
> like returning to the stone age (or to Windows, heaven help us).
Well, in some ways it's like walking back into the stone age--but in
others it's like taking a rocket ship up into the space age. The
image-based approach of having all functions accessible everywhere is no
doubt more powerful, but unfortunately its advocates often seem to still
be stuck in the 1970s when it comes to user interface and such...
And I think more than a few fellows are still annoyed that the Lisp
Machines failed and rather like to pretend that Unix is just a
bootloader for Lisp.
--
Robert Uhl <http://public.xdi.org/=ruhl>
...and the harsh light of the server room shone round about them--which
the Pointy-Headed dare not abide--and they counted themselves safe.
--Ole Craig
From: Pascal Costanza
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <4tkoeoF14bs13U1@mid.individual.net>
Robert Uhl wrote:
> Ian Jackson <········@chiark.greenend.org.uk> writes:
>> * Documentation for introducing Lisp to existing programmers is poor;
>> existing tutorials are old or at least outdated.
>
> Very true up until the publication of Practical Common Lisp. It's well
> worth the modest price, and is also available free online.
>
>> * Infrastructure for performing tasks which are routine in
>> modern programming is often lacking and/or hard to find.
>
> The old library problem. The answer from old-timers is 'write it
> yourself,' and Lisp does make that more of an option than would be the
> case in other languages--but it's still not a bloody great option.
That's only part of the answer. The other part is that during the 90's,
Common Lisp was indeed almost dead. Since a few years, a new generation
of Lispers has been coming up and started to revive the language. The
interesting thing here, maybe even from a historical perspective, is
that although Lisp is nearly half a century old, it is nowadays more at
the level of an early adopters' technology, albeit with some very mature
technology behind the scenes. Nevertheless, the community is still quite
small, with all the advantages and disadvantages that this has...
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <··············@latakia.dyndns.org>,
Robert Uhl <·········@NOSPAMgmail.com> wrote:
>Ian Jackson <········@chiark.greenend.org.uk> writes:
>> * Documentation for introducing Lisp to existing programmers is poor;
>> existing tutorials are old or at least outdated.
>
>Very true up until the publication of Practical Common Lisp. It's well
>worth the modest price, and is also available free online.
Thanks for the recommendation but when I made my suggestion I was
thinking of something a lot shorter than a book. Suggesting that
someone who wants to try out a language for some small project should
read through a book is, erm, optimistic.
>> * Infrastructure for performing tasks which are routine in
>> modern programming is often lacking and/or hard to find.
>
>The old library problem. The answer from old-timers is 'write it
>yourself,' and Lisp does make that more of an option than would be the
>case in other languages--but it's still not a bloody great option.
Yes. If there were a coherent directory of libraries, it would be an
improvement. I'm not suggesting that CL should gain a cesspit like
CPAN. Something more like Python's standard library set would be
ideal, but of course it would have to not be part of any particular CL
distribution.
>> Q. [stuff]
>[answer]
These are excellent answers and the kind of thing I was hoping for.
Would you like me to transfer them to a page on the CLiki ?
>And I think more than a few fellows are still annoyed that the Lisp
>Machines failed and rather like to pretend that Unix is just a
>bootloader for Lisp.
Yes, I did definitely get that impression from my background reading.
Needless to say I don't think that's an approach that's going to make
Lisp many new friends :-).
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
From: Robert Uhl
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m3bqmghpcd.fsf@latakia.dyndns.org>
Ian Jackson <········@chiark.greenend.org.uk> writes:
>
>>> * Documentation for introducing Lisp to existing programmers is poor;
>>> existing tutorials are old or at least outdated.
>>
>>Very true up until the publication of Practical Common Lisp. It's well
>>worth the modest price, and is also available free online.
>
> Thanks for the recommendation but when I made my suggestion I was
> thinking of something a lot shorter than a book. Suggesting that
> someone who wants to try out a language for some small project should
> read through a book is, erm, optimistic.
Well, I managed to read it in a day or two--but I'm a quick reader.
Common Lisp is a _very_ different language from the usual ones (as I'm
sure you've realised); I'm not certain that an abbreviated guide is
particularly useful.
An advantage of PCL is that one can skip over the obvious parts
(e.g. the explanations of what lists are).
>>> * Infrastructure for performing tasks which are routine in
>>> modern programming is often lacking and/or hard to find.
>>
>>The old library problem. The answer from old-timers is 'write it
>>yourself,' and Lisp does make that more of an option than would be the
>>case in other languages--but it's still not a bloody great option.
>
> Yes. If there were a coherent directory of libraries, it would be an
> improvement.
Well, as I noted Dr. Edi Weitz's stuff is
excellent--<http://www.weitz.de/> has a nice long list. And of course
then there's CLiki and the Common Lisp Directory and a few others.
Have you played with CLSQL? It's really very cool. Webactions and
PortableAllegroServe are also quite good.
> Something more like Python's standard library set would be ideal, but
> of course it would have to not be part of any particular CL
> distribution.
I agree--Python's a very useful little language; it's my typical tool at
work simply because it has a nice standard library (one which improves
every release, even). I can get the job done in a reasonably nice
language, although I keep on thinking how much easier expressing the
algorithms would be using Lisp--but then I remember how much more
difficult everything else would be, since there's no Lisp Django and so
forth.
> These are excellent answers and the kind of thing I was hoping for.
> Would you like me to transfer them to a page on the CLiki ?
Feel free.
>>And I think more than a few fellows are still annoyed that the Lisp
>>Machines failed and rather like to pretend that Unix is just a
>>bootloader for Lisp.
>
> Yes, I did definitely get that impression from my background reading.
> Needless to say I don't think that's an approach that's going to make
> Lisp many new friends :-).
That's changing, of course. I don't know that any Lisp will ever be
suitable for shell scripting, but at least it's now quite possible to
create executables and so forth.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Thanks to the joint efforts of OpenOffice, Mozilla, and a few others, Emacs
officially entered the category of lightweight utilities. --kalifa on /.
Robert Uhl <·········@NOSPAMgmail.com> wrote:
+---------------
| I don't know that any Lisp will ever be suitable for shell scripting...
+---------------
Hunh?!? I use CMUCL for "shell scripting" all the time!!!
$ file ~/bin/* | grep -i cmucl | wc -l
41
$
And many other people use CLISP and other implementations for
similar things. [I even have a half-dozen CLISP scripts myself.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Robert Uhl
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m3lkld7vzx.fsf@latakia.dyndns.org>
····@rpw3.org (Rob Warnock) writes:
>
> Robert Uhl <·········@NOSPAMgmail.com> wrote:
> +---------------
> | I don't know that any Lisp will ever be suitable for shell scripting...
> +---------------
>
> Hunh?!? I use CMUCL for "shell scripting" all the time!!!
You don't find the start-up times a pain?
At least in SBCL, stuff like capturing stdin & stdout is more of a pain
than in a simple shell, perl or python script.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Sometimes, I think the French were put on earth for no other reason than
to give Germany an over-inflated sense of their military prowess. Other
times, I can't come up with any reason at all. --Burt Prelutsky
Robert Uhl <·········@NOSPAMgmail.com> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) writes:
| > Robert Uhl <·········@NOSPAMgmail.com> wrote:
| > +---------------
| > | I don't know that any Lisp will ever be suitable for shell scripting...
| > +---------------
| >
| > Hunh?!? I use CMUCL for "shell scripting" all the time!!!
|
| You don't find the start-up times a pain?
+---------------
Not at all. Remember, unlike SBCL, CMUCL still contains a full
interpreter which is quite fast at running simple code. Also, almost
all modern operating systems do a *very* good job of caching the
CMUCL executable & image files [which are mmap()'d COW at startup],
so that repeated execution is *fast*! -- in the range of 20 ms
(that's "milliseconds"!) on all the machines I usually run on.
Times for CLISP are similar.[1] They're even usable for low-volume
CGI scripting! ;-}
+---------------
| At least in SBCL, stuff like capturing stdin & stdout is more
| of a pain than in a simple shell, perl or python script.
+---------------
I don't understand. I use CMUCL scripts in pipes all the time, e.g.:
$ cat ./powers
#!/usr/local/bin/cmucl -script
(unless (= 1 (length *script-args*))
(format *error-output* "usage: ~a #powers~%" *script-name*)
(unix:unix-exit 1))
(let ((npowers (read-from-string (first *script-args*))))
(loop for line = (read-line nil nil nil)
while line do
(let ((n (read-from-string line)))
(format t "~s~{ ~s~}~%" n (loop for p from 2 to npowers
collect (expt n p))))))
$ for i in 2 3 5 10; do echo $i; done | ./powers 5
2 4 8 16 32
3 9 27 81 243
5 25 125 625 3125
10 100 1000 10000 100000
$ for i in 2 3 5 10; do echo $i; done | ./powers 5 | cut -d' ' -f3-
8 16 32
27 81 243
125 625 3125
1000 10000 100000
$
Almost exactly the same code [though with differences on the "#!" line
and in how you do an "exit 1"] should work on SBCL or CLISP or indeed
most CLs.
-Rob
[1] Actually, my measurements some time ago indicated that CMUCL's
startup is actually *slightly* faster than CLISP's [despite CMUCL's
greatly larger memory footprint]:
$ cat ./test3c.lisp
#!/usr/local/bin/clisp -q
(format t "hello world!~%")
$ time-hist ./test3c.lisp
Timing 100 runs of: ./test3c.lisp
4 0.019
26 0.020
70 0.021
$
versus:
$ cat ./test3a.lisp
#!/usr/local/bin/cmucl -script
(format t "hello world!~%")
$ time-hist ./test3a.lisp
Timing 100 runs of: ./test3a.lisp
66 0.016
34 0.017
$
[The "-script" switch for CMUCL is a local hack to "site-init.lisp"
that I've been intending to publish for several years. My bad.
Soon, soon...]
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Don Geddis
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <874ps1575f.fsf@geddis.org>
····@rpw3.org (Rob Warnock) wrote on Tue, 12 Dec 2006:
> [The "-script" switch for CMUCL is a local hack to "site-init.lisp"
> that I've been intending to publish for several years. My bad.
> Soon, soon...]
Now that looks awesome, and quite useful.
Besides just publishing it, could it be added to the main branch of the
CMUCL code?
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Sheep haiku:
sheepskin seatcovers / winter warm and summer cool / little lambs no more
Don Geddis <···@geddis.org> wrote:
+---------------
| ····@rpw3.org (Rob Warnock) wrote:
| > [The "-script" switch for CMUCL is a local hack to "site-init.lisp"
| > that I've been intending to publish for several years. My bad.
| > Soon, soon...]
|
| Now that looks awesome, and quite useful.
+---------------
Thanks. It also works if you just slap the "#!" line in front of a
FASL files. Oh... Did you know you can make a legal CMUCL FASL file
by simply concatenating several FASL files together? Yup. The CMUCL
FASL reader supports that. And so it works with the script hack, too:
$ head script_header.cmu foo[123].lisp
==> script_header.cmu <==
#!/usr/local/bin/cmucl -script
==> foo1.lisp <==
(defun foo1 () (format t "This is foo1.~%"))
==> foo2.lisp <==
(defun foo2 () (format t "This is foo2.~%"))
==> foo3.lisp <==
(declaim (ftype function foo1 foo2)) ; muffle warnings
(foo1)
(foo2)
$ cmu-compile foo[123].lisp # "cmu-compile" is itself a small script
...[chatter]...
; foo1.x86f written.
...
; foo1.x86f written.
...
; foo3.x86f written.
; Compilation finished in 0:00:00.
$ cat script_header.cmu foo[123].x86f > foo
$ chmod a+x foo
$ ./foo
This is foo1.
This is foo2.
$
What you can't do is mix source code and FASLs in the same "script". ;-}
+---------------
| Besides just publishing it, could it be added to the main branch
| of the CMUCL code?
+---------------
I've been talking recently to one of the maintainers about that
very thing. But it's a really ugly hack [though short, only ~30
lines for the most interesting bits] since it completely usurps
the normal command-line option processing. It would be good if
a cleaner approach could be taken for the standard distribution.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2d56oflkm.fsf@bertrand.local>
····@rpw3.org (Rob Warnock) writes:
> Not at all. Remember, unlike SBCL, CMUCL still contains a full
> interpreter which is quite fast at running simple code. Also, almost
I'm pretty sure the latest releases of SBCL have an interpreter again.
From: John Thingstad
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <op.tkhqrykipqzri1@pandora.upc.no>
On Wed, 13 Dec 2006 05:48:09 +0100, Bill Atkins <······@rpi.edu> wrote:
> ····@rpw3.org (Rob Warnock) writes:
>
>> Not at all. Remember, unlike SBCL, CMUCL still contains a full
>> interpreter which is quite fast at running simple code. Also, almost
>
> I'm pretty sure the latest releases of SBCL have an interpreter again.
There was a reply to that effect a couple of weeks ago.
But as I understand it isn't enabled by default.
http://groups-beta.google.com/group/comp.lang.lisp/browse_thread/thread/9b4f746c2bb2b7/6fd3d0c55d1cbf32?lnk=st&q=SBCL+interpreter&rnum=2#6fd3d0c55d1cbf32
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Petter Gustad
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <7dvekhbh42.fsf@www.gratismegler.no>
Robert Uhl <·········@NOSPAMgmail.com> writes:
> ····@rpw3.org (Rob Warnock) writes:
> >
> > Robert Uhl <·········@NOSPAMgmail.com> wrote:
> > +---------------
> > | I don't know that any Lisp will ever be suitable for shell scripting...
> > +---------------
> >
> > Hunh?!? I use CMUCL for "shell scripting" all the time!!!
>
> You don't find the start-up times a pain?
time lisp -quiet -core script.core -eval '(script)'
this could be my script, args are (#<Command Line Switch "quiet">
#<Command Line Switch "core" -- ("script.core")>
#<Command Line Switch "eval" -- ("(script)")>)
real 0m0.033s
user 0m0.020s
sys 0m0.010s
time python script.py
this could be my script
real 0m0.039s
user 0m0.020s
sys 0m0.020s
Petter
--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Ian Jackson wrote:
> Thanks for your attention. This has been a public service rant. I
> hope that the community here will take it the right way. Don't get me
> wrong; I like CL as a language and hope to increase my use of it.
I don't know if it counts as right way or not, but it motivated me to
post the "Nikodemus' Common Lisp FAQ", which had been gathering dust
for a while:
http://groups.google.com/group/comp.lang.lisp/msg/59e8d257e9ec648c?dmode=source
...and welcome to Lisp.
Cheers,
-- Nikodemus Siivola
In article <························@73g2000cwn.googlegroups.com>,
<·········@random-state.net> wrote:
>I don't know if it counts as right way or not, but it motivated me to
>post the "Nikodemus' Common Lisp FAQ", which had been gathering dust
>for a while:
>
>http://groups.google.com/group/comp.lang.lisp/msg/59e8d257e9ec648c?dmode=source
>...and welcome to Lisp.
Thanks, that's very helpful.
Have you considered putting that FAQ on a web page ? Not that the web
needs more CL FAQs but it does need more CL FAQs with answers to
questions people might actually ask :-).
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
Ian Jackson wrote:
> >http://groups.google.com/group/comp.lang.lisp/msg/59e8d257e9ec648c?dmode=source
> Have you considered putting that FAQ on a web page ? Not that the web
> needs more CL FAQs but it does need more CL FAQs with answers to
> questions people might actually ask :-).
Yes. The canonical url for the text file is
http://random-state.net/files/nikodemus-cl-faq.txt
I'll tweak it to play nice with some txt-to-html tool or another when I
have some extra time.
Cheers,
-- Nikodemus Siivola
Ian Jackson <········@chiark.greenend.org.uk> writes:
> As an experienced programmer, I've heard a lot about how good Lisp is,
> and I like getting to grips with new languages. After conversations
> with friend who's keen I decided I should learn Common Lisp.
>
> I thought I'd share some of my experiences here. While much of what
> I'm going to say is critical, I'd like to emphasize that I'm not
> giving up on Lisp. I like what I've seen so far, and the hurdles are
> more entrance barriers than they are problems for serious work - but
> they are quite time-consuming, and nowadays we are all in a hurry.
>
> So without futher ado, let me summarise my key point:
>
> * Documentation for introducing Lisp to existing programmers is poor;
> existing tutorials are old or at least outdated.
The "standard" answer is "Practical Common Lisp". It's available at
Amazon, or even online! http://www.gigamonkeys.com/
> A comprehensive resource aimed at contemporary non-Lisp programmers
> is urgently needed. I was going to started an article on the CLiki
> with some pointers and discussion, but as I've written this article
> I've realised that the answers I have found are not really usefully
> transferrable to other people new to Lisp unless they have
> circumstances very like my own.
On cliki, there are several pages dedicated to books, tutorials or
lisp "education"...
> Secondarily:
>
> * Infrastructure for performing tasks which are routine in
> modern programming is often lacking and/or hard to find.
Yes. If you have some time, you might want to build a Lisp
"distribution", like a linux distribution, where you'd prepackage
everything for the novice or lazy user. There's already the LispBox,
but perhaps it's not as maintained or as self contained as needed.
> * Support for Common Lisp development in Debian stable is
> surprisingly poor, given how mature the Lisp world is.
Well there's two aspects:
- It's difficult to package a lisp system at the level of a unix
system. One should really build a self contained lisp system (even
if it's stored as several files on a unix system).
- Actually, despite the stability of some parts of the lisp universe,
there is a lot of evolution, some packages or even some
implementation having a lot of releases, you might even want to use
CVS or darcs heads...
> Below I'll try to justify these assertions, but first here's a list of
> questions that current `Lisp tutorials' fail to address. I think that
> the world needs someone who knows more about this than I do to write a
> single opinionated introduction that answers at least these questions:
>
> Q. If I am using a modern Unix system, which Common Lisp
> implementation should I choose ?
The oneS that best match your needs.
I use clisp (79%), sbcl (19%), cmucl, ecl, gcl, acl (2%).
> Do I need to be using a
> particular operating system to get a good CL development
> environment ?
Not really. clisp works everywhere gcc works. Otherwise, things go
easier on a x86 linux, because that's what most developers work with,
but there are also good implementations usable on other systems or
processors.
> What if I prefer a different OS (or have
> a different version) ?
So you couldn't find with google the implementation for your OS?
What OS do you use on what processor?
Just SBCL lists a matrix with 10 OS on 8 processors...
http://sbcl.sourceforge.net/platform-table.html
> Q. Which development tools should I be using ?
The majority will say emacs + slime. I use emacs + inferior-lisp and
a couple of my own emacs lisp functions. From time to time, I try
slime.
> Summary of the
> key features of SLIME.
Try: http://common-lisp.net/project/slime/
Is there a problem with Internet connectivity somewhere?
> What if I'm a vi (vim) user ?
You must be a masochist. I was a vi user once upon a time, long long
before I got my NeXTstation.
> Q. Quick introduction to installing the relevant development tools
> and libraries (eg, list of Debian packages to install). If this
> turns into a list of instructions of the form `compile this',
> `edit the system definition' etc., then the answer is wrong.
Well, no, there is no SETUP.EXE to download and be set.
Unless you install cygwin on MS-Windows and check the box for clisp.
That'd be the easiest way to install a CL AFAIK.
> Q. Which tutorial on the Common Lisp language itself, and which
> reference, should I be using ? Answer: one tutorial book or
> webpage (I don't know what would be good to recommend) and one
> reference (the Hyperspec, obviously). Provide only one answer to
> each, not any lists; the web is full of lists of Lisp
> information.
The problem is that the Earth is full of different persons. It's not
possible to give ONE tutorial for every body. If you've not noticed
yet, your neighbors are not your clones! So go to a tutorial list,
and browse them all and see which comes better for you.
> Q. Which libraries should I definitely be looking at using, and what
> are they generally good for ?
What program do you want to write? How could WE answer this question
for you? You've been watching too much Starwars, no clones, no jedi
telepathic powers.
> Q. How do I turn my program into an executable ? NB that most Lisp
> FAQs seem to answer this question with either a blank space (!)
> or with some waffle.
It's been almost one year there's a simple positive answer to this
question for most of the free implementations (and it has been for
ever for commercial implementations of course).
But you don't say us what implementation you use. Could anybody with
Jedi telepathic powers help?
> The answer seems to be: "Sorry, this is not
> properly supported by anything yet; you must write a wrapper
> script. Here is an example."
This is not a bad idea in any case. I notice that even programs
compiled to binary ELF most often are launched from a wrapper script
(eg Mozilla, SecondLife, OpenOffice, etc).
> Q. How do I package my program in such a way that non-Lisp people
> will not be freaked out by the installation instructions ?
Well, you're the programmer, and you've got your users. YOU should know.
> [...]
> It was evident that attempting to find a spec to just read wasn't
> going to be very fruitful. Since I've used Lisp variants before on
> occasion, I decided it would be better to pick some project and
> just write a program.
Perhaps you're ripe to write your own tutorial to introduce people
like you to Common Lisp.
> First I thought I'd try starting my favourite lisp and playing with
> the REPL like many of the online tutorials suggest. This was all very
> well but it all seemed very primitive. Several of the lisps I ended
> up trying didn't have command line editing by default in Debian
> stable. Absurd !
Yeah! They're affraid of GPL readline! Absurd, I agree. In anycase,
don't you know rl or emacs? This is unix you know: small utilities
that do one thing well, but one thing. The job of command line
editing is done by libreadline or rl or emacs, not by random programs.
> Also, there were evidently many useful CL packages in Debian, some of
> which I wanted to use, but it seemed difficult to get documentation
> for them. For example, I installed cl-md5, and I could say (require
> 'md5) and have it work, but what to do next ? I wrote a one-liner to
> list the symbols in the package and then extracted their docstrings
> but it was a total pain. Surely, I thought, people can't really go
> about things this way in this day and age ? (I wouldn't even have
> thought of this approach if I wasn't so familiar with Emacs's builtin
> documentation system.)
See what I mean by self containined lisp system distribution?
> But I still find myself amazed at obvious things that appear to be
> missing from the CL standard and the libraries I was using:
>
> I had to write a function to convert a string of bytes (as produced by
> cl-md5) to hex.
There's sb-ext:octets-to-string and sb-ext:string-to-octets I don't
know if it's documented yet in 1.0.
In clisp, there's ext:convert-string-to-bytes and
ext:convert-string-from-bytes and it's documented since a long time.
> Newer (non-broken!) hash functions and so on don't
> seem to be available at all. I couldn't find a library for
> manipulating IP address ranges and masks, and when I tried to write
> the code myself I found that there wasn't even a standard function for
> splitting a string into substrings based on a delimiter !
You seems to have done a lot alone in your corner. Perhaps you should
have asked on irc://irc.freenode.org/#lisp or news:comp.lang.lisp
sooner.
To split a string (which is actually a vector of character, which is a
sequence), there's the SPLIT-SEQUENCE package.
> There is a
> cornucopia of functionality available for meddling with the innards of
> lisp, but hardly any of the pieces used for solving the kinds of
> problems encountered in the modern Internet.
>
> I presume that other people have already written much of the necessary
> code, but it is really hard to know where to look.
Usually, google works well.
By the way, I don't know if other have noticied, but I've even got the
impression that it learns from each user (queries vs. clicks on hits),
so when you keep asking stuff about lisp, it gives more lisp related
answers (and less speach impediment ones).
> Debian is
> well-supplied with CL packages and the infrastructure for loading them
> is good, but it's obviously only of limited use when choosing which
> one I should use.
Perhaps, but this is a unix system, not a lisp system.
> Finally, one problem that I still haven't tackled: Lisp systems all
> seem to have the idea that the way to run lisp programs is to invoke
> the lisp interpreter and type some runes into the REPL; they also
> think that this is the way to compile them too.
Indeed.
> For someone who has been working with Unix, the inability to turn a
> small lisp program into a proper executable, quickly and easily, is
> like returning to the stone age (or to Windows, heaven help us).
Well, it's more like booting a user-mode-linux, or any other Qemu or
Bosch with its own different OS. When've you've booted emacs, you're
in a different OS, emacs not in unix anymore. (See what I mean here:
http://www.informatimago.com/linux/emacs-on-user-mode-linux.html
) When you boot a CL implementation it's the same. Think of it as a
virtual lisp machine running on your linux supervisor.
> It is all very well for large projects to involve learning a lot of
> `system definition' facilities and to expect complicated and
> hard-to-install infrastructure on the computers involved. But often
> it is important to be able to ship small programs, in a form the
> recipient will be able to execute; it is also important to be able to
> make Lisp programs look and work like any other executable on the
> system.
>
> Naturally some of these problems can be addressed with wrapper scripts
> and a few extra tools. That's fine. But where is the standard
> facility for wrapper scripts, that I can put in a #! line ?
Why do you want a wrapper?
#!/usr/bin/clisp
or
#!/usr/bin/sbcl
(or other CL implementations) work perfectly well. For example, my
current ~/bin contains 23 clisp scripts:
% ~/bin/tally-bin
53 Bourne shell script text
129 Bourne-Again shell script text
59 C shell script text
23 a /usr/local/bin/clisp -ansi -q script text
1 awk script text
9 perl script text
> Where are the standard facilities for building *portably-deployable*
> CL programs: by which I mean not `portable to a different Lisp' but
> `a whole distribution bundle which is portable to a computer which
> does not yet have a Lisp system' ?
You'd have first to build your Dell corporation, and sell computers
pre-installed with lisp systems.
Then we could ask where are the standard facilities for building
*portably-deployable* unix programs: by which I mean not "portable to
a different lisp" but "a whole distribution bundle which is portable
to a computer which does not yet have a unix system" ?
Then perhaps we could point you to some emulating software or things
like coLinux or user-mode-linux.
> How do I integrate Lisp compilation into the build system of a large
> project using many languages and tools, all driven by something like
> make ?
Well, I've got my own makefile to do that. Really, it's been a long
time I've not used them anymore. If I have a big project with a
Makefile, at most nowadays it contains something like:
pgm:
@(echo '(LOAD "loader.lisp")' ; echo '(SAVE-IMAGE-FOR-PROJECT "pgm")' )\
| ./bin/lisp.sh
and all the rest is done in loader.lisp, with the help of asdf and
things like that.
> Obviously I could write my own answers but I want to concentrate on
> writing my application, not impedance matching to an approach to
> programming that feels like a 1960's timewarp. Wouldn't it be nice if
> Lisp were dragged kicking and screaming into the mid-1990's ?
It would be even nicer if mid-2000's had the facilities that were
available a long time ago, on the lisp machines. (In the mid-2000's I
still long for features on Mac hardware that were available in the
mid-1990's on NeXT hardware, and that, with basically the same OS and
toolbox!).
> Thanks for your attention. This has been a public service rant. I
> hope that the community here will take it the right way. Don't get me
> wrong; I like CL as a language and hope to increase my use of it.
You've detected a nice business opportunity. Hope you have some time
to implement it. Good Luck!
> I'm posting here to try to document some of the things that make it
> difficult for even an experienced programmer to get involved with
> Common Lisp. If the entrance barriers could be lowered, I think you
> might find it easier to encourage new and useful people to join the
> Lisp community.
I assume that that was what moved Franz, Corman, Lispworks, and the
other commercial implementors to provide well packaged lisp systems.
Commercially. Perhaps if you feel it so painful in the free world,
you could try commercial offerings?
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
>Ian Jackson <········@chiark.greenend.org.uk> writes:
>> * Documentation for introducing Lisp to existing programmers is poor;
>> existing tutorials are old or at least outdated.
>
>The "standard" answer is "Practical Common Lisp". It's available at
>Amazon, or even online! http://www.gigamonkeys.com/
This is helpful of course but if you want to get people started
quickly, a whole book is not a good answer. How long a web page is a
Perl or Python `get you started' tutorial ?
>On cliki, there are several pages dedicated to books, tutorials or
>lisp "education"...
Oh, yes, and I read many of them. But they (a) fail to address the
difficulties that I had (and presumably anyone new to CL has), and
(b) there are huge numbers of them containing huge amounts of
irrelevant material. It's evident that nothing ever gets deleted
(which is one of the common diseases of wikis, unfortunately).
>> Secondarily:
>> * Infrastructure for performing tasks which are routine in
>> modern programming is often lacking and/or hard to find.
>
>Yes. If you have some time, you might want to build a Lisp
>"distribution", like a linux distribution, where you'd prepackage
>everything for the novice or lazy user. There's already the LispBox,
>but perhaps it's not as maintained or as self contained as needed.
All of the languages that Common Lisp is competing with are available
pre-built, and often preinstalled, on all of the major Linux
distributions and many proprietary Unix systems. As are libraries for
writing webservers and clients, quick-and-dirty text processing,
network programming, etc. etc. etc.
What is needed is not a new bundling of the existing work. What is
needed is for the existing work to be present _in existing
distribution mechanisms_ that are already ubiquitous in the non-Lisp
world.
And of course, we need a standard and common set of libraries,
available in the same way. For example, Debian stable has three
Common Lisp regexp libraries. As someone new to Lisp I have no idea
how to choose between them. Obviously I can do research but:
*People writing in Python or Perl or Ruby do not have to do research
to choose between competing regexp libraries!*
To make CL attractive, it is essential that what other languages
regard as trivial and obvious tasks are easily addressed without a
great deal of background reading.
>Well there's two aspects:
>
>- It's difficult to package a lisp system at the level of a unix
> system. One should really build a self contained lisp system (even
> if it's stored as several files on a unix system).
This difficulty needs to be solved. Debian are doing reasonably well
here, and provide a way forward, but (much as I'm a Debian partisan)
Common Lisp needs good support elsewhere too.
Note that `one should really build a self contained lisp system' is
(as someone else said in this thread) just treating Unix like a
bootloader for Lisp. That's not the way complex systems are built in
the real world - the vast manority of significant computing systems
are heterogenous.
Lisp needs to live in a heterogenous world. It needs to cooperate
with other software readily and conveniently. A good FFI is part of
this (I haven't tried the CFFI but I'm told it's reasonable), but also
needed is good access to (and provision of) other kinds of OS-provided
inter-language, inter-process, and inter-system communication
facilities.
Java is the language which comes to my mind as one with the same
insular worldview: you must do everything in Java and you must do it
the Java Way. Java only got away with it because of massive amounts
of marketing hype which persuaded armies of idiot managers that it was
the way of the future.
>> What if I'm a vi (vim) user ?
>
>You must be a masochist. I was a vi user once upon a time, long long
>before I got my NeXTstation.
*blink* I'm not a vi user personally, but do you think that this
response is likely to encourage people to try out Common Lisp ?
>> Q. Which libraries should I definitely be looking at using, and what
>> are they generally good for ?
>
>What program do you want to write? How could WE answer this question
>for you? You've been watching too much Starwars, no clones, no jedi
>telepathic powers.
Have you programmed in Python ? The standard libraries are a bit
disorganised but there is clear documentation, most things that one
wants are provided, and if there is more than one of anything then all
but one are explicitly deprecated with a reference to the preferred
interface. (I'm not a fan of Python, by the way, but like any
programmer in the larger world I deal with it occasionally.)
Indeed, have you programmed recently in anything but Common Lisp ?
If you want CL to become more popular you will have to accomodate and
satisfy the expectations of people from outside the Lisp world.
As newcomers to Common Lisp go I'm am probably unusually fortunate: I
have a wide range of experience with different programming systems;
I've used a Lisp dialect before; I'm an expert on the operating system
I'm using; I'm a native English speaker with a very fast skimreading
rate; and so forth.
If you read my narrative and saw what I went through, just to get
started, doesn't it strike you that others might have similar
problems ?
>Then we could ask where are the standard facilities for building
>*portably-deployable* unix programs: by which I mean not "portable to
>a different lisp" but "a whole distribution bundle which is portable
>to a computer which does not yet have a unix system" ?
The difference is that in the real world there is quite likely already
to be a Unix system.
If you position CL as competing with Unix then you have already lost.
If you want to position it as competing with Perl, Python and C++ you
at least have a chance to play.
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
From: Pedro Kröger
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <87lklmxiob.fsf@gmail.com>
Ian Jackson <········@chiark.greenend.org.uk> writes:
> This is helpful of course but if you want to get people started
> quickly, a whole book is not a good answer. How long a web page is a
> Perl or Python `get you started' tutorial ?
could you point some of those tutorials? so we can have an idea of what
you consider to be good.
> Oh, yes, and I read many of them. But they (a) fail to address the
> difficulties that I had (and presumably anyone new to CL has), and
> (b) there are huge numbers of them containing huge amounts of
> irrelevant material. It's evident that nothing ever gets deleted
> (which is one of the common diseases of wikis, unfortunately).
again, could you, please, point what difficulties you had and what you'd
expect to have in these tutorials? I'm not trying to be picky here (or
whatever), I'm just trying to understand what people think is missing so
we can a) direct then to something that already exists and solve it, of
b) create it.
For instance, what do you think of this introduction by Paul Graham?
http://lib.store.yahoo.net/lib/paulgraham/acl2.txt
Pedro Kroger
In article <··············@gmail.com>,
Pedro =?utf-8?Q?Kr=C3=B6ger?= <············@gmail.com> wrote:
>Ian Jackson <········@chiark.greenend.org.uk> writes:
>> This is helpful of course but if you want to get people started
>> quickly, a whole book is not a good answer. How long a web page is a
>> Perl or Python `get you started' tutorial ?
>
>could you point some of those tutorials? so we can have an idea of what
>you consider to be good.
http://www.python.org/doc/Intros.html has a bunch of them. Having a
look at the descriptions there and with a quick overview, the ones
under `Introductions for programmers' seem like the kind of thing that
Lisp is really lacking.
Particularly, look at the structure of
http://www.python.org/doc/lj21.html
which starts with the assumption that you don't know how to run Python
and in the next paragraph tells you how to make a script with a #!-line.
Python tutorials have it slightly easier because the support is
generally shipped with most people's operating systems. The Linux
Journal article http://www.linuxjournal.com/article/3946 does deal
with this to some extent but more work is needed to make a pleasant
Common Lisp environment so a CL introduction ought to pay more
attention to that.
(I wouldn't say that these documents are necessarily `good' - I
haven't reviewed them with that kind of eye and anyway I'm not really
a Python expert - but they're an example of the kind of size,
structure and topics I would like covered in an analogous document for
CL.)
>again, could you, please, point what difficulties you had and what you'd
>expect to have in these tutorials? I'm not trying to be picky here (or
>whatever), I'm just trying to understand what people think is missing so
>we can a) direct then to something that already exists and solve it, of
>b) create it.
They tend not to answer the questions I posed in my original posting.
Rather, they are introductions to the Common Lisp language itself.
Speaking personally I've previously been exposed to the basic
constructs found in various lisps and was happy to use the hyperspec
and guesswork. For others there is copious and high-quality
documentation for the language itself.
>For instance, what do you think of this introduction by Paul Graham?
>http://lib.store.yahoo.net/lib/paulgraham/acl2.txt
This is exactly an example of the kind of high-quality language
documentation I mention above. Typically they can be thought of as
`a tutorial on what forms to type into a REPL' to get started with the
CL core.
That's not what I think is missing: what I want is `how to get to a
nice REPL with command history and completion and integrated
documentation lookup'; `how to find a library to do XYZ'; `how to make
a Unix program out of my Lisp program' etc. - impedance matching.
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
Ian Jackson wrote:
> That's not what I think is missing: what I want is `how to get to a
> nice REPL with command history and completion and integrated
> documentation lookup'; `how to find a library to do XYZ'; `how to make
> a Unix program out of my Lisp program' etc. - impedance matching.
Now I see. I believe a single tutorial like this is indeed missing. I
suppose that's not that easy because there is not only one
implementation of lisp (like python) that 'dictates' how things should
be done. So, how one gets started with C? if he uses gcc he may compile
using the shell, OTOH if using visual C the approach may be different.
Anyway, I do think that a documentation of this kind could be useful,
and could, of course, point to the others documentations.
Pedro Kroger
Hi there!
Pedro Kr�ger wrote:
> Ian Jackson <········@chiark.greenend.org.uk> writes:
>
> > This is helpful of course but if you want to get people started
> > quickly, a whole book is not a good answer. How long a web page is a
> > Perl or Python `get you started' tutorial ?
>
> could you point some of those tutorials? so we can have an idea of what
> you consider to be good.
Excuse me for just jumping in, but I feel these are really good points.
I read the Paul Graham stuff as well and got all fired up about the
Lisp thing... However, I found it really hard to get anywhere with the
"standard" documentation -- and I read a lot of it. I tried several
Lisps, all considered reasonable implementations of Common Lisp. All
very hard to deal with. And trying to learn the language from the
HyperSpec? I stand in awe of Mr. Jackson's patience. It must surely be
that of a saint.
I'm not totally new to the programming thing -- I've written
interesting programs in various languages, embedded systems to
"enterprise", however, I couldn't get anywhere with common Lisp beyond
a few parlour tricks. I once wrote a CGI program in it for listing
directories for clients to download their files from our web server...
That was certainly an inglorious two pages of code. Certainly no fault
of the language, but every fault of my not being able to get a good
grip on the language.
Then (cue Holy Light and Angelic Chorus), I discovered NewLisp. Yes, I
know it doesn't have whossname variables or do untactic declosures in
the canonical form. However... And this is a *biggie*, it works almost
seamlessly on all major platforms and it has Human Readable
Documentation (tm). The documentation is what I'm here to tell you
about.
The NewLisp documentation is complete (every function, every
variation), reasonably organized, easy to get a handle on, and INCLUDES
A WORKED OUT EXAMPLE FOR EVERYTHING! Yes, that one thing (in the
screaming caps) has done wonders for my comprehension and appreciation
of Lisp. Whatever you may think about Mr. Mueller's implementation, it
is a *useable* implementation because he (or whoever) thought to
include those examples. Then, he took a good thing and made it even
better with his "Code Patterns" document, which shows the NewLisp-y way
to approach lots of common problems.
If you could provide a Common Lisp version of that one document ("Code
Patterns") and point all newcomers to it you would be doing future
newbies a great service. It's not necessary to appreciate or understand
*all* the clever ways to do something when you're starting, just *a*
way! The cleverness will come later when the learner has aquired
confidence in both the language and his/her ability to use it to solve
relevant problems.
Thank you for your time.
On 2006-12-10 09:09:24 -0500, ·····@rocketage.org said:
> Excuse me for just jumping in, but I feel these are really good points.
> I read the Paul Graham stuff as well and got all fired up about the
> Lisp thing... However, I found it really hard to get anywhere with the
> "standard" documentation -- and I read a lot of it. I tried several
> Lisps, all considered reasonable implementations of Common Lisp. All
> very hard to deal with. And trying to learn the language from the
> HyperSpec? I stand in awe of Mr. Jackson's patience. It must surely be
> that of a saint.
Let me put in my 2 cents, if anybody cares to listen - I don't even
know if Ian Jackson is still reading.
My impression of why learning lisp can be so difficult even for
experienced programmers coming from perl/c/python/java/etc.- I went
through a similar process - is that they try to apply the same model
they have sucessully used for each new language:
1. Download the best/standard/ *free* version of the language
2. Download a brief tutorial
3. profit !!! ;^)
Unfortunately:
1. the best free versions of common lisp are not the best environments
for *learning* common lisp.
2. the best brief online tutorials out there are not the best
documentation for *learning* common lisp.
The best environments for learning common lisp are the free trial
versions of the commercial implementations - LispWorks, MCL, Allegro
Common Lisp, Corman Common Lisp. I personally would choose LispWorks if
you're on the Mac, and either LispWorks or Corman if you're on Windows.
I'll let linux users say which free trial edition is the easiest to
work with on various linux distros.
The best documentation for learning common lisp is the freely available
Practical Common Lisp by Peter Siebel (which you should probably just
buy at some point since you'll want a dead tree copy anyway) available
at http://www.gigamonkeys.com/book.
If you're an experienced programmer and you do these things - download
the free trial of LispWorks, download PCL, and follow allong with PCL
in LispWorks a couple of hours a day, you'll be up to usable speed in
lisp in a few weeks at most. Of course fully *mastering* the language
will take significantly longer, but this is true of any powerful
language.
good luck,
Ralph
On Mon, 11 Dec 2006 00:47:47 -0500, Raffael Cavallaro wrote:
>
> The best environments for learning common lisp are the free trial
> versions of the commercial implementations
Name one advantage the trial versions have over the Free implementations
that is relevant to learning the language.
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
From: Pascal Costanza
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <4u8jhuF153q4hU1@mid.individual.net>
Chris Barts wrote:
> On Mon, 11 Dec 2006 00:47:47 -0500, Raffael Cavallaro wrote:
>
>> The best environments for learning common lisp are the free trial
>> versions of the commercial implementations
>
> Name one advantage the trial versions have over the Free implementations
> that is relevant to learning the language.
The fact that they come with development environments which to a certain
degree behave like those for other languages can be an advantage for
some. Not everyone wants to learn Lisp and Emacs at the same time. ;)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
Pascal Costanza wrote:
> Chris Barts wrote:
> > Name one advantage the trial versions have over the Free implementations
> > that is relevant to learning the language.
> The fact that they come with development environments which to a certain
> degree behave like those for other languages can be an advantage for
> some. Not everyone wants to learn Lisp and Emacs at the same time. ;)
True. The opposite is true for those people already using Emacs, which
is not exactly a small percentage of programmers... ;-)
Cheers,
-- Nikodemus
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <umFfh.215$oR3.134@newsfe08.lga>
·········@random-state.net wrote:
> Pascal Costanza wrote:
>
>
>>Chris Barts wrote:
>
>
>>>Name one advantage the trial versions have over the Free implementations
>>>that is relevant to learning the language.
>
>
>>The fact that they come with development environments which to a certain
>>degree behave like those for other languages can be an advantage for
>>some. Not everyone wants to learn Lisp and Emacs at the same time. ;)
>
>
> True. The opposite is true for those people already using Emacs, which
> is not exactly a small percentage of programmers... ;-)
Something like ACL offers* the kind of IDE noobs would expect (and Emacs
mode!) and easy install and a better project manager than ASDF and lotsa
tools right off the shelf and graphical inspectors and..
ken
* on win32 and *nix.
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m23b7k8jkv.fsf@bertrand.local>
Chris Barts <··············@tznvy.pbz> writes:
> On Mon, 11 Dec 2006 00:47:47 -0500, Raffael Cavallaro wrote:
>
>>
>> The best environments for learning common lisp are the free trial
>> versions of the commercial implementations
>
> Name one advantage the trial versions have over the Free implementations
> that is relevant to learning the language.
Why so confrontational?
The free implementations require zero configuration and the LispWorks
IDE is way more mature and featureful than SLIME (graphical
inspectors, class browser, system browser, an extensible editor in
Common Lisp). You also get a full GUI toolkit that you can play
around with. I am sure the other commercial implementations are
comparable, although I have less experience with them.
"Commercial" does not imply "bad." If you've got a problem with
commercial software, you can always pick up the basics in a commerical
Lisp and then set up the free "equivalents" when you're more familiar
with Lisp.
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <5zOfh.336$ne7.80@newsfe12.lga>
Bill Atkins wrote (ironically):
> "Commercial" does not imply "bad."
Hey! Reread your Stallman:
"I consider that the golden rule requires that if I like a program I
must share it with other people who like it. Software sellers want to
divide the users and conquer them, making each..." Evil software
resellers, you!.
Would the "oh, RMS never said that" crowd please now summon up the
slimmest shred of intellectual honesty and post for everyone to see,
"Oh. Sh*t. You are right."?
.
.
.
.
.
.
.
.
.
I did not think so. Why not, given the facts?
Easy. Free software has become a cult.
Every time I say this on this august forum replete with the best of the
best, the yobbos descend on me like so many barbara schwarziand
scientology pit bulls, so wrought in their internal frency they do not
notice they are proving my point. Smart folks, btw, would notice and
adjust their spin. Not the FSF yobbos, leaving open the question...
exactly how smart are they? Maybe not as such as I guessed.
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Bill Atkins wrote (ironically):
> > "Commercial" does not imply "bad."
>
> Hey! Reread your Stallman:
>
> "I consider that the golden rule requires that if I like a program I
> must share it with other people who like it. Software sellers want to
> divide the users and conquer them, making each..." Evil software
> resellers, you!.
>
> Would the "oh, RMS never said that" crowd please now summon up the
> slimmest shred of intellectual honesty and post for everyone to see,
> "Oh. Sh*t. You are right."?
> .
> .
> .
> .
> .
> .
> .
> .
> .
> I did not think so. Why not, given the facts?
>
> Easy. Free software has become a cult.
>
> Every time I say this on this august forum replete with the best of the
> best, the yobbos descend on me like so many barbara schwarziand
> scientology pit bulls, so wrought in their internal frency they do not
> notice they are proving my point. Smart folks, btw, would notice and
> adjust their spin. Not the FSF yobbos, leaving open the question...
> exactly how smart are they? Maybe not as such as I guessed.
>
> kt
>
Fortunately, most "open source" people aren't following the cult of
Marshall Applewhite, doh!, I mean Stallman. Here's what Stallman
really feels about software:
> `We are not here to give users what
> they want' -- RMS, at GUADEC 2001
>
> I am glad my words have not been forgotten.
> We are not here to give users what they want.
> We are here to spread freedom.
http://mail.gnome.org/archives/foundation-list/2002-May/msg00025.html
·············@gmail.com" <············@gmail.com> writes:
> Fortunately, most "open source" people aren't following the cult of
> Marshall Applewhite, doh!, I mean Stallman. Here's what Stallman
> really feels about software:
>
>> `We are not here to give users what
>> they want' -- RMS, at GUADEC 2001
>>
>> I am glad my words have not been forgotten.
>> We are not here to give users what they want.
>> We are here to spread freedom.
Sounds good, from an ethical point of view.
Even if somebody would want to be your slave, it's forbidden by morals
and laws to take her as your slave.
So users don't want freedom?
Doesn't matter, ethical people will give it to them anyways.
> http://mail.gnome.org/archives/foundation-list/2002-May/msg00025.html
--
__Pascal Bourguignon__ http://www.informatimago.com/
Grace personified,
I leap into the window.
I meant to do that.
Pascal Bourguignon wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
> > Fortunately, most "open source" people aren't following the cult of
> > Marshall Applewhite, doh!, I mean Stallman. Here's what Stallman
> > really feels about software:
> >
> >> `We are not here to give users what
> >> they want' -- RMS, at GUADEC 2001
> >>
> >> I am glad my words have not been forgotten.
> >> We are not here to give users what they want.
> >> We are here to spread freedom.
>
> Sounds good, from an ethical point of view.
> Even if somebody would want to be your slave, it's forbidden by morals
> and laws to take her as your slave.
>
Oops, but we're talking about software here and not slavery. I see
you're drinking the Stallman kool-aid. Carry on.
> So users don't want freedom?
> Doesn't matter, ethical people will give it to them anyways.
>
"Here's some C source code you ignorant user that was once a slave. I
think it's a number guessing game.. You should just be thankful you're
free now."
> > http://mail.gnome.org/archives/foundation-list/2002-May/msg00025.html
>
>
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
> Grace personified,
> I leap into the window.
> I meant to do that.
·············@gmail.com" <············@gmail.com> writes:
> Pascal Bourguignon wrote:
>> ·············@gmail.com" <············@gmail.com> writes:
>>
>> > Fortunately, most "open source" people aren't following the cult of
>> > Marshall Applewhite, doh!, I mean Stallman. Here's what Stallman
>> > really feels about software:
>> >
>> >> `We are not here to give users what
>> >> they want' -- RMS, at GUADEC 2001
>> >>
>> >> I am glad my words have not been forgotten.
>> >> We are not here to give users what they want.
>> >> We are here to spread freedom.
>>
>> Sounds good, from an ethical point of view.
>> Even if somebody would want to be your slave, it's forbidden by morals
>> and laws to take her as your slave.
>>
>
> Oops, but we're talking about software here and not slavery. I see
> you're drinking the Stallman kool-aid. Carry on.
>
>> So users don't want freedom?
>> Doesn't matter, ethical people will give it to them anyways.
>>
>
> "Here's some C source code you ignorant user that was once a slave. I
> think it's a number guessing game.. You should just be thankful you're
> free now."
Another thing to remember (and people who don't seem to like freedom
software often seem to forget it), is that freedom software is most
often not _paid for_. Why should user get what they want, if they
don't pay for anything? Outside of any contract, the provider can
choose what he provides: software users want, or freedom. His choice!
Now, if the question was what the user wants to buy, that'd be
different. Perhaps he'd get what he wants, if he was ready to pay for
it. Most users don't seem to be ready to pay for software, you can
accuse RMS of that, it was true even before he started GNU. Perhaps
if more users were ready to buy custom software, there'd be more
custom software developed, don't you think?
And indeed, there's a third category which is often mixed with freedom
software: paid by your taxes software, like university developed
software (often under BSD or MIT licences). Of course, this software
ought better do what the buyer wants (but often the buyer (eg tax
payer) doesn't want the software per se, but the knowledge the
developing of the software brought, in these cases).
--
__Pascal Bourguignon__ http://www.informatimago.com/
HEALTH WARNING: Care should be taken when lifting this product,
since its mass, and thus its weight, is dependent on its velocity
relative to the user.
Pascal Bourguignon wrote:
> ·············@gmail.com" <············@gmail.com> writes:
>
> > Pascal Bourguignon wrote:
> >> ·············@gmail.com" <············@gmail.com> writes:
> >>
> >> > Fortunately, most "open source" people aren't following the cult of
> >> > Marshall Applewhite, doh!, I mean Stallman. Here's what Stallman
> >> > really feels about software:
> >> >
> >> >> `We are not here to give users what
> >> >> they want' -- RMS, at GUADEC 2001
> >> >>
> >> >> I am glad my words have not been forgotten.
> >> >> We are not here to give users what they want.
> >> >> We are here to spread freedom.
> >>
> >> Sounds good, from an ethical point of view.
> >> Even if somebody would want to be your slave, it's forbidden by morals
> >> and laws to take her as your slave.
> >>
> >
> > Oops, but we're talking about software here and not slavery. I see
> > you're drinking the Stallman kool-aid. Carry on.
> >
> >> So users don't want freedom?
> >> Doesn't matter, ethical people will give it to them anyways.
> >>
> >
> > "Here's some C source code you ignorant user that was once a slave. I
> > think it's a number guessing game.. You should just be thankful you're
> > free now."
>
> Another thing to remember (and people who don't seem to like freedom
> software often seem to forget it), is that freedom software is most
> often not _paid for_. Why should user get what they want, if they
> don't pay for anything? Outside of any contract, the provider can
> choose what he provides: software users want, or freedom. His choice!
>
Exactly, and once again:
"Here's some C source code you ignorant user that was once a slave. I
think it's a number guessing game.. You should just be thankful
you're
free now."
Oh, make that GNU/Thankful.
>snip<
No, you've tried to skate around the issue enough. Explaining obvious
software models won't help you.
Here you go:
> >> Sounds good, from an ethical point of view.
> >> Even if somebody would want to be your slave, it's forbidden by morals
> >> and laws to take her as your slave.
> >>
> >
> > Oops, but we're talking about software here and not slavery. I see
> > you're drinking the Stallman kool-aid. Carry on.
> >> So users don't want freedom?
> >> Doesn't matter, ethical people will give it to them anyways.
Windows should be banned, and a new era of GNUtopia should be given to
us anyway. I look forward to GNU messages of the day in all my apps.
> --
> __Pascal Bourguignon__ http://www.informatimago.com/
>
> HEALTH WARNING: Care should be taken when lifting this product,
> since its mass, and thus its weight, is dependent on its velocity
> relative to the user.
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m24przg91e.fsf@bertrand.local>
Pascal Bourguignon <···@informatimago.com> writes:
> Another thing to remember (and people who don't seem to like freedom
> software often seem to forget it), is that freedom software is most
> often not _paid for_. Why should user get what they want, if they
> don't pay for anything?
Um, this certainly isn't something I've forgotten, and I think it's
one of the main arguments against using "free" software.
> Outside of any contract, the provider can
> choose what he provides: software users want, or freedom. His choice!
And that's why I pay for working, featureful software. I have a
computer so I can do useful things with it, not so I can feel better
about myself because the source code to all of the software I use is
freely available.
Stallman summed it up nicely at one of his lectures. An audience
member asked him if progress or freedom was more important; he
answered, "Freedom." Silly, silly, silly.
Bill Atkins <······@rpi.edu> writes:
> Stallman summed it up nicely at one of his lectures. An audience
> member asked him if progress or freedom was more important; he
> answered, "Freedom." Silly, silly, silly.
At least you are not alone with your opinion that progress is more
important than freedom: as much as I understand also the Chinese government
thinks this way.
Nicolas
Nicolas Neuss wrote:
> Bill Atkins <······@rpi.edu> writes:
>
> > Stallman summed it up nicely at one of his lectures. An audience
> > member asked him if progress or freedom was more important; he
> > answered, "Freedom." Silly, silly, silly.
>
> At least you are not alone with your opinion that progress is more
> important than freedom: as much as I understand also the Chinese government
> thinks this way.
"Using proprietary software is like living under a communist
dictatorship"
Just like clockwork, and it just flows out of their keyboards so easily.
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2tzzz96jk.fsf@bertrand.local>
Nicolas Neuss <········@mathematik.uni-karlsruhe.de> writes:
> Bill Atkins <······@rpi.edu> writes:
>
>> Stallman summed it up nicely at one of his lectures. An audience
>> member asked him if progress or freedom was more important; he
>> answered, "Freedom." Silly, silly, silly.
>
> At least you are not alone with your opinion that progress is more
> important than freedom: as much as I understand also the Chinese government
> thinks this way.
False analogy. With China, you're talking about political freedom of
individuals, which is obviously important. The ability to read the
source code of some computer program and to get that program without
paying for it is not a fundamental right, and calling it "freedom" is
simple propaganda.
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2slfjg6vu.fsf@bertrand.local>
Bill Atkins <······@rpi.edu> writes:
>> At least you are not alone with your opinion that progress is more
>> important than freedom: as much as I understand also the Chinese government
>> thinks this way.
>
> False analogy. With China, you're talking about political freedom of
> individuals, which is obviously important. The ability to read the
> source code of some computer program and to get that program without
> paying for it is not a fundamental right, and calling it "freedom" is
> simple propaganda.
Also, I can't tell you happy it makes me that you've basically accused
me of being a (literal) fascist because I don't place Stallman's
peculiar idea of source code freedom above all else.
Bill Atkins <······@rpi.edu> writes:
>>>> Stallman summed it up nicely at one of his lectures. An audience
>>>> member asked him if progress or freedom was more important; he
>>>> answered, "Freedom." Silly, silly, silly.
> >>
> >> At least you are not alone with your opinion that progress is more
> >> important than freedom: as much as I understand also the Chinese
> >> government thinks this way.
> >
> > False analogy. With China, you're talking about political freedom of
> > individuals, which is obviously important. The ability to read the
> > source code of some computer program and to get that program without
> > paying for it is not a fundamental right, and calling it "freedom" is
> > simple propaganda.
>
> Also, I can't tell you happy it makes me that you've basically accused
> me of being a (literal) fascist because I don't place Stallman's
> peculiar idea of source code freedom above all else.
Is the Chinese government fascist? I wouldn't call it so. I fear that the
world is a lot more complicated than you seem to percieve it. This is the
case also with the slogan "freedom versus progress" - both in politics and
in software.
Nicolas
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m21wn3a4ag.fsf@bertrand.local>
Nicolas Neuss <········@mathematik.uni-karlsruhe.de> writes:
> Bill Atkins <······@rpi.edu> writes:
>
>>>>> Stallman summed it up nicely at one of his lectures. An audience
>>>>> member asked him if progress or freedom was more important; he
>>>>> answered, "Freedom." Silly, silly, silly.
>> >>
>> >> At least you are not alone with your opinion that progress is more
>> >> important than freedom: as much as I understand also the Chinese
>> >> government thinks this way.
>> >
>> > False analogy. With China, you're talking about political freedom of
>> > individuals, which is obviously important. The ability to read the
>> > source code of some computer program and to get that program without
>> > paying for it is not a fundamental right, and calling it "freedom" is
>> > simple propaganda.
>>
>> Also, I can't tell you happy it makes me that you've basically accused
>> me of being a (literal) fascist because I don't place Stallman's
>> peculiar idea of source code freedom above all else.
>
> Is the Chinese government fascist? I wouldn't call it so. I fear that the
> world is a lot more complicated than you seem to percieve it. This is the
> case also with the slogan "freedom versus progress" - both in politics and
> in software.
I wasn't using the term in the Mussolini sense. See definition #2 at
http://www.askoxford.com/concise_oed/fascism?view=uk
Nevertheless, arguing about semantics ignores the comical
outlandishness of your claim that political repression has anything to
do with choosing to use non-"free" software.
You'll notice that I didn't suggest there was a dichotomy between
freedom and progress - I simply related an incident which I had the
good fortune to witness (the person who asked the question was not me,
in case that's what you're thinking). The point was that Stallman and
co. are willing to elevate their weird attachment to sharing source
code above advancements in software technology and the usefulness of
computers.
Stallman's part in the story is supposed to strike you as bizarre and
fanatical. Instead, you appear to think that the morals of the story
are 1) that I see the world very simplistically, 2) that I think
economic progress is more valuable than political freedom (that is,
after all, what's behind your reference to China, is it not?), and 3)
that I advocate the use of the slogan "freedom versus progress" (note
that despite your quotation marks, I never used this phrase in my
post). I'd be interested to know how you got to these conclusions
from my post.
On 2006-12-13 10:09:19 -0500, Bill Atkins <······@rpi.edu> said:
> The ability to read the
> source code of some computer program and to get that program without
> paying for it is not a fundamental right, and calling it "freedom" is
> simple propaganda.
This is the fundamental point that Stallman boosters continually ignore
- that he defines "freedom" in a rather idiosyncratic way to mean "the
ability to read and modify the source code of any computer program and
redistribute the result."
I think this rates very, very low on most normal people's scale of
guaranteed human freedoms. For example, almost no one would think that
the definition of "freedom" is to be able to trivially modify a novel
by Stephen King and publish the result - more like the definition of
"ripoff." But somehow this is what "freedom" means if we're talking
about computer code.
Bill Atkins <······@rpi.edu> writes:
> Pascal Bourguignon <···@informatimago.com> writes:
>
>> Another thing to remember (and people who don't seem to like freedom
>> software often seem to forget it), is that freedom software is most
>> often not _paid for_. Why should user get what they want, if they
>> don't pay for anything?
>
> Um, this certainly isn't something I've forgotten, and I think it's
> one of the main arguments against using "free" software.
It might be worth repeating, it's not often told...
With free software, you get what the _programmer_ wants to provide,
not what the _user_ wants to get.
But also, it might be worth repeating that with shrinkwrapped software
the situation is not too different:
With shrinkwrapped software, you get what the _vendor_ wants to
provide to serve the best interests of his shareholders, not what the
_user_ want to get. At most, the _user_ might get what the majority
of the other _users_ want, not what he wants.
As a user and personal experience, I can only say that free software
provides me what I want more often and more _persistently_ than
shrinkwrapped software. It looks like shrinwrapped software is not
usable after three of four years anyhow, while I've been using the
"same" (but not same version) free software for tens of years.
>> Outside of any contract, the provider can
>> choose what he provides: software users want, or freedom. His choice!
>
> And that's why I pay for working, featureful software. I have a
> computer so I can do useful things with it, not so I can feel better
> about myself because the source code to all of the software I use is
> freely available.
Is it custom made software, or shrinkwrap?
> Stallman summed it up nicely at one of his lectures. An audience
> member asked him if progress or freedom was more important; he
> answered, "Freedom." Silly, silly, silly.
Without freedom there can't be any progress. Of course, freedom is
more important than progress, because it's what allows progress.
--
__Pascal Bourguignon__ http://www.informatimago.com/
The mighty hunter
Returns with gifts of plump birds,
Your foot just squashed one.
On 2006-12-13 12:55:27 -0500, Pascal Bourguignon <···@informatimago.com> said:
> With shrinkwrapped software, you get what the _vendor_ wants to
> provide to serve the best interests of his shareholders, not what the
> _user_ want to get. At most, the _user_ might get what the majority
> of the other _users_ want, not what he wants.
But for most users, what the majority of other users want is what he
wants too. In practice this often beats getting what the developer of a
free software package wants to give you.
I therefore don't think it's possible to generalize about the quality
of features in free v. commercial software. Some free software is
excellent, much sucks. Some commercial software is excellent, much
sucks.
This means that the real issues are those of politics and economics. I
don't think that some hackers' desire (note not *right* or *freedom*,
but *desire*) to have modifyable, redistributable source code outweighs
the economic interests of people who make a living by writing software.
Stallman clearly does as seen in the quotes Kenny has pointed to many
times.
Finally, the law in the US, which the people of the US have the freedom
to change if they wish, agrees with me and Kenzo, not Stallman - by
default any new work is under copy*right* - you have to go out of your
way to make it copy*left*. If most people really agreed strongly with
Stallman on this it would change very quickly. Stallman represents a
minority political opinion about convenience to some programmers which
he has attempted to elevate to the status of "freedom." He has been
aided in this by the unfortunate fact that gratis and libertas can both
be rendered by the english word "free," and wanting stuff gratis is
*not* a minority opinion.
Nevertheless, even with the added support of many people wanting stuff
cost-free, copyleft has still not become a majority political opinion.
This is because when people think about the whole issue calmly, without
focusing solely on the fact that they could get more stuff for no-cost,
they see that making all works copyleft would have a huge negative
economic effect, turning the entire knowledge based economy into a race
to the bottom (lowest production cost wins since all IP is freely
available to everyone). The people of the US at the very least
understand that you need to compensate those who do original work. How
much and for how long are clearly topics of contention and discussion -
patent and copyright terms, etc.-, but the overwhelming majority
understands that making all IP freely available without compensation to
authors/researchers/discoverers is a recipe for economic disaster.
Pascal Bourguignon wrote:
> > Stallman summed it up nicely at one of his lectures. An audience
> > member asked him if progress or freedom was more important; he
> > answered, "Freedom." Silly, silly, silly.
>
> Without freedom there can't be any progress. Of course, freedom is
> more important than progress, because it's what allows progress.
You know, while fools like RMS are whining on about free software,
people out there in the real world are dying of preventable diseases in
their hundreds of millions. I might note that Bill Gates has done more
to prevent this than all of the free software bigots that have ever
lived.
From: Robert Uhl
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m37iwu1mld.fsf@latakia.dyndns.org>
"Tim Bradshaw" <··········@tfeb.org> writes:
>
> You know, while fools like RMS are whining on about free software,
> people out there in the real world are dying of preventable diseases
> in their hundreds of millions. I might note that Bill Gates has done
> more to prevent this than all of the free software bigots that have
> ever lived.
An intelligent analysis would have to figure out a net value for free
software, and a net value for the work of the Gates Foundation; such an
analysis would probably take months if not years of research and its
conclusions would no doubt be difficult to replicate.
And many of those preventable deaths are attributable to Rachel Carson;
I'm not certain how RMS or anyone else in the software world is supposed
to have influence there.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The object-oriented model makes it easy to build up programs by
accretion. What this often means, in practise, is that it
provides a structured way to write spaghetti code.
--Paul Graham
On 2006-12-14 11:14:22 -0500, Robert Uhl <·········@NOSPAMgmail.com> said:
> And many of those preventable deaths are attributable to Rachel Carson;
Just checking, but are we talking about malaria and DDT here?
From: Marcus Breiing
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <elsgo9$c05$1@chessie.cirr.com>
"Tim Bradshaw" <··········@tfeb.org> writes:
[You're worrying about your own little shitty problems while....]
> PEOPLE OUT THERE IN THE REAL WORLD ARE DYING
I love your kind of argument and would totally like to buy it. Real
honest. It's just that my CS teachers (dishonestly?) insisted that
"most-unlikely-to-ever-even-finish-job-first" (MUTEEFJF) is a rotten
job scheduling algorithm. Please help!
--
Marcus Breiing
(Cologne, Germany)
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
> Another thing to remember (and people who don't seem to like freedom
> software often seem to forget it), is that freedom software is most
> often not _paid for_. Why should user get what they want, if they
> don't pay for anything? Outside of any contract, the provider can
> choose what he provides: software users want, or freedom. His choice!
Well, recently I became disillusioned over "gnu-freedom" because it
basically amounts to a "freedom" that is of marginal benefit to most
groups. This came up in the Mass. debates about OpenDocument format
in which gnu-freedom advocates were outraged that users with
disabilities valued the quality of utilities used to exercise their
rights under the ADA over freedom of source code. How dare those
with motor and vision disabilities consider workplace equity over
their freedom to hack? How dare they accept any compromise in
source-code access for the sake of the ability to use a system?
Now personally, I'm in a bit of the middle ground in my rather
strong advocacy of thin copyright and encouragement of resources
donated to the public good under free copyleft and non copyleft
terms. But the rather dogmatic and narrow view of freedom expressed
by the FSF often disturbs me.
But on the other hand, I don't think it's an either/or proposition
here. Many free software projects do listen to what software users
want because they want to attract more software users.
From: Takehiko Abe
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <keke-1312061857270001@192.168.1.2>
In article <················@newsfe12.lga>, Ken Tilton
<·········@gmail.com> wrote:
> Hey! Reread your Stallman:
>
> "I consider that the golden rule requires that if I like a program I
> must share it with other people who like it. Software sellers want to
> divide the users and conquer them, making each..." Evil software
> resellers, you!.
>
> Would the "oh, RMS never said that" crowd please now summon up the
> slimmest shred of intellectual honesty and post for everyone to see,
> "Oh. Sh*t. You are right."?
Where is your intellectual honesty??
http://www.gnu.org/gnu/manifesto.html
|Why I Must Write GNU
|
|I consider that the golden rule requires that if I like a
|program I must share it with other people who like it. Software
|sellers want to divide the users and conquer them, making each
|user agree not to share with others.
It continues:
|I refuse to break solidarity with other users in this way. I
|cannot in good conscience sign a nondisclosure agreement or a
|software license agreement. For years I worked within the
|Artificial Intelligence Lab to resist such tendencies and other
|inhospitalities, but eventually they had gone too far: I could
|not remain in an institution where such things are done for me
|against my will.
And today, after 20 long years, where is the Lisp OS? ...Oh
shit, Stallman was right.
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <b8Wfh.16$C51.9@newsfe08.lga>
Takehiko Abe wrote:
> In article <················@newsfe12.lga>, Ken Tilton
> <·········@gmail.com> wrote:
>
>
>>Hey! Reread your Stallman:
>>
>>"I consider that the golden rule requires that if I like a program I
>>must share it with other people who like it. Software sellers want to
>>divide the users and conquer them, making each..." Evil software
>>resellers, you!.
>>
>>Would the "oh, RMS never said that" crowd please now summon up the
>>slimmest shred of intellectual honesty and post for everyone to see,
>>"Oh. Sh*t. You are right."?
>
>
> Where is your intellectual honesty??
>
> http://www.gnu.org/gnu/manifesto.html
Right here (from there ^^^):
"Many programmers are unhappy about the commercialization of system
software. It may enable them to make more money, but it requires them to
feel in conflict with other programmers in general rather than feel as
comrades."
> And today, after 20 long years, where is the Lisp OS?
Right here:
http://common-lisp.net/project/movitz/movitz.html
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2mz5sgdtv.fsf@bertrand.local>
Bill Atkins <······@rpi.edu> writes:
> Chris Barts <··············@tznvy.pbz> writes:
>
>> On Mon, 11 Dec 2006 00:47:47 -0500, Raffael Cavallaro wrote:
>>
>>>
>>> The best environments for learning common lisp are the free trial
>>> versions of the commercial implementations
>>
>> Name one advantage the trial versions have over the Free implementations
>> that is relevant to learning the language.
>
> Why so confrontational?
>
> The free implementations require zero configuration and the LispWorks
This should read "commercial implementations." :)
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m23b7k8jkv.fsf@bertrand.local>
Chris Barts <··············@tznvy.pbz> writes:
> On Mon, 11 Dec 2006 00:47:47 -0500, Raffael Cavallaro wrote:
>
>>
>> The best environments for learning common lisp are the free trial
>> versions of the commercial implementations
>
> Name one advantage the trial versions have over the Free implementations
> that is relevant to learning the language.
Why so confrontational?
The free implementations require zero configuration and the LispWorks
IDE is way more mature and featureful than SLIME (graphical
inspectors, class browser, system browser, an extensible editor in
Common Lisp). You also get a full GUI toolkit that you can play
around with. I am sure the other commercial implementations are
comparable, although I have less experience with them.
"Commercial" does not imply "bad." If you've got a problem with
commercial software, you can always pick up the basics in a commerical
Lisp and then set up the free "equivalents" when you're more familiar
with Lisp.
On 2006-12-12 13:41:45 -0500, Chris Barts <··············@tznvy.pbz> said:
> Name one advantage the trial versions have over the Free implementations
> that is relevant to learning the language.
With LispWorks for example in order of importance to a newbie:
A fully configured lisp-aware editor (no fiddling with getting
emacs/slime configured)
Things that are supposed to just work via asdf and asdf-install
actually do without requiring the sorts of code tweaking that a
beginner will not be able to do.
Less critical but still quite useful:
A graphical function call browser (to understand more complex systems
that are loaded, say via asdf-install or from your tutorial)
A graphical class browser (to learn and better understand clos and clos
systems)
A graphical generic function browser (ditto)
A GUI toolkit that lets them learn lisp in the context of building
familiar GUI applications, not just console stuff.
Remember, we're talking about complete beginners here. If something
doesn't "just work" they will have zero ability to fix it. This is the
real learning advantage of the commercial free trial versions - things
"just work" without fiddling.
Chris Barts <··············@tznvy.pbz> writes:
> On Mon, 11 Dec 2006 00:47:47 -0500, Raffael Cavallaro wrote:
>
> >
> > The best environments for learning common lisp are the free trial
> > versions of the commercial implementations
>
> Name one advantage the trial versions have over the Free implementations
> that is relevant to learning the language.
One "click" out of the box usability with everything available. A
_huge_ advantage for "just" learning.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
In article <····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
>Let me put in my 2 cents, if anybody cares to listen - I don't even
>know if Ian Jackson is still reading.
Yes, I am ...
>Unfortunately:
>
>1. the best free versions of common lisp are not the best environments
>for *learning* common lisp.
Well, personally I'm not prepared to commit to a programming language
(or even a significant library) which is not Free Software. Obviously
this is a political rather than a technical criterion, and people may
disagree.
>The best documentation for learning common lisp is the freely available
>Practical Common Lisp by Peter Siebel [...]
I think the problem here isn't that it's not free (or not Free), but
that it's not brief.
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
Ian Jackson wrote:
> >Unfortunately:
> >
> >1. the best free versions of common lisp are not the best environments
> >for *learning* common lisp.
>
> Well, personally I'm not prepared to commit to a programming language
> (or even a significant library) which is not Free Software. Obviously
> this is a political rather than a technical criterion, and people may
> disagree.
To contradict an earlier statement about the c.l.l "community", this
kind of stubborn grasp on preconceived notions held by novices is what
most raises hackles on c.l.l, not that fact that you might have honest
difficulties.
The fact that you expect Lispers to have presented you with a "language
that is Free Software"---putting aside that a language is not software,
but an abstraction with *implementations* that are software, and that
Lisp far predates RMS's manifesto---is a problem with your
expectations, not with Lisp. And, after all, there are multiple Free
implementations of Common Lisp, and quite good ones.
The only way such admittedly political principles could present a
practical obstacle to learning the language is if you decide to let
them.
If you decide your political posturing should be allowed to impede your
intellectual growth, that is your problem, not ours, and forgive us for
not pitying the situation in which you have placed yourself.
From: Richard M Kreuter
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <87k60wzgdu.fsf@progn.net>
Ian Jackson <········@chiark.greenend.org.uk> writes:
> In article <····································@pasdespamsilvousplaitmaccom>,
> Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
>
>> The best documentation for learning common lisp is the freely
>> available Practical Common Lisp by Peter Siebel [...]
>
> I think the problem here isn't that it's not free (or not Free), but
> that it's not brief.
You keep repeating this point about the length of a tutorial, so it
must be important to you. Can you offer an upper bound on the length
(in printed pages, say) of document that you would have found
acceptable?
--
RmK
Ian Jackson wrote:
> I think the problem here isn't that it's not free (or not Free), but
> that it's not brief.
Yeah, I tried to learn General Relativity once, but I couldn't find an
introduction that was less than 10 pages, so I gave up. Then I found a
nice brief introduction to Unix sysadmin, and now I look after critical
production systems for a bank.
On 2006-12-12 16:18:43 -0500, Ian Jackson
<········@chiark.greenend.org.uk> said:
> Well, personally I'm not prepared to commit to a programming language
> (or even a significant library) which is not Free Software.
I think you miss a possibly subtle point - you don't need to commit to
the commercial implementation, just use the free trial version for long
enough to work through a tutorial (i.e., PCL) which should be no more
than a month. Then - or even in parallel - pick up sbcl, or clisp, or
any of the other excellent free implementations. Now you'll have enough
lisp-fu under your belt that when a problem crops up with slime, or
asdf-install, or some library you're trying to get to work with your
free implementation, you'll have no problem diagnosing the problem and
fixing it.
In case you're worried, you can configure the LispWorks editor to
behave pretty much just like emacs and slime so that transitioning to
that pair with, say sbcl, is invisible - I go back and forth between
the two regularly without a hitch.
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> I think you miss a possibly subtle point - you don't need to commit to
> the commercial implementation, just use the free trial version for long
> enough to work through a tutorial (i.e., PCL) which should be no more
> than a month.
I believe that PCL links to a nice pre-packaged emacs and lisp
combination. I don't remember having any problems getting slime and
lisp working on any of the platforms I've used it on.
I probably would have been faster working through PCL with LispWorks
but I didn't find it necessary by any means.
On 2006-12-13 12:05:05 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
> I probably would have been faster working through PCL with LispWorks
> but I didn't find it necessary by any means.
Indeed, one could work through PCL using just a terminal interface and
clisp or sbcl. But the OP's problem was when things went south on him -
being a newbie he didn't know how to fix them. These sort of
configuration issues simply don't happen nearly as often with the
commercial free trial editions, which is why working through PCL would
be, as you noted, faster and therefore interfere less with the job of
learning a new language, making the whole process easier.
Remember, we're talking about what's optimal here, not what's doable.
The only things stopping many from using the free trial editions are:
1. habit - they're used to the free version being the gold standard.
This isn't the case with common lisp.
2. misguided fear of lock-in - you can use the free trial version to
learn lisp, but then make any of the free lisps your lisp of choice
with a very easy transition - the free trial's I know of have editors
that work like emacs or can be easily configured to work like emacs.
3. politics - the political belief that only free software should be
used turns out to be a practical impediment to learning common lisp.
Use the politically "tainted" free trials to learn, then switch to a
free lisp for real work.
Finally, as to the commercial vendors, they're betting that some subset
of newcomers will find some feature of their commercial implementation
so appealing that they'll become paying customers. I think they're
correct in making this bet.
On 2006-12-13 13:03:14 -0500, Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> said:
> the free trial's I know of
ack! how did that apostrophe get in there! - sorry for the typo
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-13 12:05:05 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
>
> > I probably would have been faster working through PCL with LispWorks
> > but I didn't find it necessary by any means.
>
> Indeed, one could work through PCL using just a terminal interface and
> clisp or sbcl. But the OP's problem was when things went south on him -
> being a newbie he didn't know how to fix them. These sort of
> configuration issues simply don't happen nearly as often with the
> commercial free trial editions, which is why working through PCL would
> be, as you noted, faster and therefore interfere less with the job of
> learning a new language, making the whole process easier.
Looking through the OP, it does not seem that the problems had much
to do with SLIME or open-source lisps. In fact, the OP had a very
positive experience with SLIME. Most of the complaints centered on
a perceived lack of documentation that met his needs.
> Remember, we're talking about what's optimal here, not what's doable.
> The only things stopping many from using the free trial editions are:
>
> 1. habit - they're used to the free version being the gold standard.
> This isn't the case with common lisp.
>
> 2. misguided fear of lock-in - you can use the free trial version to
> learn lisp, but then make any of the free lisps your lisp of choice
> with a very easy transition - the free trial's I know of have editors
> that work like emacs or can be easily configured to work like emacs.
>
> 3. politics - the political belief that only free software should be
> used turns out to be a practical impediment to learning common lisp.
> Use the politically "tainted" free trials to learn, then switch to a
> free lisp for real work.
Well, I would also add:
4. As much as possible, you want to learn on the system you intend
to use, and start off doing "real work" with what you learn as soon
as possible.
5. Restrictions on the trial versions of commercial lisps are
problematic, especially when you don't know in advance what kind of
"heap size" you expect, or whether you might, possibly use that code
beyond the "personal and academic" use required by the license.
6. Accountability-Since I was using lisp for research, as much as
possible I wanted the option of wrapping up and shipping my entire
toolchain, source code, and data to any person with the human
subjects authorization to review my data.
I don't think fear of lock-in is unreasonable. A number of threads
on c.l.l discuss quirks and differences in implementation between
lisps. Furthermore, the LispWorks personal license strikes me as
having a potential for tainting code produced with it. What is
personal and academic one year, might become public and commercial
the next.
I will also argue with the conclusion of #3 because it has not been
shown that free software is a practical impediment to learning
common lisp, and some of the harsher restrictions on how commercial
software must be deployed certainly can be an impediment to
instruction.
On 2006-12-13 16:49:15 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
>
>> Remember, we're talking about what's optimal here, not what's doable.
>> The only things stopping many from using the free trial editions are:
>>
>> 1. habit - they're used to the free version being the gold standard.
>> This isn't the case with common lisp.
>>
>> 2. misguided fear of lock-in - you can use the free trial version to
>> learn lisp, but then make any of the free lisps your lisp of choice
>> with a very easy transition - the free trial's I know of have editors
>> that work like emacs or can be easily configured to work like emacs.
>>
>> 3. politics - the political belief that only free software should be
>> used turns out to be a practical impediment to learning common lisp.
>> Use the politically "tainted" free trials to learn, then switch to a
>> free lisp for real work.
>
> Well, I would also add:
> 4. As much as possible, you want to learn on the system you intend to
> use, and start off doing "real work" with what you learn as soon as
> possible.
No, you want to learn on an easy to use system that makes learning
easier. Children do not learn to read by picking up a copy of the New
York Times, they start with primers. The commercial free trials have
integrated, lisp aware editors, and most if not all of the
asdf-installable packages are known to work as-is with these commercial
implementations. That's two classes of hair-pulling - getting an
editor/lisp-server combination to work, getting asdf-installable
libraries to compile and load without error - that are pretty much
invisible if you wisely choose to *learn the language* on a free trial
edition of a commercial implementation.
>
> 5. Restrictions on the trial versions of commercial lisps are
> problematic, especially when you don't know in advance what kind of
> "heap size" you expect, or whether you might, possibly use that code
> beyond the "personal and academic" use required by the license.
Again, we're talking about learning, not producing usable code for
work. Learn the basics of the language first, the go off and do
something usable.
>
> 6. Accountability-Since I was using lisp for research, as much as
> possible I wanted the option of wrapping up and shipping my entire
> toolchain, source code, and data to any person with the human subjects
> authorization to review my data.
> I don't think fear of lock-in is unreasonable. A number of threads on
> c.l.l discuss quirks and differences in implementation between lisps.
> Furthermore, the LispWorks personal license strikes me as having a
> potential for tainting code produced with it. What is personal and
> academic one year, might become public and commercial the next.
Again, misses the point. Learn basics first, then do research. Don't
confuse your ultimate goals (doing reasearch, releasing commercial
software, programming lisp for paying clients) with the immediate goal
of *learning the language*.
>
> I will also argue with the conclusion of #3 because it has not been
> shown that free software is a practical impediment to learning common
> lisp, and some of the harsher restrictions on how commercial software
> must be deployed certainly can be an impediment to instruction.
Yes it has. "Showing" it can only consist of polling the experiences of
people learning the language. This isn't a theorem - it's a matter of
people's experiences of difficulty or ease of use. Several people here
have had the experience that things just work out of the box with the
Lispworks free trial edition, and that getting things to work with
several free lisps such as certain asdf-installable libraries, and
slime/emacs - the pair of which are completely unecessary in a
commercial lisp IDE - requires configuration which will be beyond the
abilities of total beginners.
This is all about separation of concerns. How you learn the language
has nothing to do with how you will use it when you've actually gotten
up to speed. So the process of learning should be made as easy as
possible, and the commercial IDEs make learning the language as easy as
possible.
As a meta-comment, it seems like your continued denial that people have
had the experience that it is easier to get things working out of the
box with one of the commercial free trials is motivated by something
other than beginners' experiences in this area - say, maybe #3 in my
post you quoted above?
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-13 16:49:15 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
> > Well, I would also add:
> > 4. As much as possible, you want to learn on the system you intend to
> > use, and start off doing "real work" with what you learn as soon as
> > possible.
>
> No, you want to learn on an easy to use system that makes learning
> easier. Children do not learn to read by picking up a copy of the New
> York Times, they start with primers.
Of course, we are not talking about children here in most cases. We
are talking about adults who (assuming fairly normal cognition) tend
to have limited time, and learn best when they can immediately
connect what they are learn into authentic practice. (And yes, this
is an empirical fact, I can dump a library on this subject if you
wish.) This is IMO one of the reasons why PCL is a great text
because it goes quickly from "Hello World" to basic and practical
data structures.
In addition, this isn't even true of children, who master basic
language syntax and massive quantities of vocabulary before the age
of five by participating in authentic practice and conversations
with adults and peers. (Again, another empirical fact, possibly even
better supported.) Even in basic language pedagogy they don't just
learn to read simple texts, but they learn to write them as well.
For adult learners of additional languages, again the most effective
method is immersion: forcing learners to read, talk, and listen in
the language even when uncomfortable.
Third, while it's certainly possible to argue that some features of
Allegro and LispWorks provide valuable pedagogical scaffolding for
the novice, this is a far cry from arguing that they are "primers."
You have to weigh the advantages of that scaffolding against the
possible disadvantage if Allegro and LispWorks are inauthentic
compared to the desired performance.
> The commercial free trials have
> integrated, lisp aware editors, and most if not all of the
> asdf-installable packages are known to work as-is with these commercial
> implementations. That's two classes of hair-pulling - getting an
> editor/lisp-server combination to work, getting asdf-installable
> libraries to compile and load without error - that are pretty much
> invisible if you wisely choose to *learn the language* on a free trial
> edition of a commercial implementation.
Well, two problems here:
First of all, out of almost a dozen FOSS editor/lisp combinations
I've tried, I've only had one case that involved even minor
hair-pulling. And this was on FreeBSD which often involved
hair-pulling due to mis-matched ports.
Second, neither asdf or other libraries, are required for studying
PCL. The few required libraries were made for the book, and
available on the book's website.
> > 5. Restrictions on the trial versions of commercial lisps are
> > problematic, especially when you don't know in advance what kind of
> > "heap size" you expect, or whether you might, possibly use that code
> > beyond the "personal and academic" use required by the license.
>
> Again, we're talking about learning, not producing usable code for
> work. Learn the basics of the language first, the go off and do
> something usable.
> ...
> Again, misses the point. Learn basics first, then do research. Don't
> confuse your ultimate goals (doing reasearch, releasing commercial
> software, programming lisp for paying clients) with the immediate goal
> of *learning the language*.
Oh, gawsh golly gee. I can't remember the last time I had the
luxury of learning something *before* I needed it, and when I do
have the luxury of learning something with lots of time, I rarely
find an opportunity to use it except in usenet discussions and
dinner conversations.
In most cases of real-life practice, proximal goals and distal goals
are not so cleanly separated. And to be honest, in many cases they
shouldn't be. Having an itch that sits somewhere in the middle
layers of Maslow's hierarchy can be a powerful motivator to get
something done.
So what were my goals in learning lisp? I had this huge chunk of
data that needed to be processed, my attempts at creating an
abstract model for that data processing in python had run into a
mess of objects and functions. As I was pondering this problem I saw
an article on lisp macros, and then I realized that this could
ultimately save me enough work to make learning lisp worthwhile.
So there I go through and think about the criteria of selection from
the previous post:
6: Accountability: Can I send my entire toolchain to another person
who can check my results? This excludes the Commercial Lisps.
5: License: Can I ethically use the software for this work? As I was
being paid (through an NSF grant) it was arguably not personal or
academic. In addition there was always the possibility that the
project could go commercial in the future, in which case my code may
or may not go with it. My reading of the license for ACL and
LispWorks raised enough caution flags to look elsewhere.
4: Which lisp will I ultimately use? Well 4 & 5 suggested that a
free lisp like SBCL is more likely than ACL or LispWorks. In
addition I was already using Emacs with AucTeX.
The brilliant thing about lisp and PCL was that I was able to get up
and running practically crunching data after about 16 hours. I'm not
saying that my early scripts were brilliant, just that it wasn't
that hard to rebuild in lisp what I had previously built in python.
> > I will also argue with the conclusion of #3 because it has not been
> > shown that free software is a practical impediment to learning common
> > lisp, and some of the harsher restrictions on how commercial software
> > must be deployed certainly can be an impediment to instruction.
>
> Yes it has. "Showing" it can only consist of polling the experiences of
> people learning the language. This isn't a theorem - it's a matter of
> people's experiences of difficulty or ease of use.
Well, actually it's an empirical hypothesis. And how you "show" this
is by running a double-blind study minimizing the variables between
groups showing proximal and distal performance differences. Now
perhaps it's just that adult learning is my personal bailiwick, and
an area where personal intuitions and anecdotes are often
misleading, but I'm not obliged to accept claims to pedagogical
superiority based on methodological handwaving.
> Several people here
> have had the experience that things just work out of the box with the
> Lispworks free trial edition, and that getting things to work with
> several free lisps such as certain asdf-installable libraries, and
> slime/emacs - the pair of which are completely unecessary in a
> commercial lisp IDE - requires configuration which will be beyond the
> abilities of total beginners.
Well, my experience is that most lisps and slime are well-packaged
and require minimal configuration. (Four operating systems, I like
to play with about 2-3 different lisps.)
> This is all about separation of concerns. How you learn the language
> has nothing to do with how you will use it when you've actually gotten
> up to speed.
The benefits of "separation of concerns" for adult learners is not
as strong as you might think. For many adult learners authenticity
is extremely important, and "separation of concerns" is a logistical
impossibility in many situations.
> As a meta-comment, it seems like your continued denial that people have
> had the experience that it is easier to get things working out of the
> box with one of the commercial free trials is motivated by something
> other than beginners' experiences in this area - say, maybe #3 in my
> post you quoted above?
I've not denied that some people have had problems installing slime
and lisp. I have called into question your claims as to the
pedagogical superiority of commercial lisp IDEs, and your continued
denial that many lisp learners have other concerns that make the
choice of a free lisp optimal.
On 2006-12-13 20:27:17 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
> I've not denied that some people have had problems installing slime and lisp.
A problem that simply cannot exist with a lisp that comes fully
configured with a lisp aware editor.
> I have called into question your claims as to the pedagogical
> superiority of commercial lisp IDEs, and your continued denial that
> many lisp learners have other concerns that make the choice of a free
> lisp optimal.
We're talking about people who don't even know the basics of the
langauge yet, and somehow they have "other concerns" about their lisp
system. If a beginner is hung up on "authenticity" then he will get the
"authentic" misery of having to reconfigure a system most of which is
written in a language he doesn't know yet.
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-13 20:27:17 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
>
> > I've not denied that some people have had problems installing slime and
> > lisp.
>
> A problem that simply cannot exist with a lisp that comes fully
> configured with a lisp aware editor.
Well, yes. The other side of the coin is that in my experience
emacs-slime and free lisps are easy installs. In most cases, if you
can install LispWorks on your system, you should have the necessary
skills to install sbcl, emacs and slime. In addition, the skills
needed here _have little to do with lisp. Let's compare:
Lisp-in-a-box for WinXP: Download and run two executable installer
files.
Lisp-in-a-box for Linux: Download and run a script.
Aquamacs on OS X: Download a disk image. Move the application
package to the Applications folder. Slime is included.
OpenMCL on OS X: Download an archive file. Extract that archive in a
convenient location.
SBCL on multiple platforms: Download an archive file. Extract that
archive file. Run an installer script.
LispWorks on OS X: Download two disk images. Run the installer
programs.
Slime on most Linux and FreeBSD: Install through the
platform-specific package management system. Such as apt, rpm or
ports.
The only part that involves lisp is the following three lines of
code that need to be pasted into a .emacs file.
(setq inferior-lisp-program "/usr/local/bin/sbcl")
(require 'slime)
(slime-setup)
> We're talking about people who don't even know the basics of the
> langauge yet, and somehow they have "other concerns" about their lisp
> system. If a beginner is hung up on "authenticity" then he will get the
> "authentic" misery of having to reconfigure a system most of which is
> written in a language he doesn't know yet.
Well yes, most adults learn a technology not for the sake of the
technology because they have some kind of need. They learn perl
because they need to write or edit CGI scripts. They learn VBA
because they need to script something in Microsoft Office. They
learn InDesign because they were hired to edit a journal. They learn
LaTeX to write a dissertation. They learn SPSS, SAS or R because
they need to crunch data. My first encounter with elisp came because
I was working on a helpdesk that used emacs to format and dump email
messages into their problem tracking system.
So yes, people who design learning and human performance
environments recognize that most learning is both goal and
context-driven.
But here, you are just engaging in FUD. I have some spare time this
week to try out sbcl 1.0, clisp, LispWorks and an update to slime
and have not experienced any "reconfiguration misery." The
reconfiguration has simply involved:
(setq inferior-lisp-program "/usr/local/bin/sbcl")
How I wish the problems that do give me misery could be solved so
simply.
On 2006-12-14 13:02:52 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
> Aquamacs on OS X: Download a disk image. Move the application package
> to the Applications folder. Slime is included.
There are of course more steps:
> SBCL on multiple platforms: Download an archive file. Extract that
> archive file.
open a terminal to ...
> Run an installer script.
-find or create a .emacs file
-add a line to it specify your inferior lisp (how are lisp newbies
supposed to know how to do this - they know no lisp, but they somehow
do know emacs lisp?)
-launch Aquamacs then type meta-x slime (again - they know this how?)
-Scratch head in bemusement later on when a message is displayed "lost
connection to swank server"
Contrast this with the Lispworks trial:
no installer script to run - just double click an installer.
no .emacs file to create or edit
no specification of an inferior lisp
no connecting to a lisp server - the editor and listener and the lisp
are just different windows in the same process
no getting disconnected from your inferior lisp
IOW, it just works.
Newbies need stuff that just works, not stuff that feels "authentic"
unless they also want "authentic" configuration hassles.
Raffael Cavallaro wrote:
> On 2006-12-14 13:02:52 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
[...]
> -find or create a .emacs file
> -add a line to it specify your inferior lisp (how are lisp newbies
> supposed to know how to do this - they know no lisp, but they somehow
> do know emacs lisp?)
> -launch Aquamacs then type meta-x slime (again - they know this how?)
The SLIME manual? You don't need to know a whole lot of Lisp in order
to copy (setq inferior-lisp-program "/usr/local/bin/sbcl") out of the
manual.
I've got nothing against Lispworks in particular or commercial software
in general, but the installation process for SLIME + SBCL on the Mac
just isn't going to be that tough a row for a newbie to hoe. Back when
I was getting started, it took me five minutes.
Besides, it's not like there are choices besides SLIME on Mac OS
X/Intel.
Cheers,
Pillsy
Raffael Cavallaro wrote:
<snipped>
> Newbies need stuff that just works,
I would take this up with Kenny Tilton(KT) who elsethread
said that if people just didn't have the time to invest in
the learning curve then they should just walk away.
If you are going to take issue "because of the newbies",
then some of the regs here must *really* piss you off :-)
> not stuff that feels "authentic"
> unless they also want "authentic" configuration hassles.
Maybe they do (need stuff that just works, I mean).
However, on this ng, the opinions expressed are usually
along the lines of:
1. You're too cheapskate to *pay* for a decent lisp.
2. Commercial software makes you 3 times as productive
as the FOSS stuff (KT).
3. Stallman is a raving lunatic.
4. Free software is hurting quality commercial software.
5. People who use the free lisps are fools.
6. If you're too stupid to understand why you need a
commercial lisp, then perhaps VB is more to your taste?
... and various other insults.
IOW, all the arguments are ideological.
So, maybe newbies *need* stuff that just works, but the
abuse given here is *any* time FOSS comes up, not just
in context to newbies.
Hell, I even remember seeing someone dismiss FOSS as
"communist". Surely you don't expect any rational person
to take your argument seriously if it is constantly
peppered with rage, abuse and insults?
When you (personally) and you all (the ng regulars)
approve of flaming a newcomer purely because they ask
which free lisp to start with, don't act surprised when
they get turned off from the commercial offerings forever.
Constantly banging your drum and running down the opposition
(the FOSS lisp implementations) is the one method guaranteed
to send the newbie running to the opposition (FOSS). If you
want the newbie to see how good the commercial offering is,
pointing him to the trial versions without hurling vitriol
at the FOSS lisps is surely better than trying to win him
over on ideological grounds (which he may not be receptive to
anyway and which have a shaky foundation at best).
If he cared at all about ideology, he'd have already picked
the lisp with the licence that most closely matches his own
views. If Gratis matters to him, then he would be receptive
to using the commercial trial versions. If someone says they
don't want to use a commercial trial version, then it's a
good bet that Gratis is not foremost on his mind.
goose,
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2irgdcl0x.fsf@bertrand.local>
"goose" <····@webmail.co.za> writes:
>> not stuff that feels "authentic"
>> unless they also want "authentic" configuration hassles.
>
> Maybe they do (need stuff that just works, I mean).
>
> However, on this ng, the opinions expressed are usually
> along the lines of:
> 1. You're too cheapskate to *pay* for a decent lisp.
> 2. Commercial software makes you 3 times as productive
> as the FOSS stuff (KT).
> 3. Stallman is a raving lunatic.
> 4. Free software is hurting quality commercial software.
> 5. People who use the free lisps are fools.
> 6. If you're too stupid to understand why you need a
> commercial lisp, then perhaps VB is more to your taste?
>
> ... and various other insults.
Insults? 5 and 6 are insults; what's wrong with the rest?
> IOW, all the arguments are ideological.
And what do you call your belief that people shouldn't pay for
software, even when paying will get you superior software?
> Hell, I even remember seeing someone dismiss FOSS as
> "communist". Surely you don't expect any rational person
> to take your argument seriously if it is constantly
> peppered with rage, abuse and insults?
You don't see an element of communism in Stallman's ideas?
> When you (personally) and you all (the ng regulars)
> approve of flaming a newcomer purely because they ask
> which free lisp to start with, don't act surprised when
> they get turned off from the commercial offerings forever.
>
> Constantly banging your drum and running down the opposition
> (the FOSS lisp implementations) is the one method guaranteed
> to send the newbie running to the opposition (FOSS). If you
> want the newbie to see how good the commercial offering is,
> pointing him to the trial versions without hurling vitriol
> at the FOSS lisps is surely better than trying to win him
> over on ideological grounds (which he may not be receptive to
> anyway and which have a shaky foundation at best).
I don't think that's true at all. Many people who use "freedom
software" (hehe) might never even bother to look at the commercial
environments. It's a good thing when someone points out that the free
versions are hardly the best example of what Lisp development can be.
I think you'd have to be pretty irrational to decide to ignore
commercial Lisps because someone on a newsgroup has told you that
they're better than the "free" implementations.
> If someone says they
> don't want to use a commercial trial version, then it's a
> good bet that Gratis is not foremost on his mind.
What is it then? RMS's utopian vision for the future, where the job
of programmer is reduced to providing support and everyone cheerfully
uses crappy software because of the warm fuzzy feeling they get inside
and the bright green glow of righteousness emitted by their monitors?
Bill Atkins wrote:
> "goose" <····@webmail.co.za> writes:
>
> >> not stuff that feels "authentic"
> >> unless they also want "authentic" configuration hassles.
> >
> > Maybe they do (need stuff that just works, I mean).
> >
> > However, on this ng, the opinions expressed are usually
> > along the lines of:
> > 1. You're too cheapskate to *pay* for a decent lisp.
> > 2. Commercial software makes you 3 times as productive
> > as the FOSS stuff (KT).
> > 3. Stallman is a raving lunatic.
> > 4. Free software is hurting quality commercial software.
> > 5. People who use the free lisps are fools.
> > 6. If you're too stupid to understand why you need a
> > commercial lisp, then perhaps VB is more to your taste?
> >
> > ... and various other insults.
>
> Insults? 5 and 6 are insults; what's wrong with the rest?
#1 assumes that all developers make more than $1000 p/month (untrue).
#2 is is just the normal vitriol from KT (his words were something to
the effect
of ("A commercial lisp, by virtue of being commercial, must be 3x as
productive
as any free lisp" - an insult to anyones intelligence if he actually
expects them
to believe that).
#3 presumes that the person asking is abviously aligned with with
raving lunatic (or else why bring it up).
#4 .... well maybe this is only stupid, not insulting :-).
>
> > IOW, all the arguments are ideological.
>
> And what do you call your belief that people shouldn't pay for
Whoa there cowboy - your biased-ness is getting ahead of you. Where
did I say or align myself with that belief?
> software, even when paying will get you superior software?
That's my point, really; you've done a lovely job of displaying the
knee-jerk reaction I tried to explain. All I did was post some
criticism
of the manner in which some of the regs behave when the issue of
FOSS comes up, and you've already got the "them and me" attitude.
I did not say that FOSS was superior, nor did I say that I believe
people shouldn't pay for software.
I could not have put it better than you have; any mention of FOSS
follows with some abuse, insult and now (see above) strawman
arguments.
(You've obviously got that argument prepared and waiting).
>
> > Hell, I even remember seeing someone dismiss FOSS as
> > "communist". Surely you don't expect any rational person
> > to take your argument seriously if it is constantly
> > peppered with rage, abuse and insults?
>
> You don't see an element of communism in Stallman's ideas?
I see an element of communism in most things; I believe FOSS
tends more towards socialism (like some european states) that
communism.
>
> > When you (personally) and you all (the ng regulars)
> > approve of flaming a newcomer purely because they ask
> > which free lisp to start with, don't act surprised when
> > they get turned off from the commercial offerings forever.
> >
> > Constantly banging your drum and running down the opposition
> > (the FOSS lisp implementations) is the one method guaranteed
> > to send the newbie running to the opposition (FOSS). If you
> > want the newbie to see how good the commercial offering is,
> > pointing him to the trial versions without hurling vitriol
> > at the FOSS lisps is surely better than trying to win him
> > over on ideological grounds (which he may not be receptive to
> > anyway and which have a shaky foundation at best).
>
> I don't think that's true at all. Many people who use "freedom
> software" (hehe) might never even bother to look at the commercial
> environments. It's a good thing when someone points out that the free
> versions are hardly the best example of what Lisp development can be.
Hey, I hear you! Please, *point* *out* *all* the relevant alternatives,
but
leave your ideology and/or insecurity over FOSS out of it.
> I think you'd have to be pretty irrational to decide to ignore
> commercial Lisps because someone on a newsgroup has told you that
> they're better than the "free" implementations.
No; someone on a newsgroup has told me that I'd have to be stupid
to use free software. Refusing this persons advice is the only option
available to a rational being - no one takes advice from anyone
who is openly hostile to them - the advice may be bad.
>
> > If someone says they
> > don't want to use a commercial trial version, then it's a
> > good bet that Gratis is not foremost on his mind.
>
> What is it then? RMS's utopian vision for the future, where the job
> of programmer is reduced to providing support and everyone cheerfully
> uses crappy software because of the warm fuzzy feeling they get inside
> and the bright green glow of righteousness emitted by their monitors?
I'm not going to discuss your job insecurities about being reduced
to a lower level of work than you are at now; thats a personal thing
that everyone has to deal with themselves. What I *would* like to know
is why you seem to be under the impression that anyone who mentions
FOSS is automatically against proprietry software?
I'm certainly not - my only crime was to point out that the regs
here post like they are insecure over competition.
goose,
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m264caih7o.fsf@bertrand.local>
"goose" <····@webmail.co.za> writes:
> Bill Atkins wrote:
>> "goose" <····@webmail.co.za> writes:
>>
>> >> not stuff that feels "authentic"
>> >> unless they also want "authentic" configuration hassles.
>> >
>> > Maybe they do (need stuff that just works, I mean).
>> >
>> > However, on this ng, the opinions expressed are usually
>> > along the lines of:
>> > 1. You're too cheapskate to *pay* for a decent lisp.
>> > 2. Commercial software makes you 3 times as productive
>> > as the FOSS stuff (KT).
>> > 3. Stallman is a raving lunatic.
>> > 4. Free software is hurting quality commercial software.
>> > 5. People who use the free lisps are fools.
>> > 6. If you're too stupid to understand why you need a
>> > commercial lisp, then perhaps VB is more to your taste?
>> >
>> > ... and various other insults.
>>
>> Insults? 5 and 6 are insults; what's wrong with the rest?
>
> #1 assumes that all developers make more than $1000 p/month (untrue).
Where do you see that assumption?
> #2 is is just the normal vitriol from KT (his words were something to
> the effect
> of ("A commercial lisp, by virtue of being commercial, must be 3x as
> productive
> as any free lisp" - an insult to anyones intelligence if he actually
> expects them
> to believe that).
It may not be "by virtue of its being commercial," but commercial
IDE's are way more productive than SLIME is. If they were as
equivalent as you seem to think, no one would be paying for commercial
Lisps. A good inspector and debugger alone will go a long way towards
"3x as productive."
> #4 .... well maybe this is only stupid, not insulting :-).
Let's not go there again...
>> I don't think that's true at all. Many people who use "freedom
>> software" (hehe) might never even bother to look at the commercial
>> environments. It's a good thing when someone points out that the free
>> versions are hardly the best example of what Lisp development can be.
>
> Hey, I hear you! Please, *point* *out* *all* the relevant alternatives,
> but
> leave your ideology and/or insecurity over FOSS out of it.
Well, in a situation where the commerical software clearly beats the
"FOSS" software, what besides ideology would keep a free-software user
where he or she is? And if that's the case, how can you discuss
alternatives without involving ideology?
>> I think you'd have to be pretty irrational to decide to ignore
>> commercial Lisps because someone on a newsgroup has told you that
>> they're better than the "free" implementations.
>
> No; someone on a newsgroup has told me that I'd have to be stupid
> to use free software. Refusing this persons advice is the only option
> available to a rational being - no one takes advice from anyone
> who is openly hostile to them - the advice may be bad.
Silly.
>> > If someone says they
>> > don't want to use a commercial trial version, then it's a
>> > good bet that Gratis is not foremost on his mind.
>>
>> What is it then? RMS's utopian vision for the future, where the job
>> of programmer is reduced to providing support and everyone cheerfully
>> uses crappy software because of the warm fuzzy feeling they get inside
>> and the bright green glow of righteousness emitted by their monitors?
>
> I'm not going to discuss your job insecurities about being reduced
> to a lower level of work than you are at now; thats a personal thing
> that everyone has to deal with themselves.
No, it's a social issue that arises from people believing they can
give work away for free without any negative economic consequences.
> What I *would* like to know
> is why you seem to be under the impression that anyone who mentions
> FOSS is automatically against proprietry software?
>
> I'm certainly not - my only crime was to point out that the regs
> here post like they are insecure over competition.
Fair enough. I'd seen your name come up in a lot of the OSS
v. commercial software debates here and I'd noticed that you seemed to
be championing free software pretty resolutely. However, I don't know
that you are against proprietary software, and it was foolish of me to
assume that.
In article <··············@bertrand.local>,
Bill Atkins <····························@gmail.com> wrote:
> "goose" <····@webmail.co.za> writes:
> > If someone says they
> > don't want to use a commercial trial version, then it's a
> > good bet that Gratis is not foremost on his mind.
>
> What is it then? RMS's utopian vision for the future, where the job
> of programmer is reduced to providing support and everyone cheerfully
> uses crappy software because of the warm fuzzy feeling they get inside
> and the bright green glow of righteousness emitted by their monitors?
Well, I don't know. Could it be because some of us look at the
license restrictions of commercial trial versions and find them to
be incompatible with what we want to do with lisp?
I do not believe that the trial versions can be ethically or safely
used on any code that will be used for published research, or
possibly incorporated into services or products in a later
generation.
Trial versions are technically limited in terms of time and memory
size. Nor can you repackage their runtimes or build executables.
It's my experience that Stallman-style utopians are a minority among
people who use FOSS software. Most FOSS users are making pragmatic
decisions about what can be done using various systems.
From: Greg Menke
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m38xh96t22.fsf@athena.pienet>
Kirk Sluder <····@nospam.jobsluder.net> writes:
> In article <··············@bertrand.local>,
> Bill Atkins <····························@gmail.com> wrote:
>
> > "goose" <····@webmail.co.za> writes:
> > > If someone says they
> > > don't want to use a commercial trial version, then it's a
> > > good bet that Gratis is not foremost on his mind.
> >
> > What is it then? RMS's utopian vision for the future, where the job
> > of programmer is reduced to providing support and everyone cheerfully
> > uses crappy software because of the warm fuzzy feeling they get inside
> > and the bright green glow of righteousness emitted by their monitors?
>
> Well, I don't know. Could it be because some of us look at the
> license restrictions of commercial trial versions and find them to
> be incompatible with what we want to do with lisp?
>
> I do not believe that the trial versions can be ethically or safely
> used on any code that will be used for published research, or
> possibly incorporated into services or products in a later
> generation.
>
> Trial versions are technically limited in terms of time and memory
> size. Nor can you repackage their runtimes or build executables.
If the constraints of trial versions of the software is an impediment
then the software is being misused. The idea of the trial version is to
see if its going to work for you, then if so, pony up for the real thing
and if not then go elsewhere. Once you're ready for real work, then its
time to spend real money on real tools.
If you need to ease the constraints on the trial version to properly
test your application, then the vendor(s) can be contacted and
arrangements made.
But if whats desired is something for nothing, then theres plenty of
open source software to try.
Gregm
Greg Menke wrote:
> Kirk Sluder <····@nospam.jobsluder.net> writes:
[...]
> > Well, I don't know. Could it be because some of us look at the
> > license restrictions of commercial trial versions and find them to
> > be incompatible with what we want to do with lisp?
> > I do not believe that the trial versions can be ethically or safely
> > used on any code that will be used for published research, or
> > possibly incorporated into services or products in a later
> > generation.
> > Trial versions are technically limited in terms of time and memory
> > size. Nor can you repackage their runtimes or build executables.
> If the constraints of trial versions of the software is an impediment
> then the software is being misused.
Precisely. But in order to properly evaluate Common Lisp *as a
language*, it's not unlikely that a new user would like to actually use
it on a not-entirely-trivial project to see how it goes. This means
that they are not only likely to brush up against the crippled runtime,
but also against license restrictions.
FOSS Lisp implementations obviously don't have that problem.
The trial versions of the commercial Lisps aren't necessarily the best
thing for people who want to see whether Lisp is the thing for them,
and I think a lot of the rhetoric about how they're worth every penny
because of the productivity enhancements they provide is likely
misplaced in this particular conversation.
Cheers,
Pillsy
From: Greg Menke
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m3tzzwet6o.fsf@athena.pienet>
"Pillsy" <·········@gmail.com> writes:
> Greg Menke wrote:
>
> > Kirk Sluder <····@nospam.jobsluder.net> writes:
> [...]
> > > Well, I don't know. Could it be because some of us look at the
> > > license restrictions of commercial trial versions and find them to
> > > be incompatible with what we want to do with lisp?
>
> > > I do not believe that the trial versions can be ethically or safely
> > > used on any code that will be used for published research, or
> > > possibly incorporated into services or products in a later
> > > generation.
>
> > > Trial versions are technically limited in terms of time and memory
> > > size. Nor can you repackage their runtimes or build executables.
>
> > If the constraints of trial versions of the software is an impediment
> > then the software is being misused.
>
> Precisely. But in order to properly evaluate Common Lisp *as a
> language*, it's not unlikely that a new user would like to actually use
> it on a not-entirely-trivial project to see how it goes. This means
> that they are not only likely to brush up against the crippled runtime,
> but also against license restrictions.
True, but then the prospective user is entirely free to negiotiate
something suitable with one of the vendors. But really, none of the
commercial Lisps are all that expensive. They aren't cheap, but next to
something like tooling up a garage machine shop to even explore a
concept, its chump change. Nickel and Dimeing the cost of tools is a
common way to avoid committing to a task.
I've bought 2 versions of Lispworks by bartering my labor with a
customer because it gave me a leg up making fancier applications with
Common Lisp- worth every penny. I'm hoping next year's budget at work
will let me get a copy of Lispworks 5- the upgrades are worth it IMHO.
Which isn't to say the open source Lisps aren't useful, I prefer the
integration and tools that Lispworks gives me and use the open source
stuff for cross-platform scripting and fancy calculator sorts of work.
Gregm
Greg Menke wrote:
> "Pillsy" <·········@gmail.com> writes:
[...]
> > Precisely. But in order to properly evaluate Common Lisp *as a
> > language*, it's not unlikely that a new user would like to actually use
> > it on a not-entirely-trivial project to see how it goes. This means
> > that they are not only likely to brush up against the crippled runtime,
> > but also against license restrictions.
> True, but then the prospective user is entirely free to negiotiate
> something suitable with one of the vendors.
Sure. And for some projects and users that might be the perfect option.
For others, it's open source tools.
> But really, none of the commercial Lisps are all that expensive. They
> aren't cheap, but next to something like tooling up a garage machine
> shop to even explore a concept, its chump change.
They cost what professional software costs. For a professional or a
serious hobbyist, they're quite reasonable. But they're a pretty big
buy-in for someone who's unsure if Common Lisp works the way their
brain does. Especially for those of us who are, say, young academics
without extensive grant funding. :)
[...]
> Which isn't to say the open source Lisps aren't useful, I prefer the
> integration and tools that Lispworks gives me and use the open source
> stuff for cross-platform scripting and fancy calculator sorts of work.
I use SLIME + SBCL on a daily basis, and it's pretty nice. It's
distinctly better than some professional, commercial packages I've
used. Haven't used LW yet. At some point, I'll take it for a spin and
decide if it merits the cash.
Cheers,
Pillsy
From: Greg Menke
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m3odq4crmr.fsf@athena.pienet>
"Pillsy" <·········@gmail.com> writes:
> Greg Menke wrote:
>
> > But really, none of the commercial Lisps are all that expensive. They
> > aren't cheap, but next to something like tooling up a garage machine
> > shop to even explore a concept, its chump change.
>
> They cost what professional software costs. For a professional or a
> serious hobbyist, they're quite reasonable. But they're a pretty big
> buy-in for someone who's unsure if Common Lisp works the way their
> brain does. Especially for those of us who are, say, young academics
> without extensive grant funding. :)
I don't buy the argument that a thousand $ or so is unobtainable by
young academics. Its easy enough to spend room & board money exploring
designs for bongs, the same money could go to a commercial Lisp if the
student is so inclined. Theres all kinds of ways to earn money or
barter work if the desire is there.
I did the underfunded student gig too- and despite the bong research, I
managed to buy a commercial copy of Skona Brittain's Lisp (I forget the
dialect at the moment), which was a considerable upgrade from Interlisp
on my Atari 800 and cost pretty real $$ back then.
> I use SLIME + SBCL on a daily basis, and it's pretty nice. It's
> distinctly better than some professional, commercial packages I've
> used. Haven't used LW yet. At some point, I'll take it for a spin and
> decide if it merits the cash.
I never got the hang of SLIME myself, I do CMUCL or CLISP when doing
something in Lispworks isn't feasable.
Gregm
Greg Menke wrote:
> "Pillsy" <·········@gmail.com> writes:
[...]
> > They cost what professional software costs. For a professional or a
> > serious hobbyist, they're quite reasonable. But they're a pretty big
> > buy-in for someone who's unsure if Common Lisp works the way their
> > brain does. Especially for those of us who are, say, young academics
> > without extensive grant funding. :)
> I don't buy the argument that a thousand $ or so is unobtainable by
> young academics.
Not unobtainable. Just a big enough investment to justify a bunch of
looking prior to leaping.
'Course, a student can probably afford to sink $100 into a student
edition of ACL which is no doubt a good environment for learning, at
least on Win32 and Linux.
> Theres all kinds of ways to earn money or barter work if the desire is there.
Sure, but the kinds of work you'd be doing as a student, we're talking
50 to 100 hours before you've made enough for your own copy of
LispWorks. You can get a helluva lot done in 50 to 100 hours with the
OSS Lisp tools.
> > I use SLIME + SBCL on a daily basis, and it's pretty nice. It's
> > distinctly better than some professional, commercial packages I've
> > used. Haven't used LW yet. At some point, I'll take it for a spin and
> > decide if it merits the cash.
> I never got the hang of SLIME myself, I do CMUCL or CLISP when doing
> something in Lispworks isn't feasable.
Well, I'd been using Emacs for many years before stumbling across
Common Lisp, so Slime struck me as pretty natural.
Cheers,
Pillsy
Greg Menke wrote:
> I don't buy the argument that a thousand $ or so is unobtainable by
> young academics.
Fortunately you don't have to. As I'm constantly being reminded in this
ng,
in your country (whether US or EU) 1000USD is next to nothing - a
weeks
worth of income, right?
In *my* country that's equivalent to a student board for over a year.
It is, in a very real sense, unobtainable. Sorry; thats weak currencies
for you.
goose,
In article <··············@athena.pienet>,
Greg Menke <·············@toadmail.com> wrote:
> I don't buy the argument that a thousand $ or so is unobtainable by
> young academics. Its easy enough to spend room & board money exploring
> designs for bongs, the same money could go to a commercial Lisp if the
> student is so inclined. Theres all kinds of ways to earn money or
> barter work if the desire is there.
In the competition with other needs though, the purchase of a
commercial lisp has never been a high enough priority compared to,
say, conference expenses, room and board, or having an emergency
fund to fix the old car when it breaks down.
And another issue is, why should I hustle for the cash to buy a
commercial lisp when a few hours with a free lisp convinced me that
it would do everything I needed?
> Gregm
From: Greg Menke
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m3tzzvioec.fsf@athena.pienet>
Kirk Sluder <····@nospam.jobsluder.net> writes:
> In article <··············@athena.pienet>,
> Greg Menke <·············@toadmail.com> wrote:
> > I don't buy the argument that a thousand $ or so is unobtainable by
> > young academics. Its easy enough to spend room & board money exploring
> > designs for bongs, the same money could go to a commercial Lisp if the
> > student is so inclined. Theres all kinds of ways to earn money or
> > barter work if the desire is there.
>
> In the competition with other needs though, the purchase of a
> commercial lisp has never been a high enough priority compared to,
> say, conference expenses, room and board, or having an emergency
> fund to fix the old car when it breaks down.
>
> And another issue is, why should I hustle for the cash to buy a
> commercial lisp when a few hours with a free lisp convinced me that
> it would do everything I needed?
>
I really don't see what the issue is. If open source Lisps do what you
need then theres no problem. If they don't, then there is a motivation
for one of the commercial Lisps that provides the necessary
functionality. It is true that the commercial Lisps over many features
that make Lisp easier to use- but its your money and your time, expend
both as you see fit.
Gregm
In article <··············@athena.pienet>,
Greg Menke <·············@toadmail.com> wrote:
> Kirk Sluder <····@nospam.jobsluder.net> writes:
> > > Well, I don't know. Could it be because some of us look at the
> > license restrictions of commercial trial versions and find them to
> > be incompatible with what we want to do with lisp?
.....
> If the constraints of trial versions of the software is an impediment
> then the software is being misused. The idea of the trial version is to
> see if its going to work for you, then if so, pony up for the real thing
> and if not then go elsewhere. Once you're ready for real work, then its
> time to spend real money on real tools.
FOSS software isn't "real tools?"
> If you need to ease the constraints on the trial version to properly
> test your application, then the vendor(s) can be contacted and
> arrangements made.
>
> But if whats desired is something for nothing, then theres plenty of
> open source software to try.
>
> Gregm
Exactly my point. Most often FOSS software is chosen not because of
some political commitment to RMS, but for pragmatic reasons that
pre-dated RMS's contributions.
From: Greg Menke
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m3odq4eswp.fsf@athena.pienet>
Kirk Sluder <····@nospam.jobsluder.net> writes:
> In article <··············@athena.pienet>,
> Greg Menke <·············@toadmail.com> wrote:
>
> > Kirk Sluder <····@nospam.jobsluder.net> writes:
> > > > Well, I don't know. Could it be because some of us look at the
> > > license restrictions of commercial trial versions and find them to
> > > be incompatible with what we want to do with lisp?
>
> .....
>
> > If the constraints of trial versions of the software is an impediment
> > then the software is being misused. The idea of the trial version is to
> > see if its going to work for you, then if so, pony up for the real thing
> > and if not then go elsewhere. Once you're ready for real work, then its
> > time to spend real money on real tools.
>
> FOSS software isn't "real tools?"
A little hyperbole on my part, sorry. The point I was trying to make
was that when you're serious about doing something then its time to tool
up and get on with it- when open source tools work, thats fine- if
commerical, then buy them. Handwringing about the constraints of trial
versions of software just wastes time.
>
> Exactly my point. Most often FOSS software is chosen not because of
> some political commitment to RMS, but for pragmatic reasons that
> pre-dated RMS's contributions.
I agree. I have yet to meet any open source user who is anything but
pragmatic its selection, modulo disgust with Microsoft. Aside from
Firefox/Mozilla, most of the open source users I know use it on OS X.
Gregm
In article <··············@athena.pienet>,
Greg Menke <·············@toadmail.com> wrote:
> A little hyperbole on my part, sorry. The point I was trying to make
> was that when you're serious about doing something then its time to tool
> up and get on with it- when open source tools work, thats fine- if
> commerical, then buy them. Handwringing about the constraints of trial
> versions of software just wastes time.
Well, I think we mostly agree here. However, same of the history of
this thread was focused on pushing trial versions of software onto
people starting off in lisp regardless of those constraints.
Personally, I take licensing issues seriously in picking tools. What
you pay for with Allegro and LispWorks is not just additional
features, but a license to create and redistribute derivative
software tools. For me, that privilege is currently prohibitively
expensive compared to FOSS lisps. If my needs and abilities change,
then I can rethink that equation.
> Gregm
On 2006-12-15 17:24:00 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
> However, same of the history of this thread was focused on pushing
> trial versions of software onto people starting off in lisp regardless
> of those constraints.
There are no "constraints" on newbies just starting to learn. They
don't know how to walk yet - they shouldn't be deluding themselves that
there are "constraints" on what kind of running shoes they wear to
crawl around in. They will save themselves pain by learning on an
implementation that just works right out of the box.
p.s. exhuming dead discussions is bad usenetiquette
From: Cor Gest
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <87fybgtlej.fsf@atthis.clsnet.nl>
While amateurs discuss the merits of the "Brand-of-tools", artists just
grab a sharpened piece of steel and a make work of art.
Cor
--
The biggest problem LISP has is that it does not apeal to dumb people
If this failed to satisfy you try reading the HyperSpec or man frig
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Read Mailpolicy before mailing http://www.clsnet.nl/mail.html
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <HEMgh.1047$LY.389@newsfe12.lga>
Cor Gest wrote:
> While amateurs discuss the merits of the "Brand-of-tools", artists just
> grab a sharpened piece of steel and a make work of art.
What do artisans do?
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Cor Gest
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <87ac1ntbdi.fsf@atthis.clsnet.nl>
Some entity AKA Ken Tilton <·········@gmail.com>
wrote mindboggling stuff, while contemplating deep thoughts with closed eyes.
(selectively-snipped-or-not-p)
> What do artisans do?
I am rather unfamiliar with the basketweaving trade, but I would not be
suprised yhey could not care less what "knive-brand" cut their reed.
Nor the brand of the cutters wellies for that matter.
Cor
--
The biggest problem LISP has is that it does not apeal to dumb people
If this failed to satisfy you try reading the HyperSpec or man frig
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Read Mailpolicy before mailing http://www.clsnet.nl/mail.html
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <8G3hh.354$5e3.167@newsfe09.lga>
Cor Gest wrote:
> Some entity AKA Ken Tilton <·········@gmail.com>
> wrote mindboggling stuff, while contemplating deep thoughts with closed eyes.
> (selectively-snipped-or-not-p)
>
>
>>What do artisans do?
>
>
> I am rather unfamiliar with the basketweaving trade,...
Damn, mine was a great comeback if you had known the meaning of artisan.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Cor Gest
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <87y7p6sydg.fsf@atthis.clsnet.nl>
Some entity AKA Ken Tilton <·········@gmail.com>
wrote mindboggling stuff, while contemplating deep thoughts with closed eyes.
(selectively-snipped-or-not-p)
> Cor Gest wrote:
> > Some entity AKA Ken Tilton <·········@gmail.com>
> > wrote mindboggling stuff, while contemplating deep thoughts with closed eyes.
> > (selectively-snipped-or-not-p)
> >
> >>What do artisans do?
> > I am rather unfamiliar with the basketweaving trade,...
>
> Damn, mine was a great comeback if you had known the meaning of artisan.
Pardon my french, but now your'e babbling.
Cor
--
The biggest problem LISP has is that it does not apeal to dumb people
If this failed to satisfy you try reading the HyperSpec or man frig
(defvar MyComputer '((OS . "GNU/Emacs") (IPL . "GNU/Linux")))
Read Mailpolicy before mailing http://www.clsnet.nl/mail.html
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <Dgdhh.8$If3.2@newsfe10.lga>
Cor Gest wrote:
> Some entity AKA Ken Tilton <·········@gmail.com>
> wrote mindboggling stuff, while contemplating deep thoughts with closed eyes.
> (selectively-snipped-or-not-p)
>
>
>>Cor Gest wrote:
>>
>>>Some entity AKA Ken Tilton <·········@gmail.com>
>>>wrote mindboggling stuff, while contemplating deep thoughts with closed eyes.
>>>(selectively-snipped-or-not-p)
>>>
>>>
>>>>What do artisans do?
>>>
>>>I am rather unfamiliar with the basketweaving trade,...
>>
>>Damn, mine was a great comeback if you had known the meaning of artisan.
>
>
> Pardon my french,...
Ah, not a native speaker, understood.
> but now your'e babbling.
I admire your skill at keeping this from turning into an intelligent
and/or pleasant exchange.
"An artisan, also called a craftsman,[1] is a skilled manual worker
who uses tools and machinery in a particular craft."
-- http://en.wikipedia.org/wiki/Artisan
Or maybe the problem is that you do not know how craftsman feel about
their tools, or maybe you do not consider programming a craft, or...?
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Cor Gest wrote:
> > Some entity AKA Ken Tilton <·········@gmail.com>
> > wrote mindboggling stuff, while contemplating deep thoughts with closed eyes.
> > (selectively-snipped-or-not-p)
> >
> >
> >>Cor Gest wrote:
> >>
> >>>Some entity AKA Ken Tilton <·········@gmail.com>
> >>>wrote mindboggling stuff, while contemplating deep thoughts with closed eyes.
> >>>(selectively-snipped-or-not-p)
> >>>
> >>>
> >>>>What do artisans do?
> >>>
> >>>I am rather unfamiliar with the basketweaving trade,...
> >>
> >>Damn, mine was a great comeback if you had known the meaning of artisan.
> >
> >
> > Pardon my french,...
>
> Ah, not a native speaker, understood.
>
> > but now your'e babbling.
>
> I admire your skill at keeping this from turning into an intelligent
> and/or pleasant exchange.
>
> "An artisan, also called a craftsman,[1] is a skilled manual worker
> who uses tools and machinery in a particular craft."
> -- http://en.wikipedia.org/wiki/Artisan
>
> Or maybe the problem is that you do not know how craftsman feel about
> their tools, or maybe you do not consider programming a craft, or...?
>
Why would he? By the definition *you* posted, a programmer is not
an artisan, but a basketweaver is.
goose,
"manual worker" does not even closely describe what a programmer
does.
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> There are no "constraints" on newbies just starting to learn.
I have to say that in my many experiences designing instruction for
"newbies" in this field, this has never been the case. Furthermore
in my conversations with instructional designers with decades of
experience, none of them have ever found this to be the case.
> p.s. exhuming dead discussions is bad usenetiquette
It's not dead if there is still a debate going on about whether
learners should use X or Y.
On 2006-12-16 14:10:16 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
> Raffael Cavallaro
> <················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
>
>> There are no "constraints" on newbies just starting to learn.
>
> I have to say that in my many experiences designing instruction for
> "newbies" in this field, this has never been the case. Furthermore in
> my conversations with instructional designers with decades of
> experience, none of them have ever found this to be the case.
You snipped this bit:
"They don't know how to walk yet - they shouldn't be deluding
themselves that there are "constraints" on what kind of running shoes
they wear to crawl around in. They will save themselves pain by
learning on an implementation that just works right out of the box."
A beginner who is just learning the language needs:
1. an ANSI conformant implementation
2. a lisp aware editor.
There are no other "constraints."
The most painless, works-out-of-the-box solution that conforms to these
two "constraints" is the obvious choice for the least pain. Since the
libre lisps do not come with an editor and must be configured to work
with one, and the commercial free trials do come with an integrated
lisp aware editor, this is one less thing to worry about.
You keep referring to "constraints" but for someone who doesn't even
know the language the only possible "constraints" are that the
implementation allows the easy editing of lisp code, and that the
implementation is standard conformant. Anything else is features to be
considered for a later date - you youself chided me, stating that asdf
installable libraries that just worked were unecessary for beginners to
learn. How could there be any other "constraints" besides a working
lisp-aware editor and an ANSI conformant implementation?
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-16 14:10:16 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
>
> > Raffael Cavallaro
> > <················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> >
> >> There are no "constraints" on newbies just starting to learn.
> >
> > I have to say that in my many experiences designing instruction for
> > "newbies" in this field, this has never been the case. Furthermore in
> > my conversations with instructional designers with decades of
> > experience, none of them have ever found this to be the case.
>
> You snipped this bit:
>
> "They don't know how to walk yet - they shouldn't be deluding
> themselves that there are "constraints" on what kind of running shoes
> they wear to crawl around in. They will save themselves pain by
> learning on an implementation that just works right out of the box."
Perhaps it's because I think a bit more kindly of and for lisp
learners than you. I've found that most of my fellow learners of
lisp not only know how to walk, but they know how to run in one or
more other programming languages. Rather than treating learners as
idiots who appear from nowhere with no needs, skills or history. I
tend to treat my learners the way I want to be treated, as a
informed individual with clear needs and the ability to make
rational decisions in my own best interest.
I've found that learners perform much better when you address their
concerns, and don't treat them as "deluded." Perhaps a key
difference in this argument is that I love learning, and love
helping other people learn, and know better than to treat learners
like most people treat babies. (Babies are much more sophisticated
in their learning than is popularly understood.)
> A beginner who is just learning the language needs:
>
> 1. an ANSI conformant implementation
> 2. a lisp aware editor.
>
> There are no other "constraints."
There is almost a century of research on how people learn, why
people learn, and how to help people learn that says learning
experiences are rarely that simple. I talk to a lot of people who
design instruction who say it is rarely that simple. I talk to
teachers and instructors working in schools who say that it is
rarely that simple.
There are two positions here. One is supported by millions of hours
of experience, shared among thousands of teachers, designers, tutors
and facilitators, examined using double-blind trials and published
under peer review.
And there is your position, which seems to be supported by nothing
more than your own insistence on oversimplification. On which
position should I bet as a designer/developer of learning
environments?
> You keep referring to "constraints" but for someone who doesn't even
> know the language the only possible "constraints" are that the
> implementation allows the easy editing of lisp code, and that the
> implementation is standard conformant.
As I've pointed out, there are quite a few other constraints which
may affect learners of a programming language:
1: One is asked to maintain or modify a pre-existing system.
2: One has a mandatory task in a domain that would be served in that
language.
3: One needs to learn the language to stay competitive in a changing
market.
4: One is told to learn and evaluate the language by an employer.
5: One is learning in the context of a classroom environment, and
needs to conform to the class.
And there are other things instructors, designers, teachers,
facilitators consider as well. Prior experience with programming
languages. Understanding of basic concepts of computer programming
and computer information processing. Skill using the particular
operating system. Are we talking about self-study, distance
education, a classroom or on-the-job training? Are the learners
adults or children? People who love helping other people learn
think about these factors.
> Anything else is features to be
> considered for a later date - you youself chided me, stating that asdf
> installable libraries that just worked were unecessary for beginners to
> learn. How could there be any other "constraints" besides a working
> lisp-aware editor and an ANSI conformant implementation?
Well, there is the other half of this argument. There are FOSS
packages that meet both of these requirements, and demand minimal or
no configuration from the end user. These packages are supported by
the most popularly recommended text for learning lisp. They work,
"right out of the box."
And I'm not arguing against Commercial Lisps here. I'm arguing
against the repeated claim that we need to patronize learners by
ignoring their needs and concerns, and the repeated claim that FOSS
lisp environments require such horrible amounts of effort to get
started. The former claims I suspect are motivated by an ideology I
find offensive no matter what the subject. The latter claims are
motivated by profound errors of fact.
On 2006-12-16 22:58:20 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
> As I've pointed out, there are quite a few other constraints which may
> affect learners of a programming language:
> 1: One is asked to maintain or modify a pre-existing system.
Not until one learns the language (or heaven help the client).
> 2: One has a mandatory task in a domain that would be served in that language.
Not until one learns the language.
> 3: One needs to learn the language to stay competitive in a changing market.
Still, just learning the language - not yet doing real work.
> 4: One is told to learn and evaluate the language by an employer.
Again, still just learning the language
> 5: One is learning in the context of a classroom environment, and needs
> to conform to the class.
In which case there is no choice whatsoever - you use what you're told to.
In every case above you're conflating *learning* the language with
actully using it for production work. Learning the basics of the
language might take as little as a few weeks. That process can be
accomplished on *any* ANSI conforming implentation. That process will
be made easier by having a lisp-aware editor. There are no other
"constraints." Best then to choose a learning environment with a built
in lisp-aware editor and not waste time with configuration issues.
The "constraints" only come with real work, *not* when just learning
the lanaguage.
You insist upon merging these two concerns - learning and real work -
and they are quite cleanly separable - you shouldn't be writing
production code in a language you don't know yet! With lisp the
separation of learning and real work is especially easy, because it is
an ANSI standard language so you can learn on one implementation and
use any number of others in the future.
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> In every case above you're conflating *learning* the language with
> actully using it for production work. Learning the basics of the
> language might take as little as a few weeks. That process can be
> accomplished on *any* ANSI conforming implentation. That process will
> be made easier by having a lisp-aware editor. There are no other
> "constraints." Best then to choose a learning environment with a built
> in lisp-aware editor and not waste time with configuration issues.
There is a big problem you keep avoiding in this discussion. There
are FOSS packages that provide this.
> The "constraints" only come with real work, *not* when just learning
> the lanaguage.
It is my experience (and the experience of my professional field)
that learners are almost always juggling multiple hats, and dealing
with constraints that can't be cleanly factored out of the learning
environment. Until you can provide more than rhetorical evidence for
this extraordinary claim, I'm not obliged to accept it.
On 2006-12-17 08:13:51 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
>> Best then to choose a learning environment with a built in lisp-aware
>> editor and not waste time with configuration issues.
>
> There is a big problem you keep avoiding in this discussion. There are
> FOSS packages that provide this.
No, they provide a lisp, and a separate editor, and require that you
configure them to work together, something which doesn't always happen
so easily for a complete newcomer to the language, especially as the
configuration language for the editor usually provided or recommended,
emacs, is *another lisp!*
The free trials just work. Full stop.
You keep talking about learners' "constraints" and now "multiple hats."
They're just learning, the only hat they should be wearing is that of
beginner. They can put on any hat they want to in a few weeks when they
actually know some of the language. They can choose any implementation
then too, and all of their language skills will transfer.
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2ejqyih8y.fsf@bertrand.local>
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2006-12-17 08:13:51 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
>
>>> Best then to choose a learning environment with a built in
>>> lisp-aware editor and not waste time with configuration issues.
>>
>> There is a big problem you keep avoiding in this discussion. There
>> are FOSS packages that provide this.
>
> No, they provide a lisp, and a separate editor, and require that you
> configure them to work together, something which doesn't always happen
> so easily for a complete newcomer to the language, especially as the
> configuration language for the editor usually provided or recommended,
> emacs, is *another lisp!*
>
> The free trials just work. Full stop.
>
> You keep talking about learners' "constraints" and now "multiple
> hats." They're just learning, the only hat they should be wearing is
> that of beginner. They can put on any hat they want to in a few weeks
> when they actually know some of the language. They can choose any
> implementation then too, and all of their language skills will
> transfer.
This whole thread is somewhat baffling to me, but I agree with Rafael
that getting started with a commercial Lisp is probably not a bad
idea. The commercial environments are in many ways more complete than
SLIME+(insert OSS Lisp here). For a beginner, having all of these
features available might help them to appreciate why interactive
development is so freaking cool.
If someone wants to use Lisp for academic work (as you, Kirk, do) and
you feel you need to stick with open-source Lisps, you can still gain
some familiarity with how Lisp development works by using a commercial
environment and can appreciate it as something closer to the ideal of
how Lisp programming should work. For example, even though I might
never get to write prodution code on a Lisp Machine, I think that
given their legendary development environments it would still be an
educational experience to play around with one.
Really, though, this thread is so silly.
On 2006-12-17 12:06:53 -0500, Bill Atkins
<····························@gmail.com> said:
> Really, though, this thread is so silly.
OK, I'll stop now.
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2k60qiany.fsf@bertrand.local>
Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> On 2006-12-17 12:06:53 -0500, Bill Atkins
> <····························@gmail.com> said:
>
>> Really, though, this thread is so silly.
>
> OK, I'll stop now.
Actually, I'm pretty sure you did stop a couple of posts upthread. :)
It was Mr. Sluder who continued talking about 'constraints' and
'authenticity.'
In article <··············@bertrand.local>,
Bill Atkins <····························@gmail.com> wrote:
> Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com>
> writes:
>
> > On 2006-12-17 12:06:53 -0500, Bill Atkins
> > <····························@gmail.com> said:
> >
> >> Really, though, this thread is so silly.
> >
> > OK, I'll stop now.
>
> Actually, I'm pretty sure you did stop a couple of posts upthread. :)
> It was Mr. Sluder who continued talking about 'constraints' and
> 'authenticity.'
Certainly, in response to you and Mr. Menke.
Mr. Cavallaro is not the only person to whom I've been responding,
and has no reason to claim to be slighted when I respond to issues
raised by other participants in this discussion.
As it is, there is nothing more to say other than to repeat the
point that the need to evaluate learning tools on a case-by-case
basis is grounded in decades of empirical research and the best
practices of professionals who help people learn. I'm no obligated
to accept claims that run counter to that research and best
practices.
In article <··············@bertrand.local>,
Bill Atkins <····························@gmail.com> wrote:
> This whole thread is somewhat baffling to me, but I agree with Rafael
> that getting started with a commercial Lisp is probably not a bad
> idea. The commercial environments are in many ways more complete than
> SLIME+(insert OSS Lisp here). For a beginner, having all of these
> features available might help them to appreciate why interactive
> development is so freaking cool.
Well, I didn't say it was a bad idea. However, the big problem of
education is how do we design educational systems that accommodate
the many dimensions of human diversity. And I'm not just talking
about diversity in terms of age, sex, ethnicity, race, ... . But
also diversity in prior experience, skills, needs, resources, time
and context.
The *best thing* would be to design an custom system for each and
every learner and each and every learning goal. Obviously we can't
do that.
So what we do is try to recommend learning systems for individuals
and groups on a case by case basis. For learning lisp, that might be
a commercial lisp. Sometimes that might be lisp-in-a-box. Sometimes
that might be FOSS lisp+slime. Sometimes that might be starting with
customizing emacs with elisp. For that matter, I know people who
started off learning lisp writing for MUDs.
I've seen too many really brilliant systems fail as learning
environments because they were not the best system for the target
audience. So I'm unwilling to make or accept blanket recommendations
made without a careful understanding of the end learner.
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-17 08:13:51 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
>
> >> Best then to choose a learning environment with a built in lisp-aware
> >> editor and not waste time with configuration issues.
> >
> > There is a big problem you keep avoiding in this discussion. There are
> > FOSS packages that provide this.
>
> No, they provide a lisp, and a separate editor, and require that you
> configure them to work together, something which doesn't always happen
> so easily for a complete newcomer to the language, especially as the
> configuration language for the editor usually provided or recommended,
> emacs, is *another lisp!*
See http://common-lisp.net/project/lispbox/ no configuration
required.
"After installation, you can run Lisp in a Box by typing
'~/LispBox/LispBox'" (Linux instructions)
So it seems that there are three options for a person who does not
want to configure SLIME, Allegro, lisp-in-a-box, and LispWorks. If
one chooses to configure SLIME, it's a trivial task that is well
documented.
From: rydis (Martin Rydstr|m) @CD.Chalmers.SE
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <w4c8xh2mx7p.fsf@rackham.cd.chalmers.se>
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> writes:
> The most painless, works-out-of-the-box solution that conforms to
> these two "constraints" is the obvious choice for the least
> pain. Since the libre lisps do not come with an editor and must be
> configured to work with one, and the commercial free trials do come
> with an integrated lisp aware editor, this is one less thing to worry
> about.
CMUCL comes with an integrated lisp aware editor, Hemlock. It might
not be the hottest, appearance-wise, but it works well for me, and I
use it as my main editor on my home machine.
(CMUCL does come with (much) less graphical development tools than,
for instance, LispWorks, but there are some. Not many seem to use
them, though, preferring Slime.)
',mr
--
rydis (Martin Rydstr�m) @CD.Chalmers.SE http://www.rydis.se
[Emacs] is written in Lisp, which is the only computer language that is
beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_
From: Robert Uhl
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m3d56lyrdf.fsf@latakia.dyndns.org>
Bill Atkins <····························@gmail.com> writes:
>
> What is it then? RMS's utopian vision for the future, where the job
> of programmer is reduced to providing support and everyone cheerfully
> uses crappy software because of the warm fuzzy feeling they get inside
> and the bright green glow of righteousness emitted by their monitors?
Perhaps you prefer his dystopian vision of the future, as set forth in
'The Right to Read'[0]? A few years ago folks were laughing at it--and
now it's coming to pass.
RMS's vision is not one of crappy software, but one of freedom. It
means that users would have the freedom to improve their software to
meet their needs--which would rather work against poor quality. If
anything, I think it'd be pretty cool to get rid of this developer/user
divide. All developers are users; all users should be developers.
[0] http://www.gnu.org/philosophy/right-to-read.html
--
Robert Uhl <http://public.xdi.org/=ruhl>
While I was at University in Lancaster, the International Committee of
the Red Cross was having a campaign to stop other organisations using
the name 'red cross' and served a 'cease and desist' notice on the Red
Cross Inn in Lancaster. The innkeeper turned round and pointed out that
the Red Cross Inn (founded, like most other pubs of the same name, by a
returning crusader) had been trading under that name for more than seven
hundred and fifty years, and politely asked how long they'd been using
it. The ICRC retired hurt. --Simon Brooke
Robert Uhl wrote:
> Bill Atkins <····························@gmail.com> writes:
> >
> > What is it then? RMS's utopian vision for the future, where the job
> > of programmer is reduced to providing support and everyone cheerfully
> > uses crappy software because of the warm fuzzy feeling they get inside
> > and the bright green glow of righteousness emitted by their monitors?
>
> Perhaps you prefer his dystopian vision of the future, as set forth in
> 'The Right to Read'[0]? A few years ago folks were laughing at it--and
> now it's coming to pass.
>
> RMS's vision is not one of crappy software, but one of freedom. It
> means that users would have the freedom to improve their software to
> meet their needs--which would rather work against poor quality. If
I personally dislike the word "free" in this context. As I said in this
ng
about 6 months ago, FOSS (as in GPL) has a price. If you make changes
to someone elses work you have to make your changes available to the
someone else whose work you used *if* you want to distribute your
changes.
Sometimes this price is too high for a commercial enterprise, and so
they
do not pay it (and hopefully do not use the others work).
Nothing is for free (except for BSD:-).
goose,
From: Pierre THIERRY
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <elv8r2$317n$1@biggoron.nerim.net>
Le Fri, 15 Dec 2006 10:31:31 -0800, goose a écrit:
> I personally dislike the word "free" in this context. As I said in
> this ng about 6 months ago, FOSS (as in GPL) has a price.
Well, that's a problem we have with Enlgish here. That's probably why
even english-speaking ones use the term "libre" which means, in French,
free as in freedom (free as in free beer is "gratuit" and there is no
link between them). Thus we have seen for some years now the acronym
FLOSS, for Free/Libre Open Source Software...
Semantically,
Pierre
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
On Fri, 15 Dec 2006 22:50:10 +0000 (UTC), Pierre THIERRY
<···········@levallois.eu.org> tried to confuse everyone with this message:
>Le Fri, 15 Dec 2006 10:31:31 -0800, goose a écrit:
>> I personally dislike the word "free" in this context. As I said in
>> this ng about 6 months ago, FOSS (as in GPL) has a price.
>
>Well, that's a problem we have with Enlgish here. That's probably why
>even english-speaking ones use the term "libre" which means, in French,
>free as in freedom (free as in free beer is "gratuit" and there is no
>link between them). Thus we have seen for some years now the acronym
>FLOSS, for Free/Libre Open Source Software...
>
Why not just LOSS? ;)
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
····@mail.ru (Timofei Shatrov) writes:
> On Fri, 15 Dec 2006 22:50:10 +0000 (UTC), Pierre THIERRY
> <···········@levallois.eu.org> tried to confuse everyone with this message:
>
>>Le Fri, 15 Dec 2006 10:31:31 -0800, goose a écrit:
>>> I personally dislike the word "free" in this context. As I said in
>>> this ng about 6 months ago, FOSS (as in GPL) has a price.
>>
>>Well, that's a problem we have with Enlgish here. That's probably why
>>even english-speaking ones use the term "libre" which means, in French,
>>free as in freedom (free as in free beer is "gratuit" and there is no
>>link between them). Thus we have seen for some years now the acronym
>>FLOSS, for Free/Libre Open Source Software...
>>
>
> Why not just LOSS? ;)
Obviously: FLOSS!
Or to be more precise: GLOSS (Gratis or Libre Open Source Software).
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Indentation! -- I will show you how to indent when I indent your skull!"
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2wt4r2dfa.fsf@bertrand.local>
Robert Uhl <·········@NOSPAMgmail.com> writes:
> Bill Atkins <····························@gmail.com> writes:
>>
>> What is it then? RMS's utopian vision for the future, where the job
>> of programmer is reduced to providing support and everyone cheerfully
>> uses crappy software because of the warm fuzzy feeling they get inside
>> and the bright green glow of righteousness emitted by their monitors?
>
> Perhaps you prefer his dystopian vision of the future, as set forth in
> 'The Right to Read'[0]? A few years ago folks were laughing at it--and
> now it's coming to pass.
This is not a software issue, but rather a legal and political issue.
I hope you don't think the only way to prevent this is to rewrite the
entire software universe from scratch and open-source it.
> RMS's vision is not one of crappy software, but one of freedom. It
> means that users would have the freedom to improve their software to
> meet their needs--which would rather work against poor quality. If
> anything, I think it'd be pretty cool to get rid of this developer/user
> divide. All developers are users; all users should be developers.
Excepting software written for programmers, do you think most users
are able to or want to be developers?
Bill Atkins <····························@gmail.com> writes:
> Robert Uhl <·········@NOSPAMgmail.com> writes:
>> RMS's vision is not one of crappy software, but one of freedom. It
>> means that users would have the freedom to improve their software to
>> meet their needs--which would rather work against poor quality. If
>> anything, I think it'd be pretty cool to get rid of this developer/user
>> divide. All developers are users; all users should be developers.
>
> Excepting software written for programmers, do you think most users
> are able to or want to be developers?
No. But that's where developers AND users still win:
now users are able to hire developers to correct bugs or to add
specific features to their software. The user can get what he
wants. The programmers can get more paid work.
With shrink wrapped software, when the user has a bug, he can pay
"support fees" to report it to the vendor, and not have anything in
exchange, the reasons why are well known.
And the developer having no source to work with cannot do much to help
the poor user: we cannot realistically propose to write a custom
application from scratch to replace the shrink wrapped one, just to
correct one bug or add a few specific features, it would be too costly
and too prone to failure given the differential of resources on both
sides (man.month and money).
--
__Pascal Bourguignon__ http://www.informatimago.com/
"Our users will know fear and cower before our software! Ship it!
Ship it and let them flee like the dogs they are!"
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2irgajwck.fsf@bertrand.local>
Pascal Bourguignon <···@informatimago.com> writes:
> No. But that's where developers AND users still win:
>
> now users are able to hire developers to correct bugs or to add
> specific features to their software. The user can get what he
> wants. The programmers can get more paid work.
Hmm. Interesting point.
From: Robert Uhl
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m3lkl4yj5n.fsf@latakia.dyndns.org>
Bill Atkins <····························@gmail.com> writes:
>
>> Perhaps you prefer his dystopian vision of the future, as set forth
>> in 'The Right to Read'[0]? A few years ago folks were laughing at
>> it--and now it's coming to pass.
>
> This is not a software issue, but rather a legal and political issue.
> I hope you don't think the only way to prevent this is to rewrite the
> entire software universe from scratch and open-source it.
I rather fear it may the only practical way.
>> RMS's vision is not one of crappy software, but one of freedom. It
>> means that users would have the freedom to improve their software to
>> meet their needs--which would rather work against poor quality. If
>> anything, I think it'd be pretty cool to get rid of this
>> developer/user divide. All developers are users; all users should be
>> developers.
>
> Excepting software written for programmers, do you think most users
> are able to or want to be developers?
Yes and kinda. Simple programming really isn't difficult; it's no
different from writing down a recipe. Users can do this without a
problem. I think that if they don't think of it as programming, they
might actually enjoy it.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Sometimes, I think the French were put on earth for no other reason than
to give Germany an over-inflated sense of their military prowess. Other
times, I can't come up with any reason at all. --Burt Prelutsky
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-14 13:02:52 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
>
> > Aquamacs on OS X: Download a disk image. Move the application package
> > to the Applications folder. Slime is included.
>
> There are of course more steps:
Such as? And what does this have to do with lisp?
> > SBCL on multiple platforms: Download an archive file. Extract that
> > archive file.
>
> open a terminal to ...
> > Run an installer script.>
> -find or create a .emacs file
And what does this have to do with lisp?
Certainly, I am assuming that a person wishing to learn lisp on an
operating system has some basic knowledge about that operating
system including how to open archives, and how to open up files in
an editor, and how to read files helpfully named "README." These are
not tasks which are in the domain of learning lisp, but would be
covered in a text like, "OS X, The Missing Manual" or "Linux for
Dummies," or "Windows XP for Dummies."
> -add a line to it specify your inferior lisp (how are lisp newbies
> supposed to know how to do this - they know no lisp, but they somehow
> do know emacs lisp?)
>
> -launch Aquamacs then type meta-x slime (again - they know this how?)
Configuration of emacs isn't necessary for lisp-in-a-box
installations which dump you automatically into a lisp REPL. Simply
double-click, and you have REPL.
If one chooses to do it the "hard way" information on how to setup
and invoke slime is helpfully covered in a file named "README." And
yes, I am still assuming that aspiring lisp hackers who want more
flexibility than lisp-in-a-box have previously mastered the "Your
Operating System for Dummies" competencies.
There are very few systems that protect against a refusal to RTFM.
> -Scratch head in bemusement later on when a message is displayed "lost
> connection to swank server"
Why would this happen?
Or to put it another way, even the "hard way" of setting up a lisp
and slime on OS X (and I just walked through the "hard way" this
morning, so I know) is less difficult than installing and
configuring MSOffice, sharing a printer, using Microsoft Remote
Desktop, or installing a database server. Setting up an imap or pop
mail client is more difficult. Getting photoshop to reliably see my
scanner is more difficult.
> Newbies need stuff that just works, not stuff that feels "authentic"
> unless they also want "authentic" configuration hassles.
There are two problems here.
First, if there is one thing that we know from educational research,
it's that the design of learning environments involves dozens of
tradeoffs. Sometimes, you want authentic configuration hassles. And
as I've pointed out before, I've never had the luxury of learning
very much through the use of contrived elaborations of "hello
world." All of my learning of software systems has been on-the-job
training.
Secondly, you keep raising FUD about "configuration hassles." Well,
one free distribution eliminates those hassles entirely. And well,
I've installed and configured multiple free lisps and slime on four
different operating systems with few hassles. I spend more time
cursing at my web browsers than at my lisps.
On 2006-12-14 21:06:48 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
> First, if there is one thing that we know from educational research,
> it's that the design of learning environments involves dozens of
> tradeoffs. Sometimes, you want authentic configuration hassles.
speechless, really, just aghast - we're done here.
In article
<····································@pasdespamsilvousplaitmaccom>,
Raffael Cavallaro
<················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
> On 2006-12-14 21:06:48 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
>
> > First, if there is one thing that we know from educational research,
> > it's that the design of learning environments involves dozens of
> > tradeoffs. Sometimes, you want authentic configuration hassles.
>
> speechless, really, just aghast - we're done here.
I guess I'm still wondering. Why is the principle that the design of
any learning environment involves tradeoffs between simplification
and authenticity so offensive to you? There has been reams and
reams of research involving these tradeoffs, and from my point of
view, it's rather like arguing against, say, general relativity or
semiconductors.
Generally I find that when someone insists that there is one and
only one way that people should learn, it almost always involves
either a political position, or a misconception.
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m21wn1gtsi.fsf@bertrand.local>
Kirk Sluder <····@nospam.jobsluder.net> writes:
> In article
> <····································@pasdespamsilvousplaitmaccom>,
> Raffael Cavallaro
> <················@pas-d'espam-s'il-vous-plait-mac.com> wrote:
>
>> On 2006-12-14 21:06:48 -0500, Kirk Sluder <····@nospam.jobsluder.net> said:
>>
>> > First, if there is one thing that we know from educational research,
>> > it's that the design of learning environments involves dozens of
>> > tradeoffs. Sometimes, you want authentic configuration hassles.
>>
>> speechless, really, just aghast - we're done here.
>
> I guess I'm still wondering. Why is the principle that the design of
> any learning environment involves tradeoffs between simplification
> and authenticity so offensive to you? There has been reams and
> reams of research involving these tradeoffs, and from my point of
> view, it's rather like arguing against, say, general relativity or
> semiconductors.
What do you mean by "authenticity"? Is this some sort of jargon?
What is more "authentic" about configuring and using SLIME instead of
playing with a working Lisp environment?
> Generally I find that when someone insists that there is one and
> only one way that people should learn, it almost always involves
> either a political position, or a misconception.
Indeed!
In article <··············@bertrand.local>,
Bill Atkins <····························@gmail.com> wrote:
> Kirk Sluder <····@nospam.jobsluder.net> writes:
> > I guess I'm still wondering. Why is the principle that the design of
> > any learning environment involves tradeoffs between simplification
> > and authenticity so offensive to you? There has been reams and
> > reams of research involving these tradeoffs, and from my point of
> > view, it's rather like arguing against, say, general relativity or
> > semiconductors.
>
> What do you mean by "authenticity"? Is this some sort of jargon?
> What is more "authentic" about configuring and using SLIME instead of
> playing with a working Lisp environment?
Is SLIME not a working Lisp environment?
The point of learning environments is the eventual transfer of
skills to a working environment(*). Generally it seems to be the
case that skill transfer is facilitated when the learning
environment mirrors the working environment as much as possible.
Some of the methods used to accomplish this are:
* Apprenticeships: learning in an working environment under the
direction of a more skilled supervisor.
* Simulations: often used when the final task involves high
cost/risk.
* Problem and project-based learning: giving learners realistic and
messy problems to solve.
* Just-in-time training/learning: small modules used by the person
as needed.
My point regarding pedagogy is that you cannot make a blanket
recommendation absent context and needs. My hunch is that a person
is better off learning using the lisp environment they are most
likely to eventually use. If a person is going to use SLIME, they
\emph{might be} better off learning with SLIME. If a person is
going to use a commercial IDE, one \emph{might be} better off
learning with a commercial IDE. I emphasize \emph{might be} because
there are plenty of other factors from learner to learner and
context to context that should be considered.
Earlier in this thread I described two reasons why I chose FOSS
lisps and SLIME. First, I did not feel that my work was clearly
permitted as "personal and academic" use. These terms are undefined
in the licenses. Second, I wanted permission to redistribute the
tools and data to other persons. A third reason is that I had
limited funds, and no anticipated need for some of the additional
features of LispWorks or Allegro. So there were pragmatic reasons
for choosing FOSS software from the start.
(*) Or play environment, or hobby, or some other environment where
you put the knowledge in practical use.
In article <·········@news.chiark.greenend.org.uk>,
Ian Jackson <········@chiark.greenend.org.uk> wrote:
> In article
> <····································@pasdespamsilvousplaitmaccom>,
> Raffael Cavallaro <················@pas-d'espam-s'il-vous-plait-mac.com>
>
> >The best documentation for learning common lisp is the freely available
> >Practical Common Lisp by Peter Siebel [...]
>
> I think the problem here isn't that it's not free (or not Free), but
> that it's not brief.
I'm wondering, is it really possible to create a "brief"
introduction to a language? At any rate, one of the things I liked
about PCL was that after working through the first two chapters, and
dipping as needed into the rest I was well on my way to producing
the kinds of scripts I needed. You don't have to get into the foo
DSL in the later chapters.
From: Pascal Costanza
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <4tm101F14n328U1@mid.individual.net>
Ian Jackson wrote:
> And of course, we need a standard and common set of libraries,
> available in the same way. For example, Debian stable has three
> Common Lisp regexp libraries. As someone new to Lisp I have no idea
> how to choose between them. Obviously I can do research but:
>
> *People writing in Python or Perl or Ruby do not have to do research
> to choose between competing regexp libraries!*
>
> To make CL attractive, it is essential that what other languages
> regard as trivial and obvious tasks are easily addressed without a
> great deal of background reading.
CL is not a language for people who are afraid of understanding the
background of what they are using.
On the other hand, if you want to have a CL system that comes with a lot
of preinstalled libraries, there are a few choices out there. For
example, using one of the commercial implementations is not a bad
choice, especially not for a beginner. (Don't worry here, due to some
fundamental characteristics of Lisp, there is little danger of vendor
lock-in here.)
> Have you programmed in Python ? The standard libraries are a bit
> disorganised but there is clear documentation, most things that one
> wants are provided, and if there is more than one of anything then all
> but one are explicitly deprecated with a reference to the preferred
> interface. (I'm not a fan of Python, by the way, but like any
> programmer in the larger world I deal with it occasionally.)
>
> Indeed, have you programmed recently in anything but Common Lisp ?
>
> If you want CL to become more popular you will have to accomodate and
> satisfy the expectations of people from outside the Lisp world.
Becoming more popular is an important goal, since it increases the
number of users and thus helps to ensure a certain longevity of CL.
But: Becoming popular is not the most important goal!
Lisp requires a change of perspective in a few areas, which includes
dropping a number of habits and replacing them with new ones. Some
elements of this new perspective are hard to understand in the
beginning. So you need to be patient in this regard. It's impossible to
be able to judge these things after just two months.
One important boundary condition is that Common Lisp is not a single
implementation language, but a language specification with quite a few
implementations that adhere to it. Some of the things you are asking for
are impossible due to this fact. The different implementations have
their respective strengths and it is quite unlikely that one of them
will become _the_ single dominant Common Lisp.
(And that's just the tip of the iceberg.)
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
In article <···············@mid.individual.net>,
Pascal Costanza <··@p-cos.net> wrote:
>Becoming more popular is an important goal, since it increases the
>number of users and thus helps to ensure a certain longevity of CL.
>
>But: Becoming popular is not the most important goal!
Obviously not. But the things I'm suggesting don't have a downside.
They just make CL more attractive. I'm not asking that CL be changed,
even - I think the solution is better documentation and better and
more standard addons (de-facto standard would be fine).
>Lisp requires a change of perspective in a few areas, [...]
This is true of any programming language. What is troublesome about
Common Lisp is that - if you have a certain mindset - it seems to
insist on being the whole answer to the problems you attack with it.
That's not helpful, because complex and difficult problems are usually
best solved with a mixture of tools and approaches.
>One important boundary condition is that Common Lisp is not a single
>implementation language, but a language specification [...]
The same is true of C and Haskell and even Java. That's doesn't
preclude addressing the barriers to adoption I'm discussing.
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
From: Pascal Costanza
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <4tmcthF14k9ukU1@mid.individual.net>
Ian Jackson wrote:
> In article <···············@mid.individual.net>,
> Pascal Costanza <··@p-cos.net> wrote:
>> Becoming more popular is an important goal, since it increases the
>> number of users and thus helps to ensure a certain longevity of CL.
>>
>> But: Becoming popular is not the most important goal!
>
> Obviously not. But the things I'm suggesting don't have a downside.
> They just make CL more attractive. I'm not asking that CL be changed,
> even - I think the solution is better documentation and better and
> more standard addons (de-facto standard would be fine).
The documentation exists and is appropriate. It's just longer because
there is more to explain. As I tried to explain, CL requires a more
radical change of perspective than other languages.
It's unclear to me what you mean with "better." Better than what?
More standard libraries and add-ons are being developed. Due to the
(weird) early adopters' state of Common Lisp at this point in time, some
things haven't stabilized yet.
But another important aspect is that Common Lisp is not a language whose
design is being dictated by a single person or a single self-elected
group of people. This has both disadvantages (which you seem to notice)
and advantages (which you don't yet seem to notice).
>> Lisp requires a change of perspective in a few areas, [...]
>
> This is true of any programming language. What is troublesome about
> Common Lisp is that - if you have a certain mindset - it seems to
> insist on being the whole answer to the problems you attack with it.
> That's not helpful, because complex and difficult problems are usually
> best solved with a mixture of tools and approaches.
The cool thing about Common Lisp that you can have a mixture of tools
and approaches in the same environment.
To quote Guy Steele: "If you give someone Fortran, he has Fortran. If
you give someone Lisp, he has any language he pleases."
Common Lisp is not a language. It's a language toolbox. Unfortunately,
this is exactly the one part that is hard to understand in the beginning
and will take a while to grasp.
Exactly because it is a language toolbox, the notion of standard
libraries makes a lot less sense than in other languages.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
On 9680 day of my life Ian Jackson wrote:
> ... Complex and difficult problems are usually best solved with a
> mixture of tools and approaches.
Lisp *is* a mixture of tools and approaches :)
--
Ivan Boldyrev
Violets are red
Roses are blue
It's amazing what DNA splicing can do.
(message (Hello 'Ian)
(you :wrote :on '(05 Dec 2006 13:07:30 +0000 (GMT)))
(
IJ> All of the languages that Common Lisp is competing with are available
IJ> pre-built, and often preinstalled, on all of the major Linux
IJ> distributions and many proprietary Unix systems.
hell, no.
i have a _lot_ of hassle installing Java -- the most language Common Lisp is
competing.
at same time, lisp installs surprisingly well.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
In article <·························@news.sunsite.dk>,
Alex Mizrahi <········@users.sourceforge.net> wrote:
> [Ian Jackson]:
> > All of the languages that Common Lisp is competing with are available
> > pre-built, and often preinstalled, on all of the major Linux
> > distributions and many proprietary Unix systems.
>
>hell, no. i have a _lot_ of hassle installing Java -- the most
>language Common Lisp is competing. at same time, lisp installs
>surprisingly well.
You're right that Java has many of the same problems. Those problems
are daily cursed by programmers around the world whose idiot bosses
have mandated that they use Java, after having been told my Sun's
massive marketing campaign how wonderful it was. Common Lisp doesn't
have the doubtful benefit of a following amongst idiot bosses.
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
In article <·········@news.chiark.greenend.org.uk>,
Ian Jackson <········@chiark.greenend.org.uk> wrote:
>have mandated that they use Java, after having been told my Sun's
^^
`by'. Oops, I didn't want to claim responsibility for that :-).
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
Ian Jackson <········@chiark.greenend.org.uk> writes:
> [...]
> *People writing in Python or Perl or Ruby do not have to do research
> to choose between competing regexp libraries!*
So the problem would be that there are too many libraries, too many
implementations of CL and too many CL tutorials, too much choice.
If that was true:
1- it's too late the worms are out of the can. What do you suggest?
Erasing implementations and libraries?
2- I don't believe it's bad. Newbies have better come to term with
this life fact: we're not 6.5 billion clones, we're 6.5 billion
individuals.
3- there would also be too many scheme, ruby, python, perl tutorials:
google gives:
318,000 for "common lisp" tutorial.
1,280,000 for scheme tutorial.
1,810,000 for ruby tutorial.
6,940,000 for python tutorial.
12,100,000 for perl tutorial.
Clearly, Common Lisp is still the best choice here...
Perhaps you should choose LispWorks Common Lisp:
36 for "LispWorks Common Lisp" tutorial.
> To make CL attractive, it is essential that what other languages
> regard as trivial and obvious tasks are easily addressed without a
> great deal of background reading.
Once again, I notice that you have a business opportunity here. What
are you waiting to start working on it?
--
__Pascal Bourguignon__ http://www.informatimago.com/
IMPORTANT NOTICE TO PURCHASERS: The entire physical universe,
including this product, may one day collapse back into an
infinitesimally small space. Should another universe subsequently
re-emerge, the existence of this product in that universe cannot be
guaranteed.
In article <··············@thalassa.informatimago.com>,
Pascal Bourguignon <···@informatimago.com> wrote:
>Ian Jackson <········@chiark.greenend.org.uk> writes:
>> *People writing in Python or Perl or Ruby do not have to do research
>> to choose between competing regexp libraries!*
>
>So the problem would be that there are too many libraries, too many
>implementations of CL and too many CL tutorials, too much choice.
In one sense, yes, but (obviously) I think the availability of
alternatives is a good thing. What is lacking is a clear consensus
that _these_ are the ones you probably want, whereas _those_
competitors are not quite there yet, or better for special purposes,
or what-have-you.
> 3- there would also be too many scheme, ruby, python, perl tutorials:
> google gives:
Reading a tutorial is not the same kind of commitment as building
reliance on a particularly library into a program.
>Once again, I notice that you have a business opportunity here. What
>are you waiting to start working on it?
I'm too busy fixing other parts of the world. Aren't we all ?
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
From: Robert Uhl
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m33b7shmha.fsf@latakia.dyndns.org>
Pascal Bourguignon <···@informatimago.com> writes:
>
>> *People writing in Python or Perl or Ruby do not have to do research
>> to choose between competing regexp libraries!*
>
> So the problem would be that there are too many libraries, too many
> implementations of CL and too many CL tutorials, too much choice.
It's not so much that there's a choice--it's that there are no
defaults. E.g., if every implementation had CL-PPCRE you'd be free to
download some other regexp library, but every tutorial could rely on you
have CL-PPCRE, and 11/12ths of programmers would never worry about it.
Imagine in CL if you had to write (+ 1 2 :base 10 :rollover nil :type
(list integer integer)) every time... Better to provide some sane
defaults and not worry about it.
And yes, I realise that tacking a base argument on #'+ is nonsensical in
this case because by the time #'+ sees its arguments they've been read
and are just numbers. It's an example, that's all.
--
Robert Uhl <http://public.xdi.org/=ruhl>
If your adversary is badly bunkered, there is no rule against your
standing over him and counting his strokes aloud, but it will be a wise
precaution to arm yourself with the niblick before doing so, so as to
meet him on equal terms. --Horace G. Hutchinson, 1886
Hi,
Ian Jackson <········@chiark.greenend.org.uk> writes:
> *People writing in Python or Perl or Ruby do not have to do research
> to choose between competing regexp libraries!*
this, I humbly think, is a wrong mindset: CL doesn't compete with
those scripting languages but more with C++ and Java. That makes all
the difference.
C++:
There is not built-in regexp engine in C++, the installation of the
runtime is a real pain (gcc and libc), library dependencies get in the
way all the time and there is no single lib for each single task. And
just because almost everybody uses GCC nowadays does not mean that
there are not other compilers out there (intel, ms, ...).
Ah, and try to have several versions of GCC and other C-compilers on
one system. Fun that is.
Java:
Things are slightly better here because the language ships with a huge
collection of standard libs and classes. But what about different
versions of java on one system, do your programs run on IBM Java as
well as Sun Java and compile with GJC? Gentoo just came up with a
mechanism to switch java versions on a per user basis whenever you
need to switch. Cross your fingers that you never need two programms
running at the same time using different versions. And when it comes
to things not in the language standard you're pretty hopelessly lost
in the internet because search machines can't help too much with a
language that is hype-oriented. You alway have to skim through
strategic, marketing and other buzz-word pages until you get to the
technical bottom.
CL:
Keep several binaries and core file wherever you want. Each package
of those two makes for a complete runtime. Keep listening to the
CL-senders (like this newsgroup) and you will get a picture of what
libraries to use.
Mind, though, that I agree with you that the beginners barriers are
big (I once wrote a small essay much like your rant here ;-). But
then, just keep hanging around, start a CL project every now and then
and you will pretty sure get into things. It's a different world and
it needs different thinking and that needs getting used to.
Kind Regards
Stefan
--
Stefan Kamphausen --- http://www.skamphausen.de
a blessed +42 regexp of confusion (weapon in hand)
You hit. The format string crumbles and turns to dust.
In article <··············@usenet.my.skamphausen.de>,
Stefan Kamphausen <······@gmx.de> wrote:
>Ian Jackson <········@chiark.greenend.org.uk> writes:
>> *People writing in Python or Perl or Ruby do not have to do research
>> to choose between competing regexp libraries!*
>
>this, I humbly think, is a wrong mindset: CL doesn't compete with
>those scripting languages but more with C++ and Java. That makes all
>the difference.
See my comments back ^ there about Java. C++ also has enormous hype
and momentum behind it. The people who are using it aren't doing so
because of how wonderful C++ is (after all, C++ is pretty awful), so
competing on wonderfulness is missing the point.
At least the scripting languages are still competing on their merits.
One reason they can do that is that it's a low time commitment to try
them out on small problems.
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
Stefan Kamphausen ¼g¹D¡G
> Hi,
> CL:
> Keep several binaries and core file wherever you want. Each package
> of those two makes for a complete runtime. Keep listening to the
> CL-senders (like this newsgroup) and you will get a picture of what
> libraries to use.
Excuse me but I can't understand these words.
What does it by "Keep several binaries and core file wherever you
want"?
and "Each package of those two makes for a complete runtime"...
I am not familiar with the CL runtime enviroment...
Can you detail them? Thanks
hi,
·············@gmail.com" <············@gmail.com> writes:
> Stefan Kamphausen �g�D�G
>
>> Hi,
>> CL:
>> Keep several binaries and core file wherever you want. Each package
>> of those two makes for a complete runtime. Keep listening to the
>> CL-senders (like this newsgroup) and you will get a picture of what
>> libraries to use.
> Excuse me but I can't understand these words.
> What does it by "Keep several binaries and core file wherever you
> want"?
> and "Each package of those two makes for a complete runtime"...
>
> I am not familiar with the CL runtime enviroment...
> Can you detail them? Thanks
A runtime is what you need to run your program.
Well your Java runtime comprises the java binary and loads of
jar-files which contain all the standard classes. The C/C++ runtime
comprises at least the lib and several other libraries. For a
compiler you also need GCC.
When in the lisp world you just take a binary (e.g. "lisp" for CMUCL,
or "sbcl" for SBCL) and one core file (/usr/lib/cmucl/lisp.core, or
/usr/lib/sbcl/sbcl.core or (and this is interesting) any other core
file you created with all your lisp libraries loaded), tell the binary
which core file to use (lisp -core corefile, sbcl --core corefile) and
there you are. Runtime plus compiler at hand.
Does that help?
Stefan
--
Stefan Kamphausen --- http://www.skamphausen.de
a blessed +42 regexp of confusion (weapon in hand)
You hit. The format string crumbles and turns to dust.
From: Robert Uhl
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m37ix4hnzr.fsf@latakia.dyndns.org>
Ian Jackson <········@chiark.greenend.org.uk> writes:
>
> And of course, we need a standard and common set of libraries,
> available in the same way. For example, Debian stable has three
> Common Lisp regexp libraries. As someone new to Lisp I have no idea
> how to choose between them. Obviously I can do research but:
>
> *People writing in Python or Perl or Ruby do not have to do research
> to choose between competing regexp libraries!*
Well, they get one by default. No doubt there are others available if
they really wanted them.
>>> What if I'm a vi (vim) user ?
>>
>>You must be a masochist. I was a vi user once upon a time, long long
>>before I got my NeXTstation.
>
> *blink* I'm not a vi user personally, but do you think that this
> response is likely to encourage people to try out Common Lisp ?
It's true, though. There's just no reason to use vi for
programming--and I know, for I was a vi-user for a long time. Using vi
to program is like writing a word processor for Windows in octal:
possible but severely unpleasant.
That said, I'm told that there are many vim-using Lispers out there; a
quick googling reveals several pertinent documents.
> If you want CL to become more popular you will have to accomodate and
> satisfy the expectations of people from outside the Lisp world.
The problem is that there are very few people invested in the success of
Lisp-the-language. There are folks invested in the success of SBCL or
Allegro or LispWorks; there are folks invested in the success of
CL-PPCRE (which is, incidentally, the regexp library to use); but who is
invested in the success of Lisp-the-language? The closest I can come up
with is Kent Pitman, but he apparently doesn't want Lisp to succeed
enough to embrace free implementations thereof.
The Benevolent-Dictator-for-Life model has several advantages; among
them is that he really, _really_ wants his project to succeed, so he
tries to come up with an attractive offering. Perl was attractive in
its time (as was Cybil Shepherd; like Miss Shepherd, it's not aged
gracefully); Python is an attractive platform; Ruby is an attractive
platform. Common Lisp is an attractive language, but the platform is
essentially nonexistent.
--
Robert Uhl <http://public.xdi.org/=ruhl>
From my cold dead hands, my ass. I'll be taking their issue weapons
from their cold dead hands. I fight to win. --KBarrett
Ian Jackson ha escrito:
> So I decided I needed to try out SLIME. Note that SLIME isn't in
> Debian stable. Being an experienced Debian developer made solving
> this situation straightforward for me (if slightly tedious) but for
> many people it would have been hard or even impossible. (I have no
> idea what the situation is like on other Linux distributions, let
> alone on non-GNU systems.)
You should really, really use Emacs for Lisp developing, unless you pay
for Lisp Works.
Emacs is a decent editor once you understand how does it work.
For installing SLIME:
* Copy the slime folder under site-lisp of your emacs directory
(probably /usr/share/emacs/site-lisp)
* Open ~/.emacs and write (require 'slime) and evaluate it (puting the
cursor behind the right parenthesis and pushing C-x and C-e).
Once you have installed SBCL, in emacs push M-x and write slime, and
there you got it. (If it doesn't work, create a link from the sbcl
executable to /usr/bin/lisp).
And please, go to the help menu and spend some time in following the
emacs tutorial.
From: Pascal Costanza
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <4tko44F149vqnU1@mid.individual.net>
Ian Jackson wrote:
> As an experienced programmer, I've heard a lot about how good Lisp is,
> and I like getting to grips with new languages. After conversations
> with friend who's keen I decided I should learn Common Lisp.
That's a good idea. ;)
> I thought I'd share some of my experiences here. While much of what
> I'm going to say is critical, I'd like to emphasize that I'm not
> giving up on Lisp. I like what I've seen so far, and the hurdles are
> more entrance barriers than they are problems for serious work - but
> they are quite time-consuming, and nowadays we are all in a hurry.
>
> So without futher ado, let me summarise my key point:
>
> * Documentation for introducing Lisp to existing programmers is poor;
> existing tutorials are old or at least outdated.
There are at least two pretty good new ones:
- http://www.gigamonkeys.com/book/
- http://psg.com/~dlamkins/sl/cover.html
> A comprehensive resource aimed at contemporary non-Lisp programmers
> is urgently needed. I was going to started an article on the CLiki
> with some pointers and discussion, but as I've written this article
> I've realised that the answers I have found are not really usefully
> transferrable to other people new to Lisp unless they have
> circumstances very like my own.
I had the same problem a few years ago when I made my switch to Common
Lisp. I have summarized my experiences at
http://p-cos.net/lisp/guide.html in the hope to make things easier for
other people. If you have suggestions for improving my guide, I would be
glad to hear about them.
> Secondarily:
>
> * Infrastructure for performing tasks which are routine in
> modern programming is often lacking and/or hard to find.
The main reason for this is one that newcomers typically don't find to
be a satisfactory answer, but it is indeed the main reason: The
infrastructure for performing tasks which are routine in Lisp is often
lacking and/or hard to find elsewhere.
Lisp provides different takes on things at several levels. For many of
the routine tasks in other languages, you will sooner or later find the
- more often than not better - equivalents in Lisp. The alternatives
that are used elsewhere are simply not needed. What looks like a
deficiency from the outside is very often indeed a win.
> * Support for Common Lisp development in Debian stable is
> surprisingly poor, given how mature the Lisp world is.
I can't comment on this.
> When I first settled on learning CL I thought I would read a standard
> reference work. This is my usual way of approaching new programming
> languages - I'm one of the minority of people who find they get on very
> well with reference manuals, and find tutorials distressingly vague
> about details.
Same here. ;)
> A Lisp-using friend lent me their copy of CLtL2, and I started reading
> through that. I quickly gave up because of Guy Steele's absurd habit
> of writing `and the thingum does the wossname to the doobry - no wait,
> it doesn't, in 1987 X3J13 voted that in fact the thingum does
> something completely different'. This is all very well once or twice
> but constantly reading, understanding and internalising complex
> descriptions, only to be told in the next paragraph that it's all
> false and I had to forget it all again, was too much like hard work.
> (There are some typographical indications but they are too weak to
> interrupt the flow of concentrated reading and in any case the text
> only does original-version-and-diff rather than an integrated
> description.)
True. CLtL2 was an intermediate report on Common Lisp standardization
that was apparently strongly needed by the community in 1989. The
finalization of ANSI Common Lisp took a few more years (it was finally
achieved in 1994/95), so it's clear that people needed something in
between to be able to work with Common Lisp. Common Lisp already had a
semi-official specification before (CLtL1), so for people at that time
it was indeed very useful to know what the differences between the two
texts were.
From nowadays perspective, it would indeed be a good idea to have a new
version of CLtL2 that reflects ANSI Common Lisp and completely omits the
old stuff. Especially because CLtL2 is in place indeed an excellent
text. But that would be a lot of work...
> My next approach was to try to read the Hyperspec through. Well, I'm
> still doing that - but the Hyperspec is poorly structured for this.
> The number of forward references is much higher than for most other
> language specifications. It's possible that a different reading order
> for the Hyperspec would improve this but I suppose since most people
> prefer to learn languages from tutorials I'm probably out of luck.
The HyperSpec indeed makes a suggestion for an alternative reading order
at http://www.lispworks.com/documentation/HyperSpec/Front/Hilights.htm
> It was evident that attempting to find a spec to just read wasn't
> going to be very fruitful. Since I've used Lisp variants before on
> occasion, I decided it would be better to pick some project and
> just write a program.
Another alternative is to start with the ISLISP specification which is
mostly a subset of Common Lisp. See the specification you can find at
http://islisp.info/ (Unfortunately, a few things do not work in Common
Lisp).
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Holger Schauer
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <yxzwt55yqju.fsf@gmx.de>
On 4843 September 1993, Pascal Costanza wrote:
> Ian Jackson wrote:
>> * Support for Common Lisp development in Debian stable is
>> surprisingly poor, given how mature the Lisp world is.
> I can't comment on this.
I think I can. I agree with Ian. The basic problem is that as of
today, CL libraries and implementations are fast moving targets (wow,
I never would have believed that in the late 90s), while Debian stable
is -- per definiton -- stable. For instance, you don't really want to
try to use UCW on Debian Sarge. Over the last year, I've experienced
quite some hassle on Sarge, although (or perhaps because?) I'm using
backports.org. The latest installment of cmucl and
common-lisp-controller from bpo segfaults, for instance.
Holger
--
--- http://hillview.bugwriter.net/ ---
"Innenminister Schillstein hat gestern eine Anweisung erlassen, die
den Betrieb von Homefirewalls verbietet: `Die Umsetzung der europ�ischen
Brandschutzrichtlinie Nummer 1234 l��t uns keinen Spielraum: Die
Feuerwehr mu� st�ndig Zugriff auf die Wohnungselektronik haben.'"
-- Uwe Ohse in de.alt.sysadmin.recovery
From: Pascal Costanza
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <4to7ocF14nv3lU1@mid.individual.net>
Holger Schauer wrote:
> On 4843 September 1993, Pascal Costanza wrote:
>> Ian Jackson wrote:
>>> * Support for Common Lisp development in Debian stable is
>>> surprisingly poor, given how mature the Lisp world is.
>> I can't comment on this.
>
> I think I can. I agree with Ian. The basic problem is that as of
> today, CL libraries and implementations are fast moving targets (wow,
> I never would have believed that in the late 90s), while Debian stable
> is -- per definiton -- stable. For instance, you don't really want to
> try to use UCW on Debian Sarge. Over the last year, I've experienced
> quite some hassle on Sarge, although (or perhaps because?) I'm using
> backports.org. The latest installment of cmucl and
> common-lisp-controller from bpo segfaults, for instance.
But that sounds like a problem of Debian, not of Common Lisp, doesn't it?
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Holger Schauer
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <yxzu008zzse.fsf@gmx.de>
On 4844 September 1993, Pascal Costanza wrote:
> Holger Schauer wrote:
>> On 4843 September 1993, Pascal Costanza wrote:
>>> Ian Jackson wrote:
>>>> * Support for Common Lisp development in Debian stable is
>>>> surprisingly poor, given how mature the Lisp world is.
>>> I can't comment on this.
>> I think I can. I agree with Ian. The basic problem is that as of
>> today, CL libraries and implementations are fast moving targets (wow,
>> I never would have believed that in the late 90s), while Debian stable
>> is -- per definiton -- stable. [...]
> But that sounds like a problem of Debian, not of Common Lisp, doesn't it?
On first sight, yes, but not so on the second. One major
accomplishment of Debian is usually that shipped versions work and
typically that they're compatible with each other. But one of the
major problems with the current developments efforts is that often
enough APIs change. Over the last year, I think it happened to me
twice that I wanted to update some library or CL implementation, and
discovered that in order to run it, or better said, my applications on
top of it, I had to get the latest version of some other, totally
unrelated library, too. And then there are those packages which keep
their own version of some CL library that you might have already
installed in a different and incompatible version (UCW has some of
these, IIRC). As a result (of my manual repairs), my
/usr/share/common-lisp/ directory is currently such a mess that it
reminds me of students kitchens.
From what I've read and heard, the situation is likely to get better
with Etch (more libraries, more up-to-date), as I know that there are
some people working on improving the situation. We'll see.
Holger
--
--- http://hillview.bugwriter.net/ ---
"Innenminister Schillstein hat gestern eine Anweisung erlassen, die
den Betrieb von Homefirewalls verbietet: `Die Umsetzung der europ�ischen
Brandschutzrichtlinie Nummer 1234 l��t uns keinen Spielraum: Die
Feuerwehr mu� st�ndig Zugriff auf die Wohnungselektronik haben.'"
-- Uwe Ohse in de.alt.sysadmin.recovery
From: Richard M Kreuter
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <878xhk1xvp.fsf@progn.net>
Holger Schauer <··············@gmx.de> writes:
> On 4844 September 1993, Pascal Costanza wrote:
>> But that sounds like a problem of Debian, not of Common Lisp,
>> doesn't it?
>
> On first sight, yes, but not so on the second. One major
> accomplishment of Debian is usually that shipped versions work and
> typically that they're compatible with each other...
I've used Debian stable for years, and while it is a nice platform in
many ways, I always find myself needing to go outside the system for
various things: PostgreSQL, Emacs or Emacs addons, Firefox, CPAN
modules. Folks I know do or have done the same for Python versions,
desktops, X-Windows implementations. There's really nothing
Lisp-specific about the situation.
--
RmK
From: Holger Schauer
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <yxzr6vcyubc.fsf@gmx.de>
On 4844 September 1993, Richard M. Kreuter wrote:
> Holger Schauer <··············@gmx.de> writes:
>> On 4844 September 1993, Pascal Costanza wrote:
>>> But that sounds like a problem of Debian, not of Common Lisp,
>>> doesn't it?
>> On first sight, yes, but not so on the second. One major
>> accomplishment of Debian is usually that shipped versions work and
>> typically that they're compatible with each other...
> I've used Debian stable for years, [...]
So do I.
> and while it is a nice platform in many ways, I always find myself
> needing to go outside the system for various things: PostgreSQL,
> Emacs or Emacs addons, Firefox, CPAN modules. Folks I know do or
> have done the same for Python versions, desktops, X-Windows
> implementations. There's really nothing Lisp-specific about the
> situation.
I use backports also for Firefox, PostgreSQL and compile XEmacs
entirely on my own, so, yes, in some respect this is true. This is,
however, for a totally different reason, e.g., if I install Firefox
from bpo, this is not because of some incompatible library versions
that force me to update seemingly unrelated software. But if you want
to use a modern lisp library, e.g. UCW, it might well be that sbcl in
stable is just too old. And with UCW being rather heavy under
development, it might well be, that in half a year, you'll be
recompiling sbcl again. I.e,, what I see as Lisp-specific is the
inmaturity of some of the newer software which increases the
problem[1] that Debian stable is never bleeding edge. I agree that
e.g. Gnome users have suffered similar problems in the past, however,
there situation has improved a lot, because the foundation (i.e. gtk-
and gnome-libraries and infrastructure) is now much more mature and
contained in reasonable recent versions in stable. That's what I meant
when I said that the situation is going to improve (wrt. the Lisp
libraries) with Etch.
Holger
Footnotes:
[1] Actually, I don't think that stable has a problem. It does what
it is designed to. If that's not what you want, then there are several
alternatives to choose from. And with Ubuntu, you can have a 'stable'
version of a dpkg/apt-based Linux distribution twice a year.
--
--- http://hillview.bugwriter.net/ ---
"Innenminister Schillstein hat gestern eine Anweisung erlassen, die
den Betrieb von Homefirewalls verbietet: `Die Umsetzung der europ�ischen
Brandschutzrichtlinie Nummer 1234 l��t uns keinen Spielraum: Die
Feuerwehr mu� st�ndig Zugriff auf die Wohnungselektronik haben.'"
-- Uwe Ohse in de.alt.sysadmin.recovery
Richard M Kreuter <·······@progn.net> writes:
> Holger Schauer <··············@gmx.de> writes:
>> On 4844 September 1993, Pascal Costanza wrote:
>
>>> But that sounds like a problem of Debian, not of Common Lisp,
>>> doesn't it?
>>
>> On first sight, yes, but not so on the second. One major
>> accomplishment of Debian is usually that shipped versions work and
>> typically that they're compatible with each other...
>
> I've used Debian stable for years, and while it is a nice platform in
> many ways, I always find myself needing to go outside the system for
> various things: PostgreSQL, Emacs or Emacs addons, Firefox, CPAN
> modules. Folks I know do or have done the same for Python versions,
> desktops, X-Windows implementations. There's really nothing
> Lisp-specific about the situation.
>
> --
> RmK
Debian stable is, well, extremely stable, but due to the slow release
cycle Debian has had, the stable disribution does tend to lag a bit
behind.
However, having said that, I've been running Debian testing for about
6 years and have rarely had any problems at all - minor glitches from
time to time that are usually resolved quite quickly and never
anything which has prevented me from working. for the past couple of
years, I've been running a hybrid testing/unstable distribution. The
Debian packaging system handles this very nicely. Essentially, you
can add the unstable source location to your configuration and if yo
install a package from unstable, Debian will continue to offer you
updates for that package form the unstable branch, but everything
else is from testing (unless the unstable package you have installed
depends on other packages in unstable).
I've done this so that I can get the emacs 22 snapshot from unstable
and run the latest slime. All works really well.
Tim
--
tcross (at) rapttech dot com dot au
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <mYfdh.13$7_2.12@newsfe09.lga>
Ian Jackson wrote:
> Obviously I could write my own answers but I want to concentrate on
> writing my application,
That thwack you just felt was your 2k word boomerang of condescension
coming back to get your attention.
Everyone (you the latest):
goes thru the learning curve,
howls at the rawness of CL, and
just tears into programming in CL.
The latter is why no one (you the latest):
does what you are telling "us" to do
But once a week:
someone is dumb enough to walk into the NG of a new language and
shoot their mouths off without taking a moment to get up to speed.
Had you done so you would have found me explaining all this to last
week's self-important finger-shaker.
Please don't take this the wrong way.
kt
ps. Jeff, Nikodemus, any way to get this into the FAQs? i think it just
passed modifying '(a b c). k
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
In article <···············@newsfe09.lga>,
Ken Tilton <·········@gmail.com> wrote:
>Everyone (you the latest):
> goes thru the learning curve,
> howls at the rawness of CL, and
Are you at all interested in trying to make that less of an unpleasant
experience ? Because I think you're overoptimistic when you say that
`everyone' then ....
> just tears into programming in CL.
Many people will be discouraged by the hurdles that I hope I'm helping
to identify and give up and never come back. And they'll tell all of
their colleagues how bad it was.
>But once a week:
> someone is dumb enough to walk into the NG of a new language and
> shoot their mouths off without taking a moment to get up to speed.
If you'd actually read my article you'd realise that I _did_ spend the
time to get up to speed. I was under the impression that the denizens
of this newsgroup might be interested to know how (from my point of
view) this process was difficult and by implication how it can be made
easier for the next person.
I'm glad to see that others beside yourself do seem to be interested
in making Lisp more attractive, so that people will choose to use it.
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
> I'm glad to see that others beside yourself do seem to be interested
> in making Lisp more attractive, so that people will choose to use it.
>
Hi Ian,
I checked out your website and see that you wrote Debian's dpkg. Since
you obviously have expertise in the package management arena, I would
be curious to hear your opinions on the current state of Lisp's package
management systems (ASDF and ASDF-install).
Cheers
Brad
In article <························@73g2000cwn.googlegroups.com>,
bradb <··············@gmail.com> wrote:
>I checked out your website and see that you wrote Debian's dpkg. Since
>you obviously have expertise in the package management arena, I would
>be curious to hear your opinions on the current state of Lisp's package
>management systems (ASDF and ASDF-install).
I'm afraid I haven't got to grips with asdf (or any of its
competitors) at all so I can't answer that question at all.
What I can say is this: I was most impressed with the
`common-lisp-controller' system which Debian use to solve many of
these problems in a more tightly controlled way, to make CL addon
packages easy to use in Debian (and Gentoo, a websearch now tells me).
IIRC it's based on asdf.
It `just worked' in a way that many Debian approaches to similar
problems have failed :-). (Debian's Python module support system, and
its Emacs Lisp addon system, have both had serious problems.)
I haven't got anywhere near making my own cl-* extension package so I
don't know how easy or error-prone that is, but I did come across what
seemed to be comprehensive documentation for how to do it, included in
the relevant Debian package.
http://www.cliki.net/common-lisp-controller seems relevant too.
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <vXjdh.2980$E91.2036@newsfe12.lga>
Ian Jackson wrote:
> In article <···············@newsfe09.lga>,
> Ken Tilton <·········@gmail.com> wrote:
>
>>Everyone (you the latest):
>> goes thru the learning curve,
>> howls at the rawness of CL, and
>
>
> Are you at all interested in trying to make that less of an unpleasant
> experience ?
Naw, fuck 'em. if they give up they are unworthy.
I think what you are missing is that:
it is a lot of work (making it easier)
you are not doing it either (because it is a lot of work)
in the end it will not increase Lisp mindshare because...
> Because I think you're overoptimistic when you say that
> `everyone' then ....
>
>
>> just tears into programming in CL.
The only people turned back by your experience are tire kickers, not
people really looking for A Better Way. If someone comes to Lisp because:
they have heard it is vastly better than other languages,
they see all sorts of nuts on c.l.l whooping it up, and
they have read the Road to Lisp
... do you think (how many hours?) of aggravation will stop them?
Barker: "Stairway to Heaven! Open to all! Come on up! One-day amnesty!"
Kenny: "No elevator?"
> Many people will be discouraged by the hurdles that I hope I'm helping
> to identify and give up and never come back. And they'll tell all of
> their colleagues how bad it was.
There is no such thing as bad publicity. Their colleagues will ask them
why they were looking at a dead language. They say, Omigod, have you
read The Road to Lisp? A week later the resulting assault team has a
free Lisp environment working and the one smart colleague went off on
her own, downloaded ACL Trial, and won a programming contest with CL.
>
>
>>But once a week:
>> someone is dumb enough to walk into the NG of a new language and
>> shoot their mouths off without taking a moment to get up to speed.
>
>
> If you'd actually read my article you'd realise that I _did_ spend the
> time to get up to speed.
No, sorry, I meant on this question of why it is so hard to get going on
Lisp. I am not kidding, your clone was in here last week or the week
before. I have to say, savaging you blowhards is starting to get as
tedious as a treadmill.
> I was under the impression that the denizens
> of this newsgroup might be interested to know how (from my point of
> view) this process was difficult and by implication how it can be made
> easier for the next person.
See above. We get blessed with this brilliant insight about once a week.
It is pretty funny, really. And if it makes you feel better, if the
archives go back to '95 you might find me saying the same thing, because
I had the exact same reaction -- and I even had the lovely MCL
integrated IDE, Freditor, and compiler all in one. I /know/ I thought
it, just not sure I posted it.
No, what we (that is the royal we) want you to do is stop pontificating
and get to work on the CFFI equivalent of a sockets lib. LispNYC's Perry
and someone here on c.l.l almost got started on one when SoC 2006 was
aborning.
Or even better, finish Fetter/Verrazano. It is almost there and would
open up every C/C++ library to CL a hundred times better than SWIG ever
will.
I know, I know, that would be so much more work than just lecturing a
non-existent community. Welcome to the club, you are now as ineffectual
as the rest of us Lispniks, smugly enjoying a great language and not
doing the heavy-lifting ti takes to grow the language.
>
> I'm glad to see that others beside yourself do seem to be interested
> in making Lisp more attractive, so that people will choose to use it.
>
They are just sucking up to you because you have some cred. These clowns
know nothing. I have been telling them about Cells (heaven itself) for
ten years and I have ten users. Take away Edi and Marc and I have
produced more valuable bindings and libraries alone than the entire group.
You are now the blind leading the blind. We do not need a free Lisp and
we do not need Emacs+Slime+ASDF For Dummies, because noobs do not get
that far. They just walk up to the store window, see the shelves are
bare of the libraries they just bolt together in other languages, and
keep on walking.
No kidding, finishing Verrazano would make up for all your sins.
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Pascal Costanza
Subject: SBCL 1.0, was Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <4tmbtjF14m188U1@mid.individual.net>
Ken Tilton wrote:
>> Many people will be discouraged by the hurdles that I hope I'm helping
>> to identify and give up and never come back. And they'll tell all of
>> their colleagues how bad it was.
>
> There is no such thing as bad publicity. Their colleagues will ask them
> why they were looking at a dead language. They say, Omigod, have you
> read The Road to Lisp? A week later the resulting assault team has a
> free Lisp environment working and the one smart colleague went off on
> her own, downloaded ACL Trial, and won a programming contest with CL.
At some stage, you have to make up your mind.
Not so long ago, you stated that the release of SBCL 1.0 has marked a
"sad day" and made you conclude that "Lisp loses because the best and
the brightest young Lisp turks are just trying to drive Franz and
Lispworks out of business when there is so much other amazing code to be
written." (Your words.)
Now you say that "there is no such thing as bad publicity."
What is it?
Pascal
[To give this a similar spin: People will ask why Lispers are spending
their time on a new open-source implementation when there are already
excellent commercial and open-source implementations available. They
say, Omigod, have you read The Road to Lisp? A week later... etc. pp. ;) ]
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ken Tilton
Subject: Re: SBCL 1.0, was Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <PYndh.3014$E91.280@newsfe12.lga>
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>> Many people will be discouraged by the hurdles that I hope I'm helping
>>> to identify and give up and never come back. And they'll tell all of
>>> their colleagues how bad it was.
>>
>>
>> There is no such thing as bad publicity. Their colleagues will ask
>> them why they were looking at a dead language. They say, Omigod, have
>> you read The Road to Lisp? A week later the resulting assault team has
>> a free Lisp environment working and the one smart colleague went off
>> on her own, downloaded ACL Trial, and won a programming contest with CL.
>
>
> At some stage, you have to make up your mind.
>
> Not so long ago, you stated that the release of SBCL 1.0 has marked a
> "sad day" and made you conclude that "Lisp loses because the best and
> the brightest young Lisp turks are just trying to drive Franz and
> Lispworks out of business when there is so much other amazing code to be
> written." (Your words.)
>
> Now you say that "there is no such thing as bad publicity."
>
> What is it?
This type of bullsh*t Usenet gotcha-play is exactly what gets you into
trouble on Usenet. I think you saw Garret doing it and decided it was a
good idea, probably why you both ended up on EN's sh*t list and mine.
"Gotcha" is like analogies, they lead to arguments about the gotchaness
of the gotcha, an exponential explosion guaranteed.
You will not be a real Lispnik until you can respond on c.l.l without
playing "Gotcha".
hth, kenny
ps. If it helps, no, I read what you wrote and could not understand a
word of it, which is why I am being careful to respond not to it but
instead to its litigiousness. k
pps. This applies also to some one-liner you addressed to me recently,
which I missed because you were in my killfile. That remark just reeked
of aggression, sand-bagging, and gotcha. You post like a troll. The
funny thing is, I was wondering how you had gotten into my killfile, now
I am wondering something else. k
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
> This type of bullsh*t Usenet gotcha-play is exactly what gets you into
> trouble on Usenet. I think you saw Garret doing it and decided it was a
> good idea, probably why you both ended up on EN's sh*t list and mine.
Actually Kenny out of all the regulars you seemed to be fairly highly
ranked on Erik sh*t list. This is well documented using google groups
search.
Here's some reminders:
http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/e15d85ac5626af9e?lnk=st&q=naggum+tilton+shit&rnum=1&hl=en#e15d85ac5626af9e
http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/166624ccb533656d?lnk=st&q=naggum+tilton+idiot&rnum=8&hl=en#166624ccb533656d
I really can't understand why you waste so much of your time posting
crap on this group.
Mike
From: Ken Tilton
Subject: Re: SBCL 1.0, was Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <oVodh.1711$TW1.1292@newsfe08.lga>
Mike T wrote:
> Ken Tilton wrote:
>
>>This type of bullsh*t Usenet gotcha-play is exactly what gets you into
>>trouble on Usenet. I think you saw Garret doing it and decided it was a
>>good idea, probably why you both ended up on EN's sh*t list and mine.
>
>
> Actually Kenny out of all the regulars you seemed to be fairly highly
> ranked on Erik sh*t list. This is well documented using google groups
> search.
<sigh> I begin to understand why the Chinese built that wall.
Actually Mike T you have no clue what you are saying. That thread is a
fucking love fest between Erik and I who got along quite well on Usenet.
But never mind that, because if you think about it hard enough, what you
said, even were it true, is a complete non sequitor.
>
> Here's some reminders:
> http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/e15d85ac5626af9e?lnk=st&q=naggum+tilton+shit&rnum=1&hl=en#e15d85ac5626af9e
>
> http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/166624ccb533656d?lnk=st&q=naggum+tilton+idiot&rnum=8&hl=en#166624ccb533656d
>
> I really can't understand why you waste so much of your time posting
> crap on this group.
It's the fan mail from flounders like you.
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> [snipped]
>
> <sigh> I begin to understand why the Chinese built that wall.
>
> Actually Mike T you have no clue what you are saying. That thread is a
> fucking love fest between Erik and I who got along quite well on Usenet.
>
> But never mind that, because if you think about it hard enough, what you
> said, even were it true, is a complete non sequitor.
>
> >
> > Here's some reminders:
> > http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/e15d85ac5626af9e?lnk=st&q=naggum+tilton+shit&rnum=1&hl=en#e15d85ac5626af9e
> >
> > http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/166624ccb533656d?lnk=st&q=naggum+tilton+idiot&rnum=8&hl=en#166624ccb533656d
> >
> > I really can't understand why you waste so much of your time posting
> > crap on this group.
>
> It's the fan mail from flounders like you.
Well as Erik would say:
"What is your major malfunction, numbnut?"
http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/743a336328626e85/1ff27b241408bee9?lnk=st&q=tilton+naggum+newbies+floorboards&rnum=1&hl=en#1ff27b241408bee9
Best wishes
From: Ken Tilton
Subject: Re: SBCL 1.0, was Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <6Kpdh.3036$E91.1100@newsfe12.lga>
Mike T wrote:
> Ken Tilton wrote:
>
>>[snipped]
>>
>><sigh> I begin to understand why the Chinese built that wall.
>>
>>Actually Mike T you have no clue what you are saying. That thread is a
>>fucking love fest between Erik and I who got along quite well on Usenet.
>>
>>But never mind that, because if you think about it hard enough, what you
>>said, even were it true, is a complete non sequitor.
>>
>>
>>>Here's some reminders:
>>>http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/e15d85ac5626af9e?lnk=st&q=naggum+tilton+shit&rnum=1&hl=en#e15d85ac5626af9e
>>>
>>>http://groups.google.co.uk/group/comp.lang.lisp/browse_frm/thread/707067b1ace5fd18/166624ccb533656d?lnk=st&q=naggum+tilton+idiot&rnum=8&hl=en#166624ccb533656d
>>>
>>>I really can't understand why you waste so much of your time posting
>>>crap on this group.
>>
>>It's the fan mail from flounders like you.
>
>
> Well as Erik would say:
>
> "What is your major malfunction, numbnut?"
Jeez, Thompson, get the citation right, will ya?
http://www.moviesoundscentral.com/sounds/full_metal_jacket/numbnuts.wav
In your excitement over having been personally savaged by The Kenny, you
neglected to pick up my drift: that thread is a dialogue about
technology, with incidental mud-slinging to keep you lowbrows awake. It
stays on topic and never descends into the ad homineum mud your kind
finds so attractive. Even the dog crack was an echo of one I had made at
my own mistake.
You know, the last thing Erik said to me in our email exchanges (I'll
wait while you pick your sorry ass off the floor) was not to the sink to
the level of idiots like you. Right again, Erik.
<PLONK>
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Mike T wrote:
> I really can't understand why you waste so much of your time posting
> crap on this group.
He does it because otherwise I'd have to, and I'm *much* nastier than
Kenny.
From: Ken Tilton
Subject: Re: SBCL 1.0, was Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <4bXfh.26$C51.13@newsfe08.lga>
Tim Bradshaw wrote:
> Mike T wrote:
>
>
>>I really can't understand why you waste so much of your time posting
>>crap on this group.
>
>
> He does it because otherwise I'd have to, and I'm *much* nastier than
> Kenny.
>
Well suit up cuz it's time for me to take a bradshaw* and get some
algebra code out the door.
ken
* brad'-shaw (n): 1. Self-imposed "Just Say No" exile from c.l.l.**
** Holy crap, even my jokes are accurate: "The colloquial term for
Bradshaw's Monthly Railway Guide, a periodical publication containing
railway schedules for Great Britain, first produced in 1839 by George
Bradshaw." http://irfca.org/faq/faq-jargon.html
k
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
>
> ** Holy crap, even my jokes are accurate: "The colloquial term for
> Bradshaw's Monthly Railway Guide, a periodical publication containing
> railway schedules for Great Britain, first produced in 1839 by George
> Bradshaw." http://irfca.org/faq/faq-jargon.html
No relation (as far as I know)...
From: Pascal Costanza
Subject: Re: SBCL 1.0, was Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <4tmh14F136fibU1@mid.individual.net>
Ken Tilton wrote:
>
>
> Pascal Costanza wrote:
>> Ken Tilton wrote:
>>
>>>> Many people will be discouraged by the hurdles that I hope I'm helping
>>>> to identify and give up and never come back. And they'll tell all of
>>>> their colleagues how bad it was.
>>>
>>>
>>> There is no such thing as bad publicity. Their colleagues will ask
>>> them why they were looking at a dead language. They say, Omigod, have
>>> you read The Road to Lisp? A week later the resulting assault team
>>> has a free Lisp environment working and the one smart colleague went
>>> off on her own, downloaded ACL Trial, and won a programming contest
>>> with CL.
>>
>>
>> At some stage, you have to make up your mind.
>>
>> Not so long ago, you stated that the release of SBCL 1.0 has marked a
>> "sad day" and made you conclude that "Lisp loses because the best and
>> the brightest young Lisp turks are just trying to drive Franz and
>> Lispworks out of business when there is so much other amazing code to
>> be written." (Your words.)
>>
>> Now you say that "there is no such thing as bad publicity."
>>
>> What is it?
>
> This type of bullsh*t Usenet gotcha-play is exactly what gets you into
> trouble on Usenet. I think you saw Garret doing it and decided it was a
> good idea, probably why you both ended up on EN's sh*t list and mine.
>
> "Gotcha" is like analogies, they lead to arguments about the gotchaness
> of the gotcha, an exponential explosion guaranteed.
OK, you're right. I apologize.
Pascal
--
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Ken Tilton
Subject: Re: SBCL 1.0, was Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <tRpdh.3037$E91.1649@newsfe12.lga>
Pascal Costanza wrote:
> Ken Tilton wrote:
>
>>
>>
>> Pascal Costanza wrote:
>>
>>> Ken Tilton wrote:
>>>
>>>>> Many people will be discouraged by the hurdles that I hope I'm helping
>>>>> to identify and give up and never come back. And they'll tell all of
>>>>> their colleagues how bad it was.
>>>>
>>>>
>>>>
>>>> There is no such thing as bad publicity. Their colleagues will ask
>>>> them why they were looking at a dead language. They say, Omigod,
>>>> have you read The Road to Lisp? A week later the resulting assault
>>>> team has a free Lisp environment working and the one smart colleague
>>>> went off on her own, downloaded ACL Trial, and won a programming
>>>> contest with CL.
>>>
>>>
>>>
>>> At some stage, you have to make up your mind.
>>>
>>> Not so long ago, you stated that the release of SBCL 1.0 has marked a
>>> "sad day" and made you conclude that "Lisp loses because the best and
>>> the brightest young Lisp turks are just trying to drive Franz and
>>> Lispworks out of business when there is so much other amazing code to
>>> be written." (Your words.)
>>>
>>> Now you say that "there is no such thing as bad publicity."
>>>
>>> What is it?
>>
>>
>> This type of bullsh*t Usenet gotcha-play is exactly what gets you into
>> trouble on Usenet. I think you saw Garret doing it and decided it was
>> a good idea, probably why you both ended up on EN's sh*t list and mine.
>>
>> "Gotcha" is like analogies, they lead to arguments about the
>> gotchaness of the gotcha, an exponential explosion guaranteed.
>
>
> OK, you're right. I apologize.
No problemo. peace, out. k
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ar an cúigiú lá de mí na Nollaig, scríobh Ken Tilton:
> [...] The only people turned back by your experience are tire kickers,
> not people really looking for A Better Way. If someone comes to Lisp
> because: they have heard it is vastly better than other languages, they
> see all sorts of nuts on c.l.l whooping it up, and they have read the
> Road to Lisp
I’m intrested in real Lisp because I’m developing XEmacs, and because in
XEmacs Lisp, if you’re emulating Common Lisp style, you’re writing better
code than otherwise. I am exceptional in this, certainly, but the
conclusions Ian draws are also applicable to me, and I think that depending
on those who are already committed to a language to support a particular
implementation is defeatist at best, from the perspective of that
implementation and of that language.
> [...] You are now the blind leading the blind. We do not need a free Lisp
> and we do not need Emacs+Slime+ASDF For Dummies, because noobs do not get
> that far. They just walk up to the store window, see the shelves are bare
> of the libraries they just bolt together in other languages, and keep on
> walking.
I _fucking hate_ Perl. It’s unmaintainable--by which I mean, the interpreter
has far too much tolerance for alternative, endorsed ways of saying the same
thing, so if I hand a program to someone else and come back in a year it’s
incomprehensible--and confusing in its documentation; but I use it
constantly because its libraries (CPAN) mean I don’t have to implement MIME
(with good suppport for a long list of character sets) and HTTP again in the
language I would otherwise prefer to use. Ditto several other languages.
The barriers to entry for a language matter. You can ignore that, and you
will get a circle of self-reinforcing zealots as your languages users, and
hear very little about the question again. Or, you could promote _the
language,_ rather than your own opinons as to how great and leet it is.
--
Santa Maradona, priez pour moi!
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <aNndh.3012$E91.1452@newsfe12.lga>
Aidan Kehoe wrote:
> Ar an cúigiú lá de mí na Nollaig, scríobh Ken Tilton:
>
> > [...] The only people turned back by your experience are tire kickers,
> > not people really looking for A Better Way. If someone comes to Lisp
> > because: they have heard it is vastly better than other languages, they
> > see all sorts of nuts on c.l.l whooping it up, and they have read the
> > Road to Lisp
>
> I’m intrested in real Lisp because I’m developing XEmacs, and because in
> XEmacs Lisp, if you’re emulating Common Lisp style, you’re writing better
> code than otherwise. I am exceptional in this, certainly, but the
> conclusions Ian draws are also applicable to me, and I think that depending
> on those who are already committed to a language...
Cool, you got "already committed" from "having visited
http://wiki.alu.org/RtL_Highlight_Film"? We might need you for an
upcoming study correlating Broca's Area volume with pointless Usenet
comments.
> to support a particular
> implementation is defeatist at best, from the perspective of that
> implementation and of that language.
>
> > [...] You are now the blind leading the blind. We do not need a free Lisp
> > and we do not need Emacs+Slime+ASDF For Dummies, because noobs do not get
> > that far. They just walk up to the store window, see the shelves are bare
> > of the libraries they just bolt together in other languages, and keep on
> > walking.
>
> I _fucking hate_ Perl. It’s unmaintainable--by which I mean, the interpreter
> has far too much tolerance for alternative, endorsed ways of saying the same
> thing, so if I hand a program to someone else and come back in a year it’s
> incomprehensible--and confusing in its documentation; but I use it
> constantly because its libraries (CPAN) mean I don’t have to implement MIME
> (with good suppport for a long list of character sets) and HTTP again in the
> language I would otherwise prefer to use. Ditto several other languages.
Is there someone there who can explain to you that you just said is
verbatim what I said? And we /will/ want you for the Broca's Area study.
>
> The barriers to entry for a language matter. You can ignore that, and you
> will get a circle of self-reinforcing zealots as your languages users,...
Why does that sound so good after the past few days?
> and
> hear very little about the question again. Or, you could promote _the
> language,_ rather than your own opinons as to how great and leet it is.
Promote the language?! I am a commercial application developer using
Lisp as my secret edge, which is why I spend a considerable amount of
time walking the wire chasing away noobs.
As for this being just my opinion, damn, where is it... anybody got a
link to the RtL? TIA.
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Robert Uhl
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m3y7pkg6t5.fsf@latakia.dyndns.org>
Ken Tilton <·········@gmail.com> writes:
>
> We do not need a free Lisp and we do not need Emacs+Slime+ASDF For
> Dummies, because noobs do not get that far. They just walk up to the
> store window, see the shelves are bare of the libraries they just bolt
> together in other languages, and keep on walking.
What's wrong with bolting together libraries? Sure, it's not creating,
but it's a useful activity. Not all are called to be library-writers;
not all are called to be library-users.
--
Robert Uhl <http://public.xdi.org/=ruhl>
One interesting feature of Latin is that you ROT13 it and get Welsh. --Peter
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <zLGdh.208$ZP3.22@newsfe09.lga>
Robert Uhl wrote:
> Ken Tilton <·········@gmail.com> writes:
>
>>We do not need a free Lisp and we do not need Emacs+Slime+ASDF For
>>Dummies, because noobs do not get that far. They just walk up to the
>>store window, see the shelves are bare of the libraries they just bolt
>>together in other languages, and keep on walking.
>
>
> What's wrong with bolting together libraries? Sure, it's not creating,
> but it's a useful activity. Not all are called to be library-writers;
> not all are called to be library-users.
>
Admit it. You guys are deliberately completely misparsing natural
language just to see my funny comebacks.
:)
Can somebody help Robert?
kzo
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote [on c.l.l]:
> Or even better, finish Fetter/Verrazano. It is almost there and would
> open up every C/C++ library to CL a hundred times better than SWIG ever
> will.
Kenny, I don't see any licensing information on the Verrazano page or
in the project proposal. What license is the code distributed under?
-David Huebel
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <dvseh.370$_t3.197@newsfe12.lga>
grackle wrote:
> Ken Tilton wrote [on c.l.l]:
>
>>Or even better, finish Fetter/Verrazano. It is almost there and would
>>open up every C/C++ library to CL a hundred times better than SWIG ever
>>will.
>
>
> Kenny, I don't see any licensing information on the Verrazano page or
> in the project proposal. What license is the code distributed under?
Wow, you are right, I do not see anything anywhere. The Google Summer of
Code requirements were that the project be open source, but several such
licenses were acceptable.
Rayiner seems to have moved on from vzn, but we could try asking him to
add a license and pass along the c-l.net admin privs. c-l.net also has
an open source requirement, maybe they have some documentation.
Rayiner seems to be active on gmane.comp.lang.dylan.gwydion.devel as of
last month. Anyone interested in picking up vzn could try emailing him,
or I could. I have tried in the past, but not at the email address I see
on gmane.
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ken Tilton wrote:
> Rayiner seems to have moved on from vzn, but we could try asking him to
> add a license and pass along the c-l.net admin privs. c-l.net also has
> an open source requirement, maybe they have some documentation.
Please do ask him to attach a license. If the license allows
distribution of closed-source commercial apps built with Verrazano, I
will be interested in using it and doing whatever work is necessary to
enable my use of it. (Geez, I sound like such a Scrooge, but that's
the truth :-(
-David
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <6JFeh.49$1x6.37@newsfe09.lga>
grackle wrote:
> Ken Tilton wrote:
>
>>Rayiner seems to have moved on from vzn, but we could try asking him to
>>add a license and pass along the c-l.net admin privs. c-l.net also has
>>an open source requirement, maybe they have some documentation.
>
>
> Please do ask him to attach a license. If the license allows
> distribution of closed-source commercial apps built with Verrazano, I
> will be interested in using it and doing whatever work is necessary to
> enable my use of it.
I cc'ed you on the email. If we do not hear back, we can try Google and
c-l.net to see if they have any correspondence. If all else fails...
While working on my Antlr-based C-to-lisp translator it occurred to me
that I could easily use it to produce some pretty sweet bindings,
including even noticing how pointers were used (null terminated string?
secondary return values?) by looking inside the API function to see what
it did with a parameter. I'd give that code up for a virtual beer. :)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Alain Picard
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <87y7phbrei.fsf@memetrics.com>
jayessay <······@foo.com> writes:
> limitation (even very advanced stuff). If you ever 1) get to the
> point where you have (more or less) mastered CL and 2) want to use it
> for a large industrial strength application, you can then revisit
> whether or not it makes sense to buy the package or start hacking at
> making some of the "free" junk "work".
How fantastically obnoxious.
Here is a guy showing up, with 25 years of programming experience
under his belt. He's done serious, important work for the Debian
project. And you turn around and derogatorily refer to free software
as free "junk", and imply that it barely "works".
Are you listening to yourself? Do you know how you come across?
Ian -- don't give up on CL. The language, and pretty much all of
the implementations you'll lie your hands on, are of far greater
quality than most of the "responses" you've received in this forum
so far. I welcome you as a new CL hacker, and hope you will raise
the average tone of this newsgroup! [Come to think of it -- scratch
that -- you already have!]
Alain Picard
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <ZDseh.371$_t3.174@newsfe12.lga>
Alain Picard wrote:
> jayessay <······@foo.com> writes:
>
>
>>limitation (even very advanced stuff). If you ever 1) get to the
>>point where you have (more or less) mastered CL and 2) want to use it
>>for a large industrial strength application, you can then revisit
>>whether or not it makes sense to buy the package or start hacking at
>>making some of the "free" junk "work".
>
>
> How fantastically obnoxious.
>
> Here is a guy showing up, with 25 years of programming experience
> under his belt. He's done serious, important work for the Debian
> project. And you turn around and derogatorily refer to free software
> as free "junk", and imply that it barely "works".
>
> Are you listening to yourself? Do you know how you come across?
Like me? :)
>
>
> Ian -- don't give up on CL. The language, and pretty much all of
> the implementations you'll lie your hands on, are of far greater
> quality than most of the "responses" you've received in this forum
> so far. I welcome you as a new CL hacker, and hope you will raise
> the average tone of this newsgroup! [Come to think of it -- scratch
> that -- you already have!]
Lawdy, what is this, the Second Coming? If the guy is any good, HTH can
he pass on CL? After all, he has already gotten over the hard part,
getting the free junk to work. :)
Me, I saw the comment about it being unlikely anyone would ever want to
use a book to explore a new language and, unable to think of any
language I explored /without/ using a book, I started thinking "troll".
:)
ken
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Ian Jackson wrote:
<snipped>
Welcome.
I'd advise you to ignore KT. He's obviously smart, but a little
too religous to take seriously. His contributions to cll are minimal
and can be safely ignored as he very carefully sidesteps any
lisp topic and launches into his ideological crusades.
The fact that he obviously doesn't know what condescension
means (see his reply above) should've tipped you off :-).
> >But once a week:
> > someone is dumb enough to walk into the NG of a new language and
> > shoot their mouths off without taking a moment to get up to speed.
>
> If you'd actually read my article you'd realise that I _did_ spend the
> time to get up to speed. I was under the impression that the denizens
> of this newsgroup might be interested to know how (from my point of
> view) this process was difficult and by implication how it can be made
> easier for the next person.
KT is insecure and feels threatened by FOSS. Merely mentioning
it brings ill-spelled and logically-disconnected tirades from him
about why private enterprise has the right to your pocket without
any competition from free enterprises.
If you think I am joking, please search google groups.
>
> I'm glad to see that others beside yourself do seem to be interested
> in making Lisp more attractive, so that people will choose to use it.
>
Don't make your mind up too soon though. Seemingly ordinary, nice
people (Robert Uhl, Tim Bradshaw, etc) tend to not be as zealous as KT,
nor as disconnected from reality but they will happily tolerate his
insecurity and childish rantings.
The best thing to do is to ignore him; he's insignificant, insecure and
bitter - always a nasty combination.
goose,
From: Don Geddis
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <87zma2uq9h.fsf@geddis.org>
Ian Jackson <········@chiark.greenend.org.uk> wrote on 05 Dec 2006 01:0:
> A comprehensive resource aimed at contemporary non-Lisp programmers
> is urgently needed. I was going to started an article on the CLiki
> with some pointers and discussion, but as I've written this article
> I've realised that the answers I have found are not really usefully
> transferrable to other people new to Lisp unless they have
> circumstances very like my own.
You seem to have answered your own question. You couldn't find a tutorial
that directly addressed your personal circumstances, but at the same time
you now realize that such a tutorial, if it had existed, would have been of
little use to anyone EXCEPT you.
No doubt that very limited audience is why that specific tutorial did not
exist.
> * Support for Common Lisp development in Debian stable is
> surprisingly poor, given how mature the Lisp world is.
It's an odd choice you made, to insist on "Debian stable". The stable branch
of Debian is well known for being years out of date. In some sense, the newer
Ubuntu distribution is really just Debian with a quicker cycle of "stable"
releases; there wouldn't have been motivation to make Ubuntu if Debian's
release policy wasn't so slow.
It so happens that a great amount of progress has been made on Lisp
implementations in Debian in the last few years. So much of your difficulty
on this score is more a problem with Debian stable, than it is a problem with
the lisp world. Many of your reported difficulties have ALREADY been solved
today; they just happen not to be in the ancient distribution of Debian
labelled "stable".
> When I first settled on learning CL I thought I would read a standard
> reference work. This is my usual way of approaching new programming
> languages - I'm one of the minority of people who find they get on very
> well with reference manuals, and find tutorials distressingly vague
> about details.
>
> A Lisp-using friend lent me their copy of CLtL2, and I started reading
> through that.
A poor choice, unfortunately, since that text is far out of date.
> My next approach was to try to read the Hyperspec through. Well, I'm
> still doing that - but the Hyperspec is poorly structured for this.
> The number of forward references is much higher than for most other
> language specifications.
I find this complaint kind of odd. The ANSI spec is explicitly written to
an audience of Lisp implementors, NOT as a tutorial for a newbie to Lisp.
That's what tutorials are for.
And yet you rejected all texts that were addressed to your situation, chose
to attempt a text that was explicitly NOT addressed to you, and then got
frustrated when you found that it didn't work well for you?
It seems like your causing some of your own difficulties here...
> One particularly silly situation was that the sbcl in Debian stable was too
> old for unstable's slime and the sbcl in Debian unstable had a
> build-dependency only satisfiable by the sbcl in unstable ! I was able to
> solve this by bootstrapping with an sbcl binary package from backports.org.
More trouble because of your desire to stick with Debian stable. That
original choice was probably an error, and any reasonable tutorial (or more
experienced friend) would NOT have recommended it.
> I'm posting here to try to document some of the things that make it
> difficult for even an experienced programmer to get involved with
> Common Lisp. If the entrance barriers could be lowered, I think you
> might find it easier to encourage new and useful people to join the
> Lisp community.
I bet you would have had a very different experience if someone had been able
to guide you to this at the start:
"Practical Common Lisp" tutorial by Peter Seibel
Emacs + SLIME
Debian "testing"
SBCL
instead of CLtL2, Hyperspec, Vi, Debian stable, and implementation questions.
Some of your difficulties would still have been there, but probably half of
them would have just vanished immediately.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Normally I don't believe in miracles, but something happened when I was about
seven years old I still can't explain. I was on the front porch with Grandpa,
about to eat my Twinkies, when Grandpa started grabbing his chest and saying he
was having a heart attack. I ran to get Mom, but when I got back, Grandpa was
okay. "An angel helped me," he said. "Also, he ate your Twinkies."
-- Deep Thoughts, by Jack Handey [1999]
Ian Jackson wrote:
> I had to write a function to convert a string of bytes (as produced by
> cl-md5) to hex. Newer (non-broken!) hash functions and so on don't
> seem to be available at all.
You might have already found this, but Ironclad
(http://www.cliki.net/Ironclad) has several non-broken hash functions
in it. It even includes byte-array-to-hex-string. I believe it's
packaged in Debian under 'cl-ironclad'.
Unfortunately, you will have to resort to the 'extract docstrings
manually' approach to the documentation, but it is there.
-Nathan
From: Wade Humeniuk
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <FLfdh.27584$rv4.18615@edtnps90>
Ian Jackson wrote:
> As an experienced programmer, I've heard a lot about how good Lisp is,
> and I like getting to grips with new languages. After conversations
> with friend who's keen I decided I should learn Common Lisp.
>
> I thought I'd share some of my experiences here. While much of what
> I'm going to say is critical, I'd like to emphasize that I'm not
> giving up on Lisp. I like what I've seen so far, and the hurdles are
> more entrance barriers than they are problems for serious work - but
> they are quite time-consuming, and nowadays we are all in a hurry.
Would be so kind to share some additional information about
your efforts?
1) What kind of experience programming do you have?
2) How long have you spent learning CL? Hours, days, weeks, years??
3) Why did you decide to learn CL?
4) I do not understand what you mean by "from a Unix perspective".
(Besides the problem of the Debian packages not being up to date,
and really having to use emacs).
(Since you mentioned Debian I assume by Unix you mean Linux).
W
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <_tidh.7127$7_2.2058@newsfe09.lga>
Wade Humeniuk wrote:
> Ian Jackson wrote:
>
>> As an experienced programmer, I've heard a lot about how good Lisp is,
>> and I like getting to grips with new languages. After conversations
>> with friend who's keen I decided I should learn Common Lisp.
>>
>> I thought I'd share some of my experiences here. While much of what
>> I'm going to say is critical, I'd like to emphasize that I'm not
>> giving up on Lisp. I like what I've seen so far, and the hurdles are
>> more entrance barriers than they are problems for serious work - but
>> they are quite time-consuming, and nowadays we are all in a hurry.
>
>
> Would be so kind to share some additional information about
> your efforts?
>
> 1) What kind of experience programming do you have?
> 2) How long have you spent learning CL? Hours, days, weeks, years??
...and...
> 2a) How many hours (roughly) it took to get over the hump described
in the original rant?
kt
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
In article <·····················@edtnps90>,
Wade Humeniuk <··················@telus.net> wrote:
>1) What kind of experience programming do you have?
I've been programming since around 1980 and (as far as languages go) I
am expert in C, Tcl, bash, Perl and have varying levels of experience
in Haskell, Elisp, Python, Postscript, assembly languages, etc. etc.
>2) How long have you spent learning CL? Hours, days, weeks, years??
It's difficult to know exactly; I haven't been keeping a record.
The time I spent actually learning the Common Lisp language itself is
particularly hard to quantify but I've been dabbling on and off for a
month or two. I think I have probably spent the equivalent of several
days fighting incompatible software versions, hunting around on the
Internet for documentation, etc.
>3) Why did you decide to learn CL?
I thought I had adequately explained that in my previous article.
>4) I do not understand what you mean by "from a Unix perspective".
> (Besides the problem of the Debian packages not being up to date,
> and really having to use emacs).
> (Since you mentioned Debian I assume by Unix you mean Linux).
I mean that I want to treat Lisp like any of the other programming
languages on my existing Unix system. Or to put it another way, I
want to exclude two other perspectives which seem common: firstly
that CL should be treated like an operating system, and secondly the
perspective of Windows users.
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
Ian Jackson wrote:
> I mean that I want to treat Lisp like any of the other programming
> languages on my existing Unix system. Or to put it another way, I
> want to exclude two other perspectives which seem common: firstly
> that CL should be treated like an operating system, and secondly the
> perspective of Windows users.
Do you want a pony with that?
Lisp is not *like* any of the other programming languages on your
existing Unix system. One important reason for this is that Lisp was
born a decade before Unix ever existed, much less became widespread. In
fact, features like pathnames in Common Lisp turned out the way they
are because they needed to support multiple file systems with non-Unix
semantics.
If you are taking guitar lessons, do you similarly feel you should
treat it just like the violins and trumpets of your existing symphony
orchestra?
Common Lisp was my primary programming language for several years, back
in the late 80s. I remember it fondly and every once in a while I
wonder if I couldn't start using it again.
Posts like this are sure a good cure for thoughts like that.
··············@hotmail.com wrote:
> Ian Jackson wrote:
>
> > I mean that I want to treat Lisp like any of the other programming
> > languages on my existing Unix system. Or to put it another way, I
> > want to exclude two other perspectives which seem common: firstly
> > that CL should be treated like an operating system, and secondly the
> > perspective of Windows users.
>
> Do you want a pony with that?
>
> Lisp is not *like* any of the other programming languages on your
> existing Unix system. One important reason for this is that Lisp was
> born a decade before Unix ever existed, much less became widespread. In
> fact, features like pathnames in Common Lisp turned out the way they
> are because they needed to support multiple file systems with non-Unix
> semantics.
>
> If you are taking guitar lessons, do you similarly feel you should
> treat it just like the violins and trumpets of your existing symphony
> orchestra?
·······@gmail.com wrote:
> Common Lisp was my primary programming language for several years, back
> in the late 80s. I remember it fondly and every once in a while I
> wonder if I couldn't start using it again.
>
> Posts like this are sure a good cure for thoughts like that.
Why does my opinion about Ian Jackson's attitude have anything in the
slightest to do with your choice to use a language which you already
know how to program in?
··············@hotmail.com wrote:
> ·······@gmail.com wrote:
> > Common Lisp was my primary programming language for several years, back
> > in the late 80s. I remember it fondly and every once in a while I
> > wonder if I couldn't start using it again.
> >
> > Posts like this are sure a good cure for thoughts like that.
>
> Why does my opinion about Ian Jackson's attitude have anything in the
> slightest to do with your choice to use a language which you already
> know how to program in?
You're coming off like a petulant jerk, and I simply don't need to hear
it. Also, if you're to be believed, CL doesn't really fit in with a
Unix (Linux) environment. I don't buy this at all, but if I was forced
to choose between the two, it'd be Linux every day of the year.
My point is: If Lisp is to have any hope of a renaissance, it will need
friendly people advocating it, and it will need to fit in with its
friends, such as Linux.
Mike
·······@gmail.com wrote:
> ··············@hotmail.com wrote:
> > ·······@gmail.com wrote:
> > > Common Lisp was my primary programming language for several years, back
> > > in the late 80s. I remember it fondly and every once in a while I
> > > wonder if I couldn't start using it again.
> > >
> > > Posts like this are sure a good cure for thoughts like that.
> >
> > Why does my opinion about Ian Jackson's attitude have anything in the
> > slightest to do with your choice to use a language which you already
> > know how to program in?
>
> You're coming off like a petulant jerk, and I simply don't need to hear
> it.
Why does my being a jerk, even if true, have an effect on your use of
the language? There are jerks using every imaginable language.
> Also, if you're to be believed, CL doesn't really fit in with a
> Unix (Linux) environment. I don't buy this at all, but if I was forced
> to choose between the two, it'd be Linux every day of the year.
Look, what I responded to was Ian Jackson's desire for Lisp to be like
"every other
language" on his UNIX box. Lisp is just not like Fortran, which
predates UNIX, or like C, which is contemporary with UNIX, or with any
of the many languages (UNIX shells, awk, sed, perl, python, ruby, java.
..) which were basically invented when UNIX was a major environment,
and were designed from the beginning to be compatible with UNIX.
The fact is that UNIX is a minimalist environment, and it will never
fullly support Lisp in the way it supports C. Rainer Joswig had an
excellent post a while back explaining the many real reasons why not.
To believe otherwise is to ignore historical and technological reality.
> My point is: If Lisp is to have any hope of a renaissance, it will need
> friendly people advocating it, and it will need to fit in with its
> friends, such as Linux.
If being "friendly" means supporting hopeless and uninformed dreaming
or unrealistic expectations, I don't see how that helps anyone. It is
just setting people up for later disappointment. Better to be straight
about what is and is not realistic in Lisp. Lisp is a great programming
language, but it isn't a silver bullet, and it isn't going to make the
world a perfect place. And that is not the fault of the language.
If SBCL or CLISP or CMUCL on Linux-x86 are good enough for your needs,
then it fits in Linux fine. But it will never be like GCC or Perl in
its fit with Linux. That's just the facts.
From: Robert Uhl
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m364c6weg4.fsf@latakia.dyndns.org>
···············@hotmail.com" <············@gmail.com> writes:
>
> Why does my being a jerk, even if true, have an effect on your use of
> the language? There are jerks using every imaginable language.
Because folks won't persist in trying something when the threshold to do
so is too high. Assholes raise the threshold to learn a language; thus
they decrease the number of folks using it.
Using pulled-from-air numbers, if using Lisp saves one $10,000/year, but
the development environments cost $2,000/year and the Lisp community is
$9,000/year less helpful than Blub community, then one ought to stick to
Blub.
And even folks who already know & use Lisp should care, as more
fellow-users means a larger community means more libraries and tools
means more synergy means more competition in the tools market means
development tools costing more like GCC or Microsoft's suite and less
like circa-1986 C compilers.
--
Robert Uhl <http://public.xdi.org/=ruhl>
The problem with 'post-modern' society is there are too many people with
nothing meaningful to do, building 'careers' around controlling the lives of
others and generally making social nuisances of themselves.
--Graham Strachan
·······@gmail.com ¼g¹D¡G
> You're coming off like a petulant jerk, and I simply don't need to hear
> it. Also, if you're to be believed, CL doesn't really fit in with a
> Unix (Linux) environment. I don't buy this at all, but if I was forced
> to choose between the two, it'd be Linux every day of the year.
>
> My point is: If Lisp is to have any hope of a renaissance, it will need
> friendly people advocating it, and it will need to fit in with its
> friends, such as Linux.
It might be out of topic but I think CL fits in with a Unix
environment better than Windows environment.
Ian Jackson <········@chiark.greenend.org.uk> wrote in
··············@news.chiark.greenend.org.uk:
> In article <·····················@edtnps90>,
> Wade Humeniuk <··················@telus.net> wrote:
. etc.
>
>>2) How long have you spent learning CL? Hours, days, weeks, years??
>
> It's difficult to know exactly; I haven't been keeping a record.
> The time I spent actually learning the Common Lisp language itself is
> particularly hard to quantify but I've been dabbling on and off for a
> month or two. I think I have probably spent the equivalent of several
> days fighting incompatible software versions, hunting around on the
> Internet for documentation, etc.
>
2 months?
after 2 years your mind will probably change.
Lisp is a byte-the-bullet technology. Some say you need at least 10 years
to master it.
From: Ken Tilton
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <Sgmdh.2994$E91.1403@newsfe12.lga>
> Ian Jackson <········@chiark.greenend.org.uk> wrote in
> ··············@news.chiark.greenend.org.uk:
>
>> I think I have probably spent the equivalent of several
>>days fighting incompatible software versions, hunting around on the
>>Internet for documentation, etc.
And another day ranting about how hard it was which it would not have
been had you bought Lispworks Pro* for $1500. And then, good God, look
at what you get with it that does not come with "free" Lisps:
http://www.lispworks.com/products/features.html#editionfeatures
Not sure how you price your days, but hopefully you are kicking yourself
by now (I mean I hope you price your days higher than $375).
OK, everyone over on the SBCL thread is probably wondering where to send
their apologies and concede my point... :)
kt
* Not sure what deal you'd get on the even better ACL Pro and whether
you can live with the licensing royalty they want.
k
--
Algebra: http://www.tilton-technology.com/LispNycAlgebra1.htm
"Well, I've wrestled with reality for thirty-five
years, Doctor, and I'm happy to state I finally
won out over it." -- Elwood P. Dowd
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
From: Robert Maas, see http://tinyurl.com/uh3t
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <REM-2006dec05-005@Yahoo.Com>
> From: Ian Jackson <········@chiark.greenend.org.uk>
> * Documentation for introducing Lisp to existing programmers is poor;
> existing tutorials are old or at least outdated.
IMO, tutorials should be "hands on", where the newcomer gets to
actually try stuff and see it work (or get explanations what's
wrong when it's not working). I.e. more than just a "tutorial",
more like a CAI (Computer-Assisted Instruction) class.
I would like to make such a super-tutorial myself, but I need a
guinea pig, somebody willing to try it as I work on it, and give me
prompt feedback how it's working. Do you know anyone willing to
give it a try?
> * Infrastructure for performing tasks which are routine in
> modern programming is often lacking and/or hard to find.
The software infrastructure is already there for a lot of common
tasks. For example, look at the chapters on hash tables, and
string/sequence operations. Serializing/deserializing is trivial
using print and read. Please list several examples of routine tasks
that Common Lisp does *not* include built-in, so that we can
address the specifics.
Sometime in the past few years I've seen mention of a "cookbook"
that somebody was going to compose. I looked at the proposed table
of contents and noticed that it skipped right past the really easy
stuff that stumps beginners, and I suggested those really easy
tasks be covered first.
(In fact I have suggested a universal "cookbook" be composed which
for each task shows how to do it in several different common
languages. So-far I've started work on that composition for a
single task: Decoding urlencoded HTML form contents for use in CGI
service applications.
<http://www.rawbw.com/~rem/HelloPlus/hellos.html#step3>
I wanted to move onward to a lot more common elementary tasks, but
nobody showed any interest in what I had already done so I haven't
done any more work on this project.)
> Q. Which development tools should I be using ?
Emacs is nice, but not necessary. I don't have any decent version
of Emacs here on my Macintosh, so I use McSink instead.
> Q. Which libraries should I definitely be looking at using, ...
What application areas do you have in mind? Distributed computing
using XML or s-expressions to pass data back and forth? Standalone
CGI applications? Heavy numerical calculations such as statistics?
Animated games? Deep board games such as Go?
> How do I turn my program into an executable ?
Why would you want to do that? That basically requires copying
large portions of the Lisp system into each copy of the compiled
program. Why not keep the Lisp software as FASLs and have just one
copy of the Lisp system plus a tiny script for each toplevel
application? Java basically does it that way, with a single jvm
that all applications require to run, instead of a separate copy of
the jvm in each application. If it's good enough for Java, why
isn't it good enough for Lisp?
> Q. How do I package my program in such a way that non-Lisp people
> will not be freaked out by the installation instructions ?
If you concentrate on writing CGI server applications, you never
have that problem. All the user needs is the URL of the startup
form for your application.
> When I first settled on learning CL I thought I would read a
> standard reference work. This is my usual way of approaching new
> programming languages - I'm one of the minority of people who find
> they get on very well with reference manuals, and find tutorials
> distressingly vague about details.
I wonder why you didn't consider a tutorial plus a real live system
to try things on? That why if the tutorial isn't clear, you'll find
it out quickly and have a chance to guess what they meant and try
that and finally understand what they really meant.
When you worked from a reference manual, did you have a real live
system to try things on??
> A Lisp-using friend lent me their copy of CLtL2, and I started
> reading through that. I quickly gave up because of Guy Steele's
> absurd habit of writing `and the thingum does the wossname to the
> doobry - no wait, it doesn't, in 1987 X3J13 voted that in fact the
> thingum does something completely different'.
Thanks for pointing this out. I learned CL back when CLtL1 was the
standard, and that one book was sufficient for my needs.
(Now I sometimes use the HyperSpec instead because it's right here
at my fingertips instead of across the room in a book.)
> My next approach was to try to read the Hyperspec through.
It's a good reference, if you already know enough to know what to
look for, but for an absolute beginner, ...
> I decided it would be better to pick some project and just write
> a program. ... Quickly, I encountered a suitable project: a non
> hideously broken ip-over-http implementation.
Let me see if I understand this correctly. You already have HTTP
over TCP over IP, and now you use CL to operate the HTTP/TCP/IP and
then emulate IP on top of all that, as some sort of demonstration?
May I respectifully submit that accessing HTTP/TCP/IP from CL is
not the ideal first project for learning a new language? You bit
off more than you could chew. Couldn't you think of a more modest
project as a first self-training task?
> First I thought I'd try starting my favourite lisp and playing
> with the REPL like many of the online tutorials suggest.
What, you hadn't *already* done that before embarking on your
IP-emulation/HTTP/TCP/IP project?? Walk before run!
> Several of the lisps I ended up trying didn't have command line
> editing by default ...
Does your computer support copy and paste between different
applications, so you could edit your source to your heart's content
in a text editor and then copy an entire s-expression from there to
the CL environment to see if it works as planned?
> I had to write a function to convert a string of bytes (as
> produced by cl-md5) to hex.
I presume you don't mean hex (base 6) but hexadecimal (base 16)?
Note that bytes are internal data, whereas hexadecimal is a print
notation used mostly for debugging. By "string" do you literally
mean string (the data type in CL) or simply unsigned-octet vector?
In either case, a function to convert the internal data into
hexadecimal debug format is trivial, so why are you complaining?
Did you want all the hexadecimal run together, or broken by
whitespace between adjacent bytes, or blocked in groups of 4 or 8
bytes with whitespace only between blocks, or lined up in tabular
form with low-order part of index along top and high-order part of
index along left?
> Newer (non-broken!) hash functions and so on don't seem to be
> available at all.
In general, when you're writing an application, you don't want a
"hash function", you want a hash table, with all the hash function
and collision resolution etc. hidden from you. All you care about
is that gethash, and the setf for it, both work correctly.
What exactly do you really need which is missing?
> ... I found that there wasn't even a standard function for
> splitting a string into substrings based on a delimiter !
In emacs lisp such a function *is* built-in because when writing
utilities for a text editor such a function is commonly used. But
why would you need that specific feature in any other context?
And if you do really need it, why is it so difficult for you
to write it yourself, using the built-in functions POSITION
and SUBSEQUENCE?
Regarding your tirade about Lisp not producing standard
executables, have you tried posting the same tirade to a Java
newsgroup where the same remarks apply? What response do you get
there when you say that Java feels like a 1960's timewarp?
By the way, Java applets don't work if they use any packages other
than java.lang. Not even java.util is available in most Web
browsers.
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2ejrdjdfl.fsf@bertrand.local>
·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
> string/sequence operations. Serializing/deserializing is trivial
> using print and read.
To be precise, printing and reading are trivial with print and read.
Serialization is a different ball game.
Bill Atkins wrote:
> ·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>
> > string/sequence operations. Serializing/deserializing is trivial
> > using print and read.
>
> To be precise, printing and reading are trivial with print and read.
> Serialization is a different ball game.
Although still relatively trivial
http://common-lisp.net/project/cl-store/
sean.
From: Bill Atkins
Subject: Re: Common Lisp from a Unix perspective - barriers to using CL
Date:
Message-ID: <m2r6v7vcuf.fsf@bertrand.local>
"sross" <······@gmail.com> writes:
> Bill Atkins wrote:
>
>> ·······@Yahoo.Com (Robert Maas, see http://tinyurl.com/uh3t) writes:
>>
>> > string/sequence operations. Serializing/deserializing is trivial
>> > using print and read.
>>
>> To be precise, printing and reading are trivial with print and read.
>> Serialization is a different ball game.
>
> Although still relatively trivial
> http://common-lisp.net/project/cl-store/
>
> sean.
True. Thanks for cl-store, by the way!
In article <·················@Yahoo.Com>,
Robert Maas, see http://tinyurl.com/uh3t <·······@Yahoo.Com> wrote:
>[stuff]
>
>I would like to make such a super-tutorial myself, but I need a
>guinea pig, somebody willing to try it as I work on it, and give me
>prompt feedback how it's working. Do you know anyone willing to
>give it a try?
The best way to do this would probably be to find someone you know but
who doesn't already know lisp and watch them go through it. (If it
takes more than an hour or two then it's probably too long anyway.)
>The software infrastructure is already there for a lot of common
>tasks. For example, look at the chapters on hash tables, and
>string/sequence operations. Serializing/deserializing is trivial
>using print and read.
Indeed. This is quite a strange situation: some important facilities
which in other languages are found in obscure libraries, and which
hardly anyone uses, are standard in CL. But those facilities are
generally ones used when writing larger and more sophisticated
applications, and it is hard to get that far when writing a small
program shows up lack of standard facilities for operations people
nowadays think of as trivial.
> Please list several examples of routine tasks
>that Common Lisp does *not* include built-in, so that we can
>address the specifics.
The biggest class of these is textual string handling, and the next
biggest is Internet functionality. Most modern programming languages
have a huge array of facilities for doing useful things with strings
(regexp libraries, easy split and join, lexers and parser generators,
UTF-8, etc.) and nowadays you wouldn't like to choose a language which
couldn't at least (for example) do basic parsing of CGI form data,
make DNS lookups, read IP addresses from textial configuration files,
etc.
>(In fact I have suggested a universal "cookbook" be composed [...])
That sounds interesting to me (but I haven't followed your link ...)
>> I decided it would be better to pick some project and just write
>> a program. ... Quickly, I encountered a suitable project: a non
>> hideously broken ip-over-http implementation.
>
>Let me see if I understand this correctly. You already have HTTP
>over TCP over IP, and now you use CL to operate the HTTP/TCP/IP and
>then emulate IP on top of all that, as some sort of demonstration?
No, the IP is feeding back into the operating system. (I already have
a suitable way to make pseudo network interfaces from user programs.)
It's an ip-over-braindamage protocol. Eg, some idiot hotel gives you
"internet access" which turns out to mean "web access" so you fill
their webcache with your encrypted packets. Not efficient or pretty
but it gets the job done.
>May I respectifully submit that accessing HTTP/TCP/IP from CL is
>not the ideal first project for learning a new language?
Actually, the portable allegroserve bit is one of the easier parts.
Extensible single-process webserver frameworks are rare enough that I
didn't have the difficulty of choosing between them. It was either
cl-aserve, or twisted, or some hideous nightmare with cooperating
processes and liberal use of fcntl F_GETLK.
> You bit off more than you could chew. Couldn't you think of a more
>modest project as a first self-training task?
This project ought to be modest. When I'm done it ought to be no more
than a few hundred lines at most.
>In either case, a function to convert the internal data into
>hexadecimal debug format is trivial, so why are you complaining?
Because it's tedious to be reimplementing trivial wheels all the time.
If my program has 100 lines of algorithm and needs two dozen trivial
but not suplied features, I end up with 100 lines of algorithm and 100
lines of trivial wheel-reimplementations. What a waste of effort!
OTOH at least reimplementing all of those wheels is good programming
practice, I suppose.
>> Newer (non-broken!) hash functions and so on don't seem to be
>> available at all.
...
>What exactly do you really need which is missing?
As it happens MD5 is sufficient for my needs, but what would be really
nice would be a ready-made HMAC-SHA256. Someone in another thread has
suggested cl-ironport which I would backport if MD5 wasn't good
enough.
>In emacs lisp such a function *is* built-in because when writing
>utilities for a text editor such a function is commonly used. But
>why would you need that specific feature in any other context?
Because the world nowadays uses strings, with particular common kinds
of structure, as interchange formats and protocol elements. Being
able to deal with those quickly and easily saves a lot of faff.
>[Java]
Java is terrible in so many different ways. Common Lisp advocates
should set their sights higher !
--
Ian Jackson personal email: <········@chiark.greenend.org.uk>
These opinions are my own. http://www.chiark.greenend.org.uk/~ijackson/
PGP2 key 1024R/0x23f5addb, fingerprint 5906F687 BD03ACAD 0D8E602E FCF37657
(message (Hello 'Ian)
(you :wrote :on '(05 Dec 2006 01:08:23 +0000 (GMT)))
(
IJ> Q. How do I turn my program into an executable ?
there is no good and official way to make executable from Java or .net
application, at same time Java is most popular language according to TIOBE,
so i think it's not a case.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"People who lust for the Feel of keys on their fingertips (c) Inity")
Alex Mizrahi wrote:
> (message (Hello 'Ian)
> (you :wrote :on '(05 Dec 2006 01:08:23 +0000 (GMT)))
> (
>
> IJ> Q. How do I turn my program into an executable ?
>
> there is no good and official way to make executable from Java or .net
> application, at same time Java is most popular language according to TIOBE,
> so i think it's not a case.
The official way is to make a JAR or use Java Webstart or a WAR for web
applications. The user has to install the official Sun implementation once
and then he/she can just double click every JAR file to start the
application or click on a link to install and start a Webstart application.
Some "unofficial" ways:
http://www.ej-technologies.com/products/exe4j/overview.html
http://www.excelsior-usa.com/jet.html
For Lisp:
CLISP: see ext:saveinitmem with :executable t and
http://www.frank-buss.de/lisp/clisp.html
SBCL: see sb-ext:save-lisp-and-die and :executable
LispWorks: see "deliver"
I assume most other Lisp implemenations have similiar features.
Like to JAR, but not as easy and platform independant: ASDF
Like to Webstart, but again not a single click: ASDF-Install
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Ian Jackson wrote:
> Naturally some of these problems can be addressed with wrapper scripts
> and a few extra tools. That's fine. But where is the standard
> facility for wrapper scripts, that I can put in a #! line ? Where are
> the standard facilities for building *portably-deployable* CL
> programs: by which I mean not `portable to a different Lisp' but
> `a whole distribution bundle which is portable to a computer which
> does not yet have a Lisp system' ? How do I integrate Lisp
> compilation into the build system of a large project using many
> languages and tools, all driven by something like make ?
This is one goal of the Common Lisp Application Builder project:
http://www.lispbuilder.org
Unfortunately I don't have much time at the moment for it, but some users
are very active enhancing it, particularly the SDL support. I have added
some other libraries for regular expressions, yacc- and AWK-emulation and
started a Microsoft Windows wrapper, which could become a general GUI
library.
For OpenGL I recommend cl-opengl: http://common-lisp.net/project/cl-opengl/
For web development I recommend TBNL:
http://weitz.de/tbnl/
http://www.frank-buss.de/lisp/tbnl.html
It provides many functions you need for web development and references some
useful other libraries, like HTML-TEMPLATE etc.
Would be nice to integrate some de facto standard web libraries into a
release of the Lispbuilder project. It could be integrated all into the
Lispbox project (http://www.gigamonkeys.com/lispbox/), but I don't like
Emacs, so a more newbie friendly IDE is required, like the Java Eclipse
IDE.
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss wrote:
> For web development I recommend TBNL:
> http://weitz.de/tbnl/
TBNL is deprecated. Use Hunchentoot instead.
http://weitz.de/hunchentoot/
Cheers,
Edi.
·······@gmail.com wrote:
> TBNL is deprecated. Use Hunchentoot instead.
>
> http://weitz.de/hunchentoot/
Thanks, I'll try it. And looks like you had some time to implement some
more interesting Lisp libraries and projects since I last visited your web
site. Do you plan to implement all additional standard libraries, which are
needed for a useful Lisp environment, by yourself? :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Ian Jackson <········@chiark.greenend.org.uk> wrote:
> * Documentation for introducing Lisp to existing programmers is poor;
> existing tutorials are old or at least outdated.
Nope. The poor old documentation (or link lists) has a higher
PageRank(tm) than the good/great new documentation. So Google
will show you the bottom first.
That's a real problem.
Stefan Scholl <······@no-spoon.de> writes:
> Ian Jackson <········@chiark.greenend.org.uk> wrote:
>> * Documentation for introducing Lisp to existing programmers is poor;
>> existing tutorials are old or at least outdated.
>
> Nope. The poor old documentation (or link lists) has a higher
> PageRank(tm) than the good/great new documentation. So Google
> will show you the bottom first.
>
> That's a real problem.
Well, google is not programmed in lisp, what can we hope?
--
__Pascal Bourguignon__ http://www.informatimago.com/
NEW GRAND UNIFIED THEORY DISCLAIMER: The manufacturer may
technically be entitled to claim that this product is
ten-dimensional. However, the consumer is reminded that this
confers no legal rights above and beyond those applicable to
three-dimensional objects, since the seven new dimensions are
"rolled up" into such a small "area" that they cannot be
detected.
Ian Jackson wrote:
> As an experienced programmer, I've heard a lot about how good Lisp is,
> and I like getting to grips with new languages. After conversations
> with friend who's keen I decided I should learn Common Lisp.
>
> I thought I'd share some of my experiences here.
Welcome to Lisp, and to the unique world that is comp.lang.lisp. Since
you are reporting some difficulties, you may reliably expect to be
insulted. It just seems to be a feature of comp.lang.lisp.
Starting out learning common lisp is not particularly easy as compared
to lots of other languages. As you discovered, there is a bunch of
stuff (documentation and implementations) available, and for the
newcomer there is no very obvious starting point. Probably the easiest
place to start is with either Franz's Allegro Common Lisp or Lispworks,
from the company also called Lispworks. Both provide free versions of
their commercial software, complete with helpful documentation.
A good way to start learning Common Lisp is to read Peter Seibel's book
_Practical Common Lisp_ together with LispBox, a turnkey common lisp +
emacs package designed to be easy to use in combination with that book,
and also maintained by its author.
The free Lisps and tools are good, but require more tinkering, and
probably some help from more experienced users. You can get help from
comp.lang.lisp, but, its culture being what it is, you will be made to
pay for the help by taking abuse. (Over twenty years of writing
commercial software in Common Lisp, I've seen this phenomenon in more
than one place, as if the population of Lisp programmers were a giant
"I'm smarter than you" club; but, thankfully, I've also run into
pockets of very smart Lispers that are free of this nonsense.)
These answers have been the same for a little while now. I don't know
what would be the best way to make the easiest solutions for newcomers
more obvious. A significant issue is that there is a lot of recent
development in Lisp, while at the same time there are decades of legacy
as well. By the time many programmers have figured out how to use Lisp
productively, they seem to have lost any interest they might have had
in making it easier for other newcomers. There are exceptions -- see
the aforementioned _Practical Common Lisp_ and Lispbox, for example --
but even when there are easier starting approaches, they seem to get
lost amongst the plethora of other, less easy, alternatives, which
exist in part because Lisp has been around for so long.
When I started learning Lisp 20 years ago I was lucky in that an easy,
accessible implementation fell into my lap, and it was packaged very
conveniently for my chosen platform (Coral Common Lisp on Macintosh).
The situation is more complicated and less clear-cut than that for
people starting to learn Lisp these days.
A reasonable solution, if you end up really loving Lisp, as some people
do, might be to create a project (or a business!) expanding on the
Lispbox idea -- packaging a Lisp with some tutorial materials and
promoting it to newcomers. Or, if you decided you wanted to address any
deficiencies you find in Lispbox, I'll bet Peter would welcome help
with it.
Once again, welcome to Lisp, and my condolences on the reception your
post is bound to receive.