ccc31807 <
cart...@gmail.com> writes:
> On Wednesday, November 28, 2012 4:07:25 AM UTC-5, Nicolas Neuss wrote:
>> Could you please make a sketch of you didactic program? When and how do
>> you introduce functions? That is much more central than car/cdr/cons.
>> Which book for other languages do you want to follow?
>
> I didn't think my comment through in a rigorous way, but it was more
> of an impressionistic comment. As someone else pointed out below, a
> lot depends on context. My everyday language is Perl, and when I got
> interested in CL one approach I took in learning the language was to
> translate my Perl scripts to CL. Needless to say, this was both
> frustrating and fruitless.
Maybe. Nevertheless, I would be interested in such an example of a
(small) perl script which cannot be translated reasonably well. My
guess would be that if you post such a beast, someone (probably Pascal
B.) will post a CL solution which is not that bad.
> Perhaps the most successful Perl book (and possibly the most
> successful of any language book) is 'Learning Perl'. You can pick up a
> used copy very cheaply and if you want more specifics, read that and
> imagine it 'translated' to CL. Ditto 'Perl Objects, Modules, and
> References'.
I looked at it and my impression is that I would not like it very much.
But maybe my interests in programming are also not those of the average
person.
>> And BTW: _No_ Lisp book I remember starts with car/cdr/cons. Neither
>> does SICP, nor PCL, nor ANSI CL. Which one does?
>
> Again, this was an impressionistic statement more than anything
> else. Over the years I have purchased around a dozen CL books,
> including Wilensky, Touretzky, Winston and Horn, Graham, Seible,
> Barski, Norvig, Tanimoto, Keene, Lamkins, and others I don't remember
> now. My point was NOT that cons, car, etc. are not essential to CL
> (because these along with lambda constitute the heart of CL),
I do _not_ think that cons/car/cdr are essential to CL! At least not
more than make-array and aref are. One Datapoint: I did a search
through my code and car/cdr don't appear much more often than aref.
> but that those of us who came to maturity under the influence of
> numeric processing Turing machines are not equipped to deal with
> symbolic processing lambda calculus without seeing the benefits of why
> we should learn something differently.
>
> I learned Perl via CGI, and once I saw the advantages of Perl in the
> HTTP and database realms, I very naturally went on to learn regular
> expressions, references, and the rest of the very peculiar and
> idiosyncratic Perl syntax.
There was some quote which I tried to find and could not - maybe someone
here can help me. I thought it was by Erik Naggum, but could not find
it in Zach's archive. It was about people being addicted towards some
tool which was bad for them and Perl was given as a specific "example
from hell".
> Java currently has this problem with the OO first mentality that's
> causing an attrition rate of over 50% in beginning programming
> classes.
>
> Perhaps if we had a CL CGI book that focused squarely on the
> development of internet and web applications, some might want to delve
> more deeply in CL.
Maybe. But I doubt it.
> I took an AI class and implemented some of the algorithms in CL. It
> was quite an eye opener in that the little scripts almost wrote
> themselves.
So this may be a domain where CL excels even without a library. The
next thing is to realize that CL is so flexible that you can (usually
quite easily) emulate/incorporate any feature you desire for other
domains.
> They say that if you put a frog in hot water it will immediately jump
> out but if you put it in cold water and boil the water he will not
> jump out. (I've never tried this BTW). My proposal was to do something
> similar with CL.
I don't want to boil people or to seduce them. My sincere goal is to
help them find the right tool for themselves. For me this is CL.
A small example: When I recently gave a Matlab course (with a focus on
stochastic problems), I wanted to generate large random prime numbers
for cryptography. For this, I would have liked to generate large random
integer numbers. Now, although symbolic algebra is supposedly in the
new Matlab (which has incorporated the CAS Mupad), it was not possible
to generate a large random integer, because the randi function was not
capable to handle large integer arguments like say 10^1000. We tried
working around this by composing large random integers from small ones,
but ended in crashing Matlab with a core dump without any apparent
reason. It was towards the end of the course, so I finished with
demonstrating that "(random (expt 10 1000))" is a no-brainer in good
computer languages.
Nicolas