Groups > comp.lang.lisp > #60742 > unrolled thread

Resources to learn common lisp?

Started by	Mario Rosell <mario@mariorosell.es>
First post	2026-02-20 22:53 +0100
Last post	2026-06-03 03:16 +0000
Articles	20 on this page of 132 — 19 participants

Back to article view | Back to comp.lang.lisp

  Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-20 22:53 +0100
    Re: Resources to learn common lisp? Ben Bacarisse <ben@bsb.me.uk> - 2026-02-20 22:00 +0000
      Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:25 +0100
        Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-02-21 10:24 -0500
        Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-21 21:30 +0000
          Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-22 01:08 +0100
            Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-22 04:59 +0000
              Re: Resources to learn common lisp? Madhu <enometh@meer.net> - 2026-02-22 10:59 +0530
                Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-02-22 21:48 +0000
                  Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:43 -0400
          Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:41 -0400
            Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-08 20:02 +0000
              Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-09 00:23 -0400
                Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:28 +0000
                  Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:32 +0000
                    Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:27 -0400
                      Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:33 +0000
                  Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:16 -0400
              Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 06:53 +0000
                Re: Resources to learn common lisp? Axel Reichert <mail@axel-reichert.de> - 2026-06-09 12:07 +0200
                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:14 +0000
                    Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-17 00:01 -0400
                Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:22 +0000
                Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:59 -0700
                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:55 +0000
                    Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 01:43 -0700
                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:45 +0000
            Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:35 +0000
        Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-08 12:37 -0400
          Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 00:33 +0000
            Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-09 00:22 -0400
            Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-09 01:22 -0400
              Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-09 06:17 +0000
              Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-09 06:50 +0000
                Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:40 -0400
                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:26 +0000
                    Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:10 -0400
                  Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:27 -0400
                    Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:12 -0400
              Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-10 12:24 -0400
                Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 05:57 -0400
                Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-11 21:07 -0400
                  Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 13:06 +0000
                    Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:13 +0000
                      Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 07:25 +0000
                        Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 08:25 +0000
                          Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:46 +0000
                            Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:52 +0000
                              Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:57 +0000
                                Re: Resources to learn common lisp? Nuno Silva <nunojsilva@invalid.invalid> - 2026-06-15 10:10 +0100
                            Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:56 +0000
                              Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 11:46 +0000
                      Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 20:56 -0400
                    Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-13 00:55 -0400
                      Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 07:43 +0000
                      Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:37 -0400
                  Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:09 -0700
                    Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:02 +0000
                    Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 10:12 +0000
                  Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 22:54 -0400
                    Re: Resources to learn common lisp? Alan Bawden <alan@csail.mit.edu> - 2026-06-17 00:07 -0400
                Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 12:42 +0000
                  Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 23:32 -0400
            Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-09 09:36 -0400
              Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-10 00:06 +0000
                Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-10 08:43 -0400
                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-11 00:22 +0000
                    Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-11 08:57 -0400
                      Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:16 +0000
                      Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:42 -0400
                    Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 01:15 +0000
                      Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-15 05:42 +0000
                        Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 11:19 +0000
                          Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:18 +0000
                            Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-16 03:27 +0000
                              Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 01:25 -0700
                        Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 23:53 -0400
                Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-11 06:37 -0400
                  Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:30 -0700
                    Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 00:58 +0000
                      Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 01:46 -0700
                        Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-15 06:59 -0400
                          Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-15 12:25 -0700
                Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-11 17:42 +0000
                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-12 00:16 +0000
                    Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-12 12:34 +0000
                      Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-13 00:11 +0000
                        Re: Resources to learn common lisp? George Neuner <gneuner2@comcast.net> - 2026-06-13 04:06 -0400
                          Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:37 -0700
                            Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-06-13 21:25 +0000
                              Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 15:26 -0700
                                Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 05:37 +0000
                                  Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 01:34 +0000
                                    Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-15 05:43 +0000
                                      Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-15 11:23 +0000
                                        Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:23 +0000
                                          Re: Resources to learn common lisp? antispam@fricas.org (Waldek Hebisch) - 2026-06-16 03:29 +0000
                                            Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 04:59 +0000
                                              Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 15:10 -0700
                                    Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 13:34 +0000
                        Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-13 08:36 +0000
                          Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:43 +0000
                            Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-14 10:36 -0400
                              Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 23:55 +0000
                                Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 18:04 -0700
                                  Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 12:33 +0000
                                Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-15 09:51 -0400
                                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-16 00:23 +0000
                                    Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 03:14 -0700
                                    Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-16 15:29 -0700
                                    Re: Resources to learn common lisp? Stefan Monnier <monnier@iro.umontreal.ca> - 2026-06-16 10:23 -0400
                            Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-14 13:14 -0700
                            Re: Resources to learn common lisp? tfb <no_email@invalid.invalid> - 2026-06-16 11:46 +0000
                Re: Resources to learn common lisp? Paul Rubin <no.email@nospam.invalid> - 2026-06-13 13:22 -0700
                  Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-14 01:55 +0000
    Re: Resources to learn common lisp? tpeplt <tpeplt@gmail.com> - 2026-02-20 17:44 -0500
      Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:30 +0100
    Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-02-20 23:50 +0000
      Re: Resources to learn common lisp? ram@zedat.fu-berlin.de (Stefan Ram) - 2026-02-21 00:24 +0000
        Re: Resources to learn common lisp? Andreas Eder <a_eder_muc@web.de> - 2026-02-21 11:36 +0100
        Re: Resources to learn common lisp? Mario Rosell <mario@mariorosell.es> - 2026-02-21 12:44 +0100
    Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-03-31 17:47 -0400
      Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-03-31 23:41 +0000
      Re: Resources to learn common lisp? tpeplt <tpeplt@gmail.com> - 2026-04-01 13:23 -0400
        Re: Resources to learn common lisp? steve g <Sgonedes1977@gmail.com> - 2026-06-16 21:59 -0400
    Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 10:52 -0400
    Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 10:57 -0400
    Re: Resources to learn common lisp? Peri Didaskalou <pfd@torfree.net> - 2026-05-01 11:06 -0400
    Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-01 14:56 -0400
      Re: Resources to learn common lisp? "Robert B. Carleton" <rbc@rbcarleton.net> - 2026-06-01 23:02 +0000
        Re: Resources to learn common lisp? steve g <sgonedes1977@gmail.com> - 2026-06-02 21:32 -0400
          Re: Resources to learn common lisp? Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-06-03 03:16 +0000

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →

#60869

From	tfb <no_email@invalid.invalid>
Date	2026-06-13 08:36 +0000
Message-ID	<110j4qk$2q1p4$1@dont-email.me>
In reply to	#60862

Lawrence D´Oliveiro <ldo@nz.invalid> wrote:

> That’s even worse. That means the live objects have to be moved from
> their existing locations, which might be in the cache, into new
> locations which most likely are not.

How do you think the copying happens?  How does the data you've just
written to its new location manage not to end up in a cache?

I really think you need to read, *and understand* some material on computer
architecture.  I don't know if Hennessy and Patterson is still as good as
it was,  but it's likely a good place to start.  Then implement a simple
two-space copying GC (real examples tend to be so full of low-level
cleverness that it's better to implement a naïve one).  A good way to do
this is to start by writing a program which will defragment objects in
memory: turn a linked list into another one whose links nodes are all
adjacent, say.  When you do that, you'll find you've basically written a
copying GC.

-- 
www.tfeb.org/computer/

[toc] | [prev] | [next] | [standalone]

#60884

From	Lawrence D’Oliveiro <ldo@nz.invalid>
Date	2026-06-14 01:43 +0000
Message-ID	<110l0v9$3av52$1@dont-email.me>
In reply to	#60869

On Sat, 13 Jun 2026 08:36:36 -0000 (UTC), tfb wrote:

> Lawrence D´Oliveiro <ldo@nz.invalid> wrote:
>
>> That’s even worse. That means the live objects have to be moved
>> from their existing locations, which might be in the cache, into
>> new locations which most likely are not.
>
> How do you think the copying happens? How does the data you've just
> written to its new location manage not to end up in a cache?

You need to remember what the cache is for. Having a cache in the
copying path doesn’t somehow magically speed up copying.

And remember, *everything* that is live is being pushed into the cache
by the copying -- including objects that the program wasn’t actually
needing at the moment.

[toc] | [prev] | [next] | [standalone]

#60893

From	Stefan Monnier <monnier@iro.umontreal.ca>
Date	2026-06-14 10:36 -0400
Message-ID	<jwvbjdd5gx3.fsf-monnier+comp.lang.lisp@gnu.org>
In reply to	#60884

> And remember, *everything* that is live is being pushed into the cache
> by the copying -- including objects that the program wasn’t actually
> needing at the moment.

Yeah, GCs are very costly.  Which makes it all the more amazing that
reference counting is typically even worse.


=== Stefan

[toc] | [prev] | [next] | [standalone]

#60896

From	Lawrence D’Oliveiro <ldo@nz.invalid>
Date	2026-06-14 23:55 +0000
Message-ID	<110nf0q$3vra6$3@dont-email.me>
In reply to	#60893

On Sun, 14 Jun 2026 10:36:48 -0400, Stefan Monnier wrote:

> Yeah, GCs are very costly. Which makes it all the more amazing that
> reference counting is typically even worse.

Do you have a reference for that? One which shows that heap-intensive
operations are more efficient (size, speed) when doing with a garbage
collector than reference-counting?

[toc] | [prev] | [next] | [standalone]

#60898

From	Paul Rubin <no.email@nospam.invalid>
Date	2026-06-14 18:04 -0700
Message-ID	<87y0gg62cx.fsf@nightsong.com>
In reply to	#60896

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> Do you have a reference for that? One which shows that heap-intensive
> operations are more efficient (size, speed) when doing with a garbage
> collector than reference-counting?

Chapter 5 of "The Garbage Collection Handbook" (Jones, Hosking, & Moss
2012) is about reference counting.  Most of what it says about naive
reference counting (like Python's, or C++'s std::shared_ptr) is bad.
The relevant text is a page or so, more than I want to type.  The rest
of the chapter is about ways to get around the deficiencies.

I also looked up Zorn's PhD thesis (about GC performance) from 1988:

https://www2.eecs.berkeley.edu/Pubs/TechRpts/1989/Archive/CSD-89-544.pdf

It says similar things to the GC handbook above:

    Unfortunately, reference counting has fundamental disadvantages.
    First and foremost, reference counting algorithms do not reclaim
    storage allocated in circular structures.  Modifications to the
    traditional algorithm have been suggested to overcome this problem,
    but the performance of the modified algorithm is unacceptably slow.
    As a result, reference counting algorithms are augmented with
    traditional garbage collection algorithms.  A second disadvantage of
    reference counting is that space is required to maintain the count.
    A simple implementation associates a 32-bit count with each object
    and increases the size of each cons object (the most common object
    type) by 50%.  More complex implementations reduce this overhead but
    do not entirely eliminate it.  A third disadvantage of reference
    counting is that it fails to reorganize or compact objects in memory
    and is thus unable to improve the locality of references to those
    objects.  By using generations, garbage collection can signicantly
    improve reference locality, as this thesis shows.  Finally, the most
    signicant advantage of reference counting, that of incrementally
    collecting storage, has also been achieved with garbage collection
    algorithms using incremental and generation techniques.

    Because of these disadvantages, reference counting is not often used
    in modern Lisp and Smalltalk implementations.  Recently, however,
    research with distributed memory computers has sparked renewed
    interest in reference counting algorithms because they allow storage
    deallocation based on local information, instead of the global
    information required by garbage collection.  This dissertation
    focuses entirely on techniques for garbage collection and does not
    consider reference counting any further.

Jones' online GC bibliography has a bunch of entries that mention
reference counting.  Only a few look even slightly relevant, but you
could check them if you want.

https://www.cs.kent.ac.uk/people/staff/rej/cgi-bin/searchbib?pattern=reference+counting

[toc] | [prev] | [next] | [standalone]

#60923

From	tfb <no_email@invalid.invalid>
Date	2026-06-16 12:33 +0000
Message-ID	<110rfqf$142ot$1@dont-email.me>
In reply to	#60898

Paul Rubin <no.email@nospam.invalid> wrote:

> 
> Chapter 5 of "The Garbage Collection Handbook" (Jones, Hosking, & Moss
> 2012) is about reference counting.  Most of what it says about naive
> reference counting (like Python's, or C++'s std::shared_ptr) is bad.
> The relevant text is a page or so, more than I want to type.  The rest
> of the chapter is about ways to get around the deficiencies.
> 

You can also just measure stuff.  In the thing I just posted the GC was
called 4,065 times on generation 0.  Each time it found no more than 1,000
live conses each of which is 16 bytes (2 words).  So it copied something
like 65MB.  A better way is probably to say it considered at about 4
million conses.  The program allocated a billion conses, so the GC saw
about 1/250th of them (not coincidentally the GC runtime was about 1/250th
of the total runtime).

A reference counted system would have looked at, *and written the reference
counts of* all billion conses: about 250 times as many as the GC.

I don't have a reference-counted modern Lisp, but it seems deeply
implausible that it would be faster.  If it was faster, it could only
reduce run-time by under 0.5%, because that's what the GC overhead was.

This was for a program which did essentially nothing but allocate memory. 
So it is empirically not the case that GCs are slow for programs which
allocate heavily.  Obviously if you allocate in a way which is
intentionally hostile to the GC *and* you don't tune the GC to deal with
that then they can take longer. LW has extensive support for this: for huge
long-lived allocations you allocate into a generation which the GC does not
look at, and then when you're done you tell it to look at it, once.  I
assume other serious GC'd implementations of Lisp or other languages have
similar tuning options.

-- 
tfeb.org/computer/

[toc] | [prev] | [next] | [standalone]

#60910

From	Stefan Monnier <monnier@iro.umontreal.ca>
Date	2026-06-15 09:51 -0400
Message-ID	<jwv7bo02aiq.fsf-monnier+comp.lang.lisp@gnu.org>
In reply to	#60896

Lawrence D’Oliveiro [2026-06-14 23:55:06] wrote:
> On Sun, 14 Jun 2026 10:36:48 -0400, Stefan Monnier wrote:
>> Yeah, GCs are very costly. Which makes it all the more amazing that
>> reference counting is typically even worse.
> Do you have a reference for that? One which shows that heap-intensive
> operations are more efficient (size, speed) when doing with a garbage
> collector than reference-counting?

[ For the Nth time: I'm not talking about memory size, only about
  speed.  And not specifically for "heap intensive" operations, but for
  just normal execution of "typical" programs.  ]

I don't have a reference, no.  But I'm pretty sure there are plenty.

I guess the most obvious argument is just the very small number of
language implementations that use reference counting and are "high
performance" (which presumably implies that the implementors have spent
some effort to try and use an efficient memory management technique).

I know there exists a GC for the JVM that uses reference counting, but
it's only one out of many others.  It is competitive speed-wise, but it
took a lot of effort to get there (it's very far from a simple reference
counting system like CPython's).

There's also Lean which uses reference counting, but I haven't seen any
indication that it's particularly fast.  AFAIK, the main purpose is to
allow "functional in place update" (by checking if the refcount is equal
to 1), IOW circumvent the language constraint on everything being
immutable yet without resorting to monads.

Given the amount of effort poured into the GC of many language
implementations, if reference counting was competitive speed-wise, it'd
be used a lot more, since it's a lot easier to implement (and debug).

=== Stefan

[toc] | [prev] | [next] | [standalone]

#60913

From	Lawrence D’Oliveiro <ldo@nz.invalid>
Date	2026-06-16 00:23 +0000
Message-ID	<110q516$o45a$7@dont-email.me>
In reply to	#60910

On Mon, 15 Jun 2026 09:51:57 -0400, Stefan Monnier wrote:

> I guess the most obvious argument is just the very small number of
> language implementations that use reference counting and are "high
> performance" (which presumably implies that the implementors have
> spent some effort to try and use an efficient memory management
> technique).

Perl was probably the pioneer here. Implementations use garbage
collection simply because it’s so much easier to do, nothing more.

As I mentioned elsewhere Java gets “high performance” by minimizing
heap allocation, at the cost of writing more circumlocutory code.

Lisp would be the same. What’s his name, Lisp guru Paul Graham, has a
blog online where he talks about working on an early dotcom startup
where the development language was Lisp. That gave them a lot of
productivity boosts. But the core part of the in-memory database was
implemented in C++, precisely where the garbage collector could not
get its sticky fingers on it.

[toc] | [prev] | [next] | [standalone]

#60920

From	Paul Rubin <no.email@nospam.invalid>
Date	2026-06-16 03:14 -0700
Message-ID	<87a4su6bcg.fsf@nightsong.com>
In reply to	#60913

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> Lisp would be the same. What’s his name, Lisp guru Paul Graham, has a
> blog online where he talks about working on an early dotcom startup
> where the development language was Lisp. That gave them a lot of
> productivity boosts. But the core part of the in-memory database was
> implemented in C++, precisely where the garbage collector could not
> get its sticky fingers on it.

Do you mean https://www.paulgraham.com/avg.html ?

The mention of C++ was after he sold the company to Yahoo:

   In January 2003, Yahoo released a new version of the editor written
   in C++ and Perl. It's hard to say whether the program is no longer
   written in Lisp, though, because to translate this program into C++
   they literally had to write a Lisp interpreter: the source files of
   all the page-generating templates are still, as far as I know, Lisp
   code. (See Greenspun's Tenth Rule.)

He mentions that the ordering system of his site was written in C but
doesn't say why.

It's not that great an essay imho.  And the stuff he says about Python
now seems quaint.

[toc] | [prev] | [next] | [standalone]

#60926

From	Paul Rubin <no.email@nospam.invalid>
Date	2026-06-16 15:29 -0700
Message-ID	<871pe65dbt.fsf@nightsong.com>
In reply to	#60913

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> Perl was probably the pioneer here. Implementations use garbage
> collection simply because it’s so much easier to do, nothing more.

Have you actually implemented both?  I feel like a bunch of stuff you're
saying come from inexperience.  

In my case I've implemented an Awk with reference counting and later a
Lisp with GC.  I used RC in the Awk because at that time, I didn't know
how to write a GC.  The GC in the Lisp that I wrote was quite simple but
I still wouldn't say that it was easier than RC.  Of course "serious"
GC's are very intricate and not remotely comparable to the naive
reference counting in something like Python.  It's ridiculous to say
it's easier.

Here's Simon Marlow et al's 2008 paper on the GHC garbage collector:

https://simonmar.github.io/bib/papers/parallel-gc.pdf

I have a vague recollection that the GHC GC was later redone to be even
more sophisticated.  And it's nowhere near as fancy as the GC's used in
Java which have gotten a lot more development energy.

If of any interest, the current "big" Python implementation is CPython
and it uses reference counting.  MicroPython, a smaller Python version
for microcontrollers, uses GC.  Lua, considered a smaller-footprint and
more embeddable language than Python, also uses GC.  MicroPython ran on
MCU's with as little as 16KB of ram (BBC Micro:bit v1) though that was
very cramped.  It's reasonably usable with 32KB.  I don't think CPython
could run at all on those machines.

I'd be interested to know why CPython uses RC.  If I ever meet Guido
I'll try to remember to ask him.  I do have the impression that
immediate reclamation for stuff like file descriptors was claimed as a
big advantage, before Python itself got RAII in the "with" statement.

Slightly related, do you even use Lisp?  I think your picture of how
Lisp programs use memory is also unrealistic.

[toc] | [prev] | [next] | [standalone]

#60927

From	Stefan Monnier <monnier@iro.umontreal.ca>
Date	2026-06-16 10:23 -0400
Message-ID	<jwv7bny1t3z.fsf-monnier+comp.lang.lisp@gnu.org>
In reply to	#60913

Lawrence D’Oliveiro [2026-06-16 00:23:02] wrote:
> On Mon, 15 Jun 2026 09:51:57 -0400, Stefan Monnier wrote:
>> I guess the most obvious argument is just the very small number of
>> language implementations that use reference counting and are "high
>> performance" (which presumably implies that the implementors have
>> spent some effort to try and use an efficient memory management
>> technique).
> Perl was probably the pioneer here. Implementations use garbage
> collection simply because it’s so much easier to do, nothing more.

I'm sorry, but I don't count things like Perl or CPython (or ELisp, for
that matter) as high-performance language implementations.

As tools, they can be very efficient, but it's not because they run Perl
or Python code efficiently: it's because they don't spend much time
running actual Perl and Python code (instead they spend most of their
time running code written in other languages, like C).

> As I mentioned elsewhere Java gets “high performance” by minimizing
> heap allocation, at the cost of writing more circumlocutory code.

No, Java gets high performance because lots of money was poured into the
implementation of JVM's compilers to generate efficient machine code.
In turn, this makes the time spent managing memory more visible so it
increases pressure on the language implementors to implement efficient
memory management, and it also increases pressure on programmers to be
mindful of the amount of allocation they perform when they care
about speed.

> That gave them a lot of productivity boosts.  But the core part of the
> in-memory database was implemented in C++, precisely where the garbage
> collector could not get its sticky fingers on it.

This seems to argue that automatic memory management can be expensive.
I never claimed otherwise.  I'm just claiming that when a language
implementation has to implement automatic memory management, the choice
of reference counting will usually lead to slower execution than what
you'd get with a tracing GC.

=== Stefan

[toc] | [prev] | [next] | [standalone]

#60894

From	Paul Rubin <no.email@nospam.invalid>
Date	2026-06-14 13:14 -0700
Message-ID	<87bjdc7uce.fsf@nightsong.com>
In reply to	#60884

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> And remember, *everything* that is live is being pushed into the cache
> by the copying -- including objects that the program wasn’t actually
> needing at the moment.

Generational GC exists to avoid that.  In most GC cycles, the stuff that
you copy is new and either is in use or gets collected at the next cycle.
Now and then you have a "major" GC that copies older objects.  Those
cycles are slower but there aren't that many of them.

If you actually profile an application, and GC is dominating the CPU
time, something is probably wrong with the program.  It's even that way
with GHC, which likely generates more garbage than typical Lisp programs
do, because of how the language works.

[toc] | [prev] | [next] | [standalone]

#60921

From	tfb <no_email@invalid.invalid>
Date	2026-06-16 11:46 +0000
Message-ID	<110rd23$137br$1@dont-email.me>
In reply to	#60884

Lawrence D´Oliveiro <ldo@nz.invalid> wrote:

> You need to remember what the cache is for. Having a cache in the
> copying path doesn’t somehow magically speed up copying.

Where was the bit where I claimed that?  Oh, gosh, I didn't claim it, did
I?

> 
> And remember, *everything* that is live is being pushed into the cache
> by the copying -- including objects that the program wasn’t actually
> needing at the moment.
> 

Here's the thing, you have two systems (1) a system which leaves caches
full of data which is live and which may be referenced again, and (2) a
system which leaves caches full of data which certainly never will be
referenced again.  One of these systems is better than the other: can you
guess which?

And yes, the problem with a copying GC is it may need to copy a lot of
data.  That's why nobody serious has used naïve two-space copying GCs for
forty years.  They use something cleverer.

Here's the output of a program running in an implementation with one of
these cleverer GCs:

? (run)
* 1000000 chunks of 1000
Timing the evaluation of (progn (thrash n m))

User time    =       21.156
System time  =        0.078
Elapsed time =       21.238
Allocation   = 16016000000 bytes
4276 Page faults

                                  total    /   user     /   system
total gc activity          =      0.086224 /   0.058126 /   0.028098
Standard  0  ( 4065 calls) =      0.083341 /   0.057528 /   0.025813
Standard  1  (    8 calls) =      0.002883 /   0.000598 /   0.002285
- estimate 16000000000 bytes
* single chunk of 1000000000
Timing the evaluation of (progn (thrash n m :chunk-by-n nil))

User time    =       34.310
System time  =        7.447
Elapsed time =       46.056
Allocation   = 16000000016 bytes
3908831 Page faults

                                  total    /   user     /   system
total gc activity          =     25.694390 /  18.446271 /   7.248119
Standard  0  (   19 calls) =      5.275545 /   4.710530 /   0.565015
Standard  1  (    6 calls) =      1.925155 /   1.636884 /   0.288271
Standard  2  (    4 calls) =     13.096888 /   8.477376 /   4.619512
Standard  3  (    2 calls) =      5.396802 /   3.621481 /   1.775321
- estimate 16000000000 bytes

The first call to THRASH allocated 1,000 conses 1,000,000 times: a total
allocation of about 16GB.  The GC is taking about 1/246 of the run time. 
That's because it never finds more than about 16k of live data, even though
it's run thousands of times.

The second call allocates the same amount: about 16GB.  And the two loops
are the same, but this time it's collecting one big list.  And now the GC
is taking more than half of the runtime.  That's because I've deliberately
written the second example to be hostile to a generational GC and also I
have deliberately not adjusted it so that it doesn't kill the GC.  In real
life, if I had a program which I knew was going to allocate some vast,
non-ephemeral object I'd do that in a way that wasn't going to kill the GC.

OK, well, discussing things with you is like discussing things with mud, so
I'll likely give up now.

-- 
tfeb.org/computer/

[toc] | [prev] | [next] | [standalone]

#60874

From	Paul Rubin <no.email@nospam.invalid>
Date	2026-06-13 13:22 -0700
Message-ID	<87pl1u8a1q.fsf@nightsong.com>
In reply to	#60839

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> Whereas a garbage collector, by design, is spending much of its time
> hitting long-dead objects, which would likely have long since
> disappeared from the cache. 

Larger runtimes tend to use semispace (copying) GC's.  Those never touch
dead objects.  They copy the live objects to a new block of memory
(which also makes them contiguous), then release the entire old block in
a single operation.

> Feel free to show any performance measures that back up your claim --
>particularly memory usage. I would say the only reason the Python
>approach hasn’t been done before now is because it’s hard to do -- pure
>brute-force GC has always simply been the path of least resistance.

For a long time (amybe still), we lived in a world where memory was
cheap and people cared more about program speed than the memory
footprint of the GC'd heap.  The heap after all is the part of the
program memory that potentially contains pointers, and high-memory
systems (databases, file servers, etc.) tended to use the memory mostly
for caches and other chunks of pointer-free data.  I know lots of us
remember old Lisp systems thrashing during GC, but that was before every
cheap PC had gigabytes of ram.  

Java in particular has received many times more performance tuning of
both its GC's and its JIT compilers than Python ever has.  Benchmarks
reflect that.  I ran a Lucene-based production search system for a
while, and keeping it lively was more a matter of keeping the data
caches warm than anything to do with the GC.  IDK whether CL got much
attention in the same period, or is getting it now.

[toc] | [prev] | [next] | [standalone]

#60885

From	Lawrence D’Oliveiro <ldo@nz.invalid>
Date	2026-06-14 01:55 +0000
Message-ID	<110l1n2$3av52$2@dont-email.me>
In reply to	#60874

On Sat, 13 Jun 2026 13:22:57 -0700, Paul Rubin wrote:

> For a long time (amybe still), we lived in a world where memory was
> cheap and people cared more about program speed than the memory
> footprint of the GC'd heap.

Memory still is cheap (even at current prices), compared to what it
was in living memory. The paradox of current processor architectures
is: memory may be cheap, but accessing memory is expensive.

> Java in particular has received many times more performance tuning
> of both its GC's and its JIT compilers than Python ever has.
> Benchmarks reflect that.

I would be wary of simplistic comparisons like that, without looking
in more detail at the code.

The key to getting speed out of Java is to avoid heap operations. This
is one reason why Java code ends up so verbose. You can’t even define
custom operator overloads.

For example, at one point I wrote a library of 4×4 matrix operations
for 3D graphics on Android. Here’s what the method looked like that
created a matrix for scaling about an arbitrary given origin:

    public static Mat4f scaling
      (
        Vec3f v,
        Vec3f origin
      )
      /* returns a matrix that will scale about the specified point by the specified vector. */
      {
        return
            translation(origin).mul(scaling(v)).mul(translation(origin.neg()));
      } /*scaling*/

(The operations go from right to left: move the origin to (0, 0, 0),
apply the scaling, then move back to the original position.)

A Java programmer who cared about performance wouldn’t do it in such a
functional way: they would do it procedurally, defining the methods so
that they applied transformations in sequence to an existing matrix
object, instead of creating a new one every time.

Python, of course, encourages functional ways of expressing things,
and it provides lots of constructs to ease this sort of thing --
including custom operator overloads. But this means creating lots more
objects on the heap than Java would.

So you see, the performance you saw with Java very likely had less to
do with GC optimization than you suppose.

[toc] | [prev] | [next] | [standalone]

#60744

From	tpeplt <tpeplt@gmail.com>
Date	2026-02-20 17:44 -0500
Message-ID	<87seavm3wj.fsf@gmail.com>
In reply to	#60742

Mario Rosell <mario@mariorosell.es> writes:

> Hello everyone!
>
> I want to learn Common Lisp, but I don't really know what resources to
> use.
>
> What did you all use to learn? Is that even relevant? Is this newsgroup
> active?
>
> Thanks for everyone in advice

A place where you can start is with David S. Touretzky’s
book "COMMON LISP: A Gentle Introduction to Symbolic
Computation", which Carnegie-Mellon University has made
available for download as a PDF file:

https://www.cs.cmu.edu/~dst/LispBook/book.pdf

In addition to the text that teaches you Common Lisp, it
includes exercises, answers to the exercises, and a glossary
to get the definitions of terms.

Although you can read the book, you will want to be able to
evaluate expressions both to practice and the confirm that
you understand what you are doing.  Some readers of this
group might have a Lisp that they will recommend.  I
recommend that you start by installing GNU Emacs on your
computer.  It is a text editor that comes with its own Lisp,
called Emacs Lisp, that is similar enough to Common Lisp
that you will be able to complete many of the exercises
without installing a Lisp.  Over decades, Emacs has been
developed so that it can be used as an environment that is
highly-optimized for Lisp programming, including Scheme and
Common Lisp.

If you have not used Emacs and are able to install it, then
you will want to look carefully the first time that you
start running it.  You should see the following two links:

   Emacs Tutorial
   Emacs Guided Tour

The tutorial gets you started on using Emacs and the guided
tour shows you some of the capabilities that the editor.
The guided tour uses one of Emacs’s built-in web browsers to
download into the editor a web page with text and images to
give the tour.

You should also read the built-in manual titled "Introduction
to Emacs Lisp", which is available inside Emacs via its
menu:

   menu -> Help -> More Manuals -> Introduction to Emacs Lisp

You might consider reading this (much smaller) book BEFORE
reading "Gentle Intro." because it will quickly give you an
idea of whether you want to learn Lisp.

-- 
The lyf so short, the craft so long to lerne.
- Geoffrey Chaucer, The Parliament of Birds.

[toc] | [prev] | [next] | [standalone]

#60749

From	Mario Rosell <mario@mariorosell.es>
Date	2026-02-21 12:30 +0100
Message-ID	<87y0km2v0u.fsf@mariorosell.es>
In reply to	#60744

> I recommend that you start by installing GNU Emacs on your computer

I used Emacs a bit - just a few weeks.  I'll install it again.

> A place where you can start is with David S. Touretzky’s book "COMMON
> LISP: A Gentle Introduction to Symbolic Computation"

Thanks! I'll read the book. It seems pretty good.

-- 
- mario

[toc] | [prev] | [next] | [standalone]

#60745

From	ram@zedat.fu-berlin.de (Stefan Ram)
Date	2026-02-20 23:50 +0000
Message-ID	<books-20260221004737@ram.dialup.fu-berlin.de>
In reply to	#60742

Mario Rosell <mario@mariorosell.es> wrote or quoted:
>I want to learn Common Lisp, but I don't really know what resources to
>use.

  I read parts of a Common Lisp specification by Guy Steele in
  the 80s or 90s. But this is very long ago, and I have long
  forgotten what I read. I don't really know Common Lisp well.

  Some books come to mind, but I have not read any of them:

Practical Common Lisp by Peter Seibel (who was a regular here)

Common Lisp: A Gentle Introduction to Symbolic Computation by
David S. Touretzky

On Lisp by Paul Graham

[toc] | [prev] | [next] | [standalone]

#60746

From	ram@zedat.fu-berlin.de (Stefan Ram)
Date	2026-02-21 00:24 +0000
Message-ID	<books-20260221012132@ram.dialup.fu-berlin.de>
In reply to	#60745

ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>Some books come to mind, but I have not read any of them:

  Here are quotations from this group from the years starting
  with "202":

|El Fri, 25 Sep 2020 17:08:53 -0700 (PDT), Ishaan escribió:
|>>What tutorial are you following?
|>"Practical Common Lisp" by Peter Siebel. Are their any good alternatives
|>to Emacs and lisp in a box that are easier to use? Thanks for the help!
|That's a pretty good book, and Emacs with Slime is the best setup IMO, so 
'-----------------------------------------------------------------------
José Manuel García-Patos on 2020-09-26 12:58:32+00:00 in comp.lang.lisp,
Subject: Lisp programming questions


|[_]-- try the 
|     Book-- Land Of Lisp
|          which is very simple to start with
|               and it makes a sequence of games
|               working up to a webserver version of Dice Of Doom
|               in CommonLisp 
|          it's written by a doctor of medicine apparently
'-----------------------------------------------------------------------
picoVerse on 2021-03-22 02:58:01+00:00 in comp.lang.lisp,
Subject: Lisp programming questions


|There are a number of introductory books that have been produced over the
|years. It doesn't matter if some of them are years old, as Common Lisp hasn't
|changed in a while (although some libraries for doing things have).
'-----------------------------------------------------------------------
Tom Russ on 2022-01-26 20:28:48+00:00 in comp.lang.lisp,
Subject: Is using Emacs a good way to learn lisp?


|Common LISP: A Gentle Introduction to Symbolic Computation
|by Touretzky, David S.
|ISBN 13 9780486498201
|
|Practical Common Lisp
|by Peter Seibel
|ISBN 13 9781430242901
|
|I haven't read the first. I can recommend the second (for those with some
|programming experience) although it uses LOOP too much for my taste and only
|casually mentions the DEFSTRUCT functionality.
'-----------------------------------------------------------------------
Spiros Bousbouras on 2022-01-29 19:20:29+00:00 in comp.lang.lisp,
Subject: Is using Emacs a good way to learn lisp?


|2 books to read absolutely to understand Lisp and its philosophy:
|Ansi Common Lisp
|On Lisp
|Both from Paul Graham. The second one is not printed anymore, but
|available at low cost from lulu.com
'-----------------------------------------------------------------------
ST on 2022-11-22 06:54:33+00:00 in comp.lang.lisp,
Subject: Can someone help me fix a basic recursive function


|When I ventured out into Common Lisp some years back, I found
<Touretzky>
|a very nice read, with lots of small recursive exercises.
'-----------------------------------------------------------------------
Axel Reichert on 2022-11-22 21:36:29+00:00 in comp.lang.lisp,
Subject: Can someone help me fix a basic recursive function


|> I searched around for subsets (not very fruitful), but I did happen to
|> find one quite interesting online textbook (apart from the usual
|> suspects), "Learn Lisp the hard way":
|It's an in-progress draft.  It's looking pretty good.  I don't even
|think a book to teach one how to use a language needs that much.  But if
|the author has that much energy, I think it's useful.
'-----------------------------------------------------------------------
Julieta Shem on 2024-01-30 04:37:02+00:00 in comp.lang.lisp,
Subject: common lisp, the untold story


|Peter Seibel's ``Practical Common Lisp'' guides you with the GNU EMACS
|and SLIME.  Chapter 2.  I use the GNU EMACS and SLIME.  It's wonderful.
'-----------------------------------------------------------------------
Julieta Shem on 2024-02-04 15:31:48+00:00 in comp.lang.lisp,
Subject: Learning the REPL


|- Common Lisp: An Interactive Approach <-novices
|- A Gentle Introduction to Symbolic Computation <-advanced  
|- Paradigms On Artifical Intelligence Programming <- almost expert
'-----------------------------------------------------------------------
usuario on 2024-10-03 21:05:02+00:00 in comp.lang.lisp,

[toc] | [prev] | [next] | [standalone]

#60747

From	Andreas Eder <a_eder_muc@web.de>
Date	2026-02-21 11:36 +0100
Message-ID	<878qcmidsb.fsf@eder.anydns.info>
In reply to	#60746

On Sa 21 Feb 2026 at 00:24, Stefan Ram wrote:

> ram@zedat.fu-berlin.de (Stefan Ram) wrote or quoted:
>>Some books come to mind, but I have not read any of them:
>
>   Here are quotations from this group from the years starting
>   with "202":
>
> |El Fri, 25 Sep 2020 17:08:53 -0700 (PDT), Ishaan escribió:
> |>>What tutorial are you following?
> |>"Practical Common Lisp" by Peter Siebel. Are their any good alternatives
> |>to Emacs and lisp in a box that are easier to use? Thanks for the help!
> |That's a pretty good book, and Emacs with Slime is the best setup IMO, so
> '-----------------------------------------------------------------------
> José Manuel García-Patos on 2020-09-26 12:58:32+00:00 in comp.lang.lisp,
> Subject: Lisp programming questions
>
> |[_]-- try the
> |     Book-- Land Of Lisp
> |          which is very simple to start with
> |               and it makes a sequence of games
> |               working up to a webserver version of Dice Of Doom
> |               in CommonLisp
> |          it's written by a doctor of medicine apparently
> '-----------------------------------------------------------------------
> picoVerse on 2021-03-22 02:58:01+00:00 in comp.lang.lisp,
> Subject: Lisp programming questions
>
> |There are a number of introductory books that have been produced over the
> |years. It doesn't matter if some of them are years old, as Common Lisp hasn't
> |changed in a while (although some libraries for doing things have).
> '-----------------------------------------------------------------------
> Tom Russ on 2022-01-26 20:28:48+00:00 in comp.lang.lisp,
> Subject: Is using Emacs a good way to learn lisp?
>
> |Common LISP: A Gentle Introduction to Symbolic Computation
> |by Touretzky, David S.
> |ISBN 13 9780486498201
> |
> |Practical Common Lisp
> |by Peter Seibel
> |ISBN 13 9781430242901
> |
> |I haven't read the first. I can recommend the second (for those with some
> |programming experience) although it uses LOOP too much for my taste and only
> |casually mentions the DEFSTRUCT functionality.
> '-----------------------------------------------------------------------
> Spiros Bousbouras on 2022-01-29 19:20:29+00:00 in comp.lang.lisp,
> Subject: Is using Emacs a good way to learn lisp?
>
> |2 books to read absolutely to understand Lisp and its philosophy:
> |Ansi Common Lisp
> |On Lisp
> |Both from Paul Graham. The second one is not printed anymore, but
> |available at low cost from lulu.com
> '-----------------------------------------------------------------------
> ST on 2022-11-22 06:54:33+00:00 in comp.lang.lisp,
> Subject: Can someone help me fix a basic recursive function
>
> |When I ventured out into Common Lisp some years back, I found
> <Touretzky>
> |a very nice read, with lots of small recursive exercises.
> '-----------------------------------------------------------------------
> Axel Reichert on 2022-11-22 21:36:29+00:00 in comp.lang.lisp,
> Subject: Can someone help me fix a basic recursive function
>
> |> I searched around for subsets (not very fruitful), but I did happen to
> |> find one quite interesting online textbook (apart from the usual
> |> suspects), "Learn Lisp the hard way":
> |It's an in-progress draft.  It's looking pretty good.  I don't even
> |think a book to teach one how to use a language needs that much.  But if
> |the author has that much energy, I think it's useful.
> '-----------------------------------------------------------------------
> Julieta Shem on 2024-01-30 04:37:02+00:00 in comp.lang.lisp,
> Subject: common lisp, the untold story
>
> |Peter Seibel's ``Practical Common Lisp'' guides you with the GNU EMACS
> |and SLIME.  Chapter 2.  I use the GNU EMACS and SLIME.  It's wonderful.
> '-----------------------------------------------------------------------
> Julieta Shem on 2024-02-04 15:31:48+00:00 in comp.lang.lisp,
> Subject: Learning the REPL
>
> |- Common Lisp: An Interactive Approach <-novices
> |- A Gentle Introduction to Symbolic Computation <-advanced
> |- Paradigms On Artifical Intelligence Programming <- almost expert
> '-----------------------------------------------------------------------
> usuario on 2024-10-03 21:05:02+00:00 in comp.lang.lisp,

All these books are good.
Let me add two additional ones:

'LISP, Lore, and Logic' by W. Richard Stark

'Paradigms of Artificial Intelligence Programming: Case Studies in
Common Lisp' by Peter Norvig

-- 
ceterum censeo redmondinem esse delendam

[toc] | [prev] | [next] | [standalone]

Page 6 of 7 — ← Prev page 1 2 3 4 5 [6] 7 Next page →

csiph-web

Resources to learn common lisp?

Contents

#60869

#60884

#60893

#60896

#60898

#60923

#60910

#60913

#60920

#60926

#60927

#60894

#60921

#60874

#60885

#60744

#60749

#60745

#60746

#60747