Julieta Shem <jshem@yaxenu.org> writes:

> Axel Reichert <mail@axel-reichert.de> writes:
>
>> which brings me back to your original question: Since Guile is
>> advertised with its POSIX capabilities, I expect you could find a
>> better/more familiar technique there.
>>
>> But that is just guessing and gut feeling, not based on any research.
>
> Relative to my desires that's good intuition. I've been looking for a
> Lisp as a medium of expression and Racket does appear to be the most
> sophisticated one.

Sounds familiar. Some years back I was torn between (Steel Bank) Common
Lisp, Clojure and Racket. From an aesthetic/minimalistic point of view,
I prefer Lisp-1s/Schemes, but SBCL is just an awesome interactive
experience in Emacs with SLIME and really fast. Clojure feels more
modern (but I am allergic against anything related to Java) and Racket
powerful (but somehow not pragmatic). Common Lisp seems more down to
earth, but also baroque (its age shows).

> seeing how much fun I was having just considering Common Lisp I did
> think of Guile precisely because of the GNU Guix connection.

I somewhere read that Guile is the most Common-Lisp-like of the Scheme
implementations (if you ask for it, I will try to dig up the link). From
my above paragraph, you can imagine that this is intriguing for
me. Especially having a reasonably fast general purpose language that
purportedly integrates well with everything POSIX or C (I do not speak
C), can be used to configure (I should rather say "determine") the setup
of an operating system (Guix SD) and, with this OS, also for Emacs
(since Guix SD has Guile Emacs, which otherwise is said to be quite an
endeavour to build/install). I really like to reduce the number of tools
in my box, provided they are powerful and I am willing to learn them
deeply.

> reading Common Lisp documentation I felt like a computing historian.

[...]

> I do enjoy the history of computing quite a lot and it does feel good
> to actually use tools older than the current ones that actually feels
> /quite/ superior

Sure, and again, sounds familiar. Emacs is old, AWK is old, Unix is
old. Many of the good tools are old, it is called

https://en.wikipedia.org/wiki/Lindy_effect

Learn them early, try to master them until late in your life. (This
makes sense only for both powerful and versatile tools.)

Best regards

Axel

On Wed, 10 Jan 2024 22:45:37 +0100, Axel Reichert wrote:

> Emacs is old, AWK is old, Unix is old.
> Many of the good tools are old ...

Only the ones that people still remember, because they are still in common
use.

And also because their modern incarnations are quite different from how
they were in the early days.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> On Wed, 10 Jan 2024 22:45:37 +0100, Axel Reichert wrote:
>
>> Emacs is old, AWK is old, Unix is old.
>> Many of the good tools are old ...
>
> Only the ones that people still remember, because they are still in common
> use.

(remove-if-not #'time-resistant (list tool-1 tool-2 ...))

> And also because their modern incarnations are quite different from
> how they were in the early days.

(mapcar #'refinement (list lindy-tool-1 lindy-tool-2 ...))

(-;

Best regards

Axel

On Wed, 10 Jan 2024 22:45:37 +0100, Axel Reichert
<mail@axel-reichert.de> wrote:

>Julieta Shem <jshem@yaxenu.org> writes:
>
>> Axel Reichert <mail@axel-reichert.de> writes:
>>
>>> which brings me back to your original question: Since Guile is
>>> advertised with its POSIX capabilities, I expect you could find a
>>> better/more familiar technique there.
>>>
>>> But that is just guessing and gut feeling, not based on any research.
>>
>> Relative to my desires that's good intuition. I've been looking for a
>> Lisp as a medium of expression and Racket does appear to be the most
>> sophisticated one.
>
>Sounds familiar. Some years back I was torn between (Steel Bank) Common
>Lisp, Clojure and Racket. From an aesthetic/minimalistic point of view,
>I prefer Lisp-1s/Schemes, but SBCL is just an awesome interactive
>experience in Emacs with SLIME and really fast. Clojure feels more
>modern (but I am allergic against anything related to Java) and Racket
>powerful (but somehow not pragmatic). Common Lisp seems more down to
>earth, but also baroque (its age shows).
>
>> seeing how much fun I was having just considering Common Lisp I did
>> think of Guile precisely because of the GNU Guix connection.
>
>I somewhere read that Guile is the most Common-Lisp-like of the Scheme
>implementations (if you ask for it, I will try to dig up the link). From
>my above paragraph, you can imagine that this is intriguing for
>me. Especially having a reasonably fast general purpose language that
>purportedly integrates well with everything POSIX or C (I do not speak
>C), can be used to configure (I should rather say "determine") the setup
>of an operating system (Guix SD) and, with this OS, also for Emacs
>(since Guix SD has Guile Emacs, which otherwise is said to be quite an
>endeavour to build/install). I really like to reduce the number of tools
>in my box, provided they are powerful and I am willing to learn them
>deeply.
>
>> reading Common Lisp documentation I felt like a computing historian.
>
>[...]
>
>> I do enjoy the history of computing quite a lot and it does feel good
>> to actually use tools older than the current ones that actually feels
>> /quite/ superior
>
>Sure, and again, sounds familiar. Emacs is old, AWK is old, Unix is
>old. Many of the good tools are old, it is called
>
> https://en.wikipedia.org/wiki/Lindy_effect
>
>Learn them early, try to master them until late in your life. (This
>makes sense only for both powerful and versatile tools.)
>
>Best regards
>
>Axel

Question is whether you want to write GUI programs. Then Armed Bear
Common Lisp, Clojure or Racket have the edge ... Armed Bear and
Clojure can use Java-based GUI builders and libraries, and Racket has
its own builder and libraries.

Admittedly I'm not current with Lisp state of the art, but I'm not
aware of any Lisp that comes with its own GUI builder. Certainly you
can use FFI and a widget library, or create a GUI using some other
language and connect your Lisp program to it.

YMMV,
George

Axel Reichert <mail@axel-reichert.de> writes:

> Julieta Shem <jshem@yaxenu.org> writes:
>
>> Axel Reichert <mail@axel-reichert.de> writes:
>>
>>> which brings me back to your original question: Since Guile is
>>> advertised with its POSIX capabilities, I expect you could find a
>>> better/more familiar technique there.
>>>
>>> But that is just guessing and gut feeling, not based on any research.
>>
>> Relative to my desires that's good intuition. I've been looking for a
>> Lisp as a medium of expression and Racket does appear to be the most
>> sophisticated one.
>
> Sounds familiar. Some years back I was torn between (Steel Bank) Common
> Lisp, Clojure and Racket.

That's where I am right now. I'm all for studying Racket and Clojure,
but meanwhile I'm sticking to Common Lisp. I never fell in love with a
language so quickly. These new languages may be marvelous in every
single way, but like Alan Perlis would say

``I think that it’s extraordinarily important that we in computer
science keep fun in computing. [...]'' -- Alan J. Perlis (SICP, before
the table of contents.)

> From an aesthetic/minimalistic point of view, I prefer
> Lisp-1s/Schemes, but SBCL is just an awesome interactive experience in
> Emacs with SLIME and really fast.

Maybe that's it. Really fast. Maybe that's a big thing for the fun of
it. Trivial mistakes beginners make are reported with a lot of clarity
by SBCL. I think I've never seen a more clarifying compiler ever in my
life.

> Clojure feels more modern (but I am allergic against anything related
> to Java) and Racket powerful (but somehow not pragmatic).

It's hard to pinpoint what it is with Racket. Maybe I'm not good enough
for Racket. Maybe I'm too stupid for Racket.

> Common Lisp seems more down to earth, but also baroque (its age
> shows).

I'd be careful here. Maybe Common Lisp is still future in various
respects. For example, when it comes to fun --- it's my top first pick.
Can't say what it is, but I'm having a lot of fun with it.

>> seeing how much fun I was having just considering Common Lisp I did
>> think of Guile precisely because of the GNU Guix connection.
>
> I somewhere read that Guile is the most Common-Lisp-like of the Scheme
> implementations (if you ask for it, I will try to dig up the link).

Dig it up! Let's read it and discuss it. You're invited. :-)

> From my above paragraph, you can imagine that this is intriguing for
> me. Especially having a reasonably fast general purpose language that
> purportedly integrates well with everything POSIX or C (I do not speak
> C),

I think you would like to speak C. It's comforting to know what if
things ever get lower level, you'd be at home. For instance, there's
this new library that nobody created the bindings in Common Lisp or
whatever; you can do it. It's a simple thing at least for an emergency.
C is /simple/ language; that's its best feature.

> can be used to configure (I should rather say "determine") the setup
> of an operating system (Guix SD)

What's the SD in Guix SD? Software distribution?

> and, with this OS, also for Emacs (since Guix SD has Guile Emacs,
> which otherwise is said to be quite an endeavour to build/install). I
> really like to reduce the number of tools in my box, provided they are
> powerful and I am willing to learn them deeply.

Same here. I like keep the box small and I do choose tools that I can
carry with me for a life time. That's another thing about Common Lisp
that feels very good --- you find papers and books that are ``old'' and
they describe things that are still exactly like they said. That's not
even true of C, say. C has been updated to do wild things, but gladly
we can still find old compilers and even ask the new ones to behave like
the old ones. Here's a Unix counterexample:

--8<---------------cut here---------------start------------->8---
errno

Kernel designers often add system-specific macros to
errno.h. Workaround: in files that include errno.h, avoid all macros
beginning with the letter E. Recent Linux distributions (recent
versions of glibc) refuse to compile programs that declare extern int
errno without including errno.h. This is a bug, as discussed
below. Correct behavior (all other C libraries: BSD, Solaris, etc.) is
to accept extern int errno whether or not errno.h is included. The
workaround for this Linux bug is to include errno.h everywhere, for
example by compiling with gcc -include /usr/include/errno.h.

Further comments on the Linux bug: When this change was introduced, it
was a clear and flagrant violation of IEEE Std 1003.1-1990 (POSIX),
which specifies the correct declaration to be extern int errno, nothing
more, nothing less. When Paul Wanish formally requested in 2001 that
IEEE issue an "interpretation" of IEEE Std 1003.1-1990 as meaning
something other than what it says, IEEE refused:

IEEE Std 1003.1-1990 specifies that extern int errno; is the correct
declaration for errno. This is not a shorthand for a different meaning.
The glibc authors' excuse for violating IEEE Std 1003.1-1990 (and for
loudly demanding changes in subsequent standards) is that threaded
programs need a variable errno address. This excuse doesn't stand up to
even the slightest examination. Yes, threaded programs need to include
errno.h, but it's trivial to keep extern int errno working for all the
non-threaded programs. The C library simply defines an int errno and has
its address as the initial value for the thread errno pointer.

Source:
https://cr.yp.to/docs/unixport.html
--8<---------------cut here---------------end--------------->8---

>> reading Common Lisp documentation I felt like a computing historian.
>
> [...]
>
>> I do enjoy the history of computing quite a lot and it does feel good
>> to actually use tools older than the current ones that actually feels
>> /quite/ superior
>
> Sure, and again, sounds familiar. Emacs is old, AWK is old, Unix is
> old. Many of the good tools are old, it is called
>
> https://en.wikipedia.org/wiki/Lindy_effect
>
> Learn them early, try to master them until late in your life. (This
> makes sense only for both powerful and versatile tools.)

Thanks for the name of the effect.

Let's end with something that makes a lot of sense to me.

--8<---------------cut here---------------start------------->8---
``The idea that new code is better than old is patently absurd. Old
code has been used. It has been tested. Lots of bugs have been found,
and they’ve been fixed. There’s nothing wrong with it. It doesn’t
acquire bugs just by sitting around on your hard drive. Au contraire,
baby! Is software supposed to be like an old Dodge Dart, that rusts
just sitting in the garage? Is software like a teddy bear that’s kind
of gross if it’s not made out of all new material?''
-- Joel Spolsky, 2000.

Source:
https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i
--8<---------------cut here---------------end--------------->8---

On Wed, 10 Jan 2024 17:57:13 -0500, George Neuner wrote:

> ... I'm not aware
> of any Lisp that comes with its own GUI builder. Certainly you can use
> FFI and a widget library ...

Another thing is that GUI toolkits define their own event loop. You can
hook into this with callbacks, but the fun way to do things now is via
coroutines (async/await). Scheme can implement these with continuation-
passing; but this is not a feature of Common Lisp.

Julieta Shem <jshem@yaxenu.org> writes:

> Axel Reichert <mail@axel-reichert.de> writes:
>
>> I somewhere read that Guile is the most Common-Lisp-like of the
>> Scheme implementations (if you ask for it, I will try to dig up the
>> link).
>
> Dig it up! Let's read it and discuss it. You're invited. :-)

https://ane.iki.fi/2020/10/05/between-two-lisps.html

Somewhat more biased, and, strictly speaking, off-topic here:

https://www.wingolog.org/archives/2013/01/07/an-opinionated-guide-to-scheme-implementations

> I think you would like to speak C.

Sure. Not only because there is an awful lot of open source software
written in it, but also due its enormous historical importance.

https://www.buildyourownlisp.com/

(Lisp in C) is on my Emacs/Org mode to-do list for quite some time ...

> What's the SD in Guix SD? Software distribution?

Ah, sorry, using the old name, nowadays it is just Guix System (the OS)
versus Guix, the package manager.

> I like keep the box small and I do choose tools that I can carry with
> me for a life time. That's another thing about Common Lisp that feels
> very good --- you find papers and books that are ``old'' and they
> describe things that are still exactly like they said.

Yes! When I searched around about the various Schemes, I became already
slightly annoyed: Which RxRSs are supported, which SRFIs are included,
etc.

> It doesn’t acquire bugs just by sitting around on your hard drive.

Non-perishable ...

Ideas rock.

Best regards

Axel

George Neuner <gneuner2@comcast.net> writes:

> Question is whether you want to write GUI programs. Then Armed Bear
> Common Lisp, Clojure or Racket have the edge ... Armed Bear and
> Clojure can use Java-based GUI builders and libraries, and Racket has
> its own builder and libraries.

Good point, but I am not affected, no GUI ambitions here.

Best regards

Axel

Axel Reichert <mail@axel-reichert.de> writes:

> George Neuner <gneuner2@comcast.net> writes:
>
>> Question is whether you want to write GUI programs. Then Armed Bear
>> Common Lisp, Clojure or Racket have the edge ... Armed Bear and
>> Clojure can use Java-based GUI builders and libraries, and Racket has
>> its own builder and libraries.
>
> Good point, but I am not affected, no GUI ambitions here.

Nor here.

Axel Reichert <mail@axel-reichert.de> writes:

> Julieta Shem <jshem@yaxenu.org> writes:
>
>> Axel Reichert <mail@axel-reichert.de> writes:
>>
>>> I somewhere read that Guile is the most Common-Lisp-like of the
>>> Scheme implementations (if you ask for it, I will try to dig up the
>>> link).
>>
>> Dig it up! Let's read it and discuss it. You're invited. :-)
>
> https://ane.iki.fi/2020/10/05/between-two-lisps.html

Fun to read. There isn't much I'd like to add or comment. I agreed
with everything I read.

> Somewhat more biased, and, strictly speaking, off-topic here:
>
> https://www.wingolog.org/archives/2013/01/07/an-opinionated-guide-to-scheme-implementations

Less fun to read.

Question. ``Use an existing implementation rather than writing your
own. Get good at using your REPL (or the IDE, in the case of Racket).''

I use ``IDE'' very loosely and it seems the author has a more precise
definition. It seems s/he says Racket has an IDE. I suppose DrRacket.
And somehow that means Racket doesn't have a REPL?

>> I think you would like to speak C.
>
> Sure. Not only because there is an awful lot of open source software
> written in it, but also due its enormous historical importance.

Yes. It feels good to be close to the operating system so that you know
exactly how things work.

> https://www.buildyourownlisp.com/
>
> (Lisp in C) is on my Emacs/Org mode to-do list for quite some time ...

You'll enjoy it! This book is great fun. Each picture is a joke. I
offered the author one of my jokes. First picture in chapter 9 at

https://www.buildyourownlisp.com/chapter9_s_expressions

The idea is: ``OLD LISP: YOU HAD TO YELL AT IT TO GET THINGS DONE''.

>> What's the SD in Guix SD? Software distribution?
>
> Ah, sorry, using the old name, nowadays it is just Guix System (the OS)
> versus Guix, the package manager.

And what did it mean?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>And also because their modern incarnations are quite different from how
>they were in the early days.

I'm just following my sentimentality when choosing a LISP dialect.
In other words, it has to be as similar as possible to the LISP
I used to write simple functions for symbolic differentiation
on my Pet 2001 when I was young. Something like this:

( SETQ DIFF
( LAMBDA( X )
( COND
( ( ATOMP X )
( COND
( ( = X 'X )
1 )
( T
0 )))
( T
( COND
( ( =( CAR X )'SUM )
( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

.

Julieta Shem <jshem@yaxenu.org> writes:

> Axel Reichert <mail@axel-reichert.de> writes:
>
>> https://www.wingolog.org/archives/2013/01/07/an-opinionated-guide-to-scheme-implementations
>
> Less fun to read.

Why so? Too much "advocacy"?

> Get good at using your REPL (or the IDE, in the case of Racket).''
>
> I use ``IDE'' very loosely

Same here. Is Emacs' lisp-interaction-mode an IDE? If not, is Emacs plus
Geiser a Scheme/Guile IDE? If not, is Emacs plus SLIME an IDE? I think
the amount of "support" a tool offers for programming is more a
continuum than either a REPL or an IDE.

> It seems s/he says Racket has an IDE. I suppose DrRacket.

Yes, that is probably meant.

> And somehow that means Racket doesn't have a REPL?

No. I suppose the author sees IDEs as supersets of REPLs, so if you have
access to the former, it is to be preferred.

>> https://www.buildyourownlisp.com/
>>
>> (Lisp in C) is on my Emacs/Org mode to-do list for quite some time ...
>
> You'll enjoy it! This book is great fun. Each picture is a joke.

Sounds good, thanks for your encouragement.

>> Ah, sorry, using the old name, nowadays it is just Guix System (the OS)
>> versus Guix, the package manager.
>
> And what did it mean?

"System Distribution", see

https://en.wikipedia.org/wiki/GNU_Guix_System

Best regards

Axel

On 11 Jan 2024 10:12:41 GMT, Stefan Ram wrote:

> ( SETQ DIFF
> ( LAMBDA( X )
> ...
> ( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))

That looks like some Lisp-1 (Scheme-type) dialect.

Also, we don’t like doing all uppercase code these days.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On 11 Jan 2024 10:12:41 GMT, Stefan Ram wrote:
>> ( SETQ DIFF
>> ( LAMBDA( X )
>> ...
>> ( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))
>That looks like some Lisp-1 (Scheme-type) dialect.

For now, I'm using, IIRC, "NewLisp" and

( setq SETQ setq )
( SETQ NULL null? )
( SETQ ATOMP atom? )
( SETQ T true )
( SETQ CAR first )
( SETQ CDR rest )
( SETQ PROGN begin )
( SETQ LENGTH length )
( SETQ COND cond )
( SETQ APPEND append )
( SETQ CADR( lambda( X )( CAR ( CDR X ))))
( SETQ CADDR( lambda( X )( CAR ( CDR ( CDR X )))))

. I was not able to convert "lambda" to uppercase, though.
So, I have to write:

( SETQ DIFF
( lambda( X )
( COND
...

.

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On 11 Jan 2024 10:12:41 GMT, Stefan Ram wrote:
>>> ( SETQ DIFF
>>> ( LAMBDA( X )
>>> ...
>>> ( LIST 'SUM( DIFF( CADR X ))( DIFF( CADDR X )))))))))
>>That looks like some Lisp-1 (Scheme-type) dialect.
>
> For now, I'm using, IIRC, "NewLisp" and
>
> ( setq SETQ setq )
> ( SETQ NULL null? )
> ( SETQ ATOMP atom? )
> ( SETQ T true )
> ( SETQ CAR first )
> ( SETQ CDR rest )
> ( SETQ PROGN begin )
> ( SETQ LENGTH length )
> ( SETQ COND cond )
> ( SETQ APPEND append )
> ( SETQ CADR( lambda( X )( CAR ( CDR X ))))
> ( SETQ CADDR( lambda( X )( CAR ( CDR ( CDR X )))))
>
> . I was not able to convert "lambda" to uppercase, though.
> So, I have to write:
>
> ( SETQ DIFF
> ( lambda( X )
> ( COND
> ...
>
> .

Likely because lambda is syntax, not a symbol.

Julieta Shem <jshem@yaxenu.org> writes:
>Likely because lambda is syntax, not a symbol.

The Hyper Spec (indirect quotation) does call "lambda" a "symbol":

|lambda expression n. a list which can be used in place of a
|function name in certain contexts to denote a function by
|directly describing its behavior rather than indirectly by
|referring to the name of an established function; its name
|derives from the fact that its first element is the symbol
|lambda.

. Since I use "NewLisp", what should be relevant in my case should
actually be NewLisp! The NewLisp manual says indeed:

|Note that the lambda keyword is not a symbol in a list,
|but a designator of a special type of list: the lambda list.

. Insofar, you are right when you say it's not a symbol!
It's a keyword (in NewLisp).

I'd hesitate to call lambda "syntax", but I thing you might meant
to say it's /part of/ the syntax, which is what a keyword is.

ram@zedat.fu-berlin.de (Stefan Ram) writes:

> Julieta Shem <jshem@yaxenu.org> writes:
>>Likely because lambda is syntax, not a symbol.
>
> The Hyper Spec (indirect quotation) does call "lambda" a "symbol":
>
> |lambda expression n. a list which can be used in place of a
> |function name in certain contexts to denote a function by
> |directly describing its behavior rather than indirectly by
> |referring to the name of an established function; its name
> |derives from the fact that its first element is the symbol
> |lambda.
>
> . Since I use "NewLisp", what should be relevant in my case should
> actually be NewLisp! The NewLisp manual says indeed:
>
> |Note that the lambda keyword is not a symbol in a list,
> |but a designator of a special type of list: the lambda list.
>
> . Insofar, you are right when you say it's not a symbol!
> It's a keyword (in NewLisp).
>
> I'd hesitate to call lambda "syntax", but I thing you might meant
> to say it's /part of/ the syntax, which is what a keyword is.

We'll never go wrong if we say it's just energy. :-)

On Wed, 10 Jan 2024 20:45:32 -0300, Julieta Shem <jshem@yaxenu.org>
wrote:

>
>It's hard to pinpoint what it is with Racket. Maybe I'm not good enough
>for Racket. Maybe I'm too stupid for Racket.

The full #racket language is very powerful and it can be difficult to
learn. However, there are a number of dedicated "learning" languages
which limit what the programmer can do, and have better error messages
to help newbies.

It also accepts standard R5RS and R6RS Scheme.

You can change the language the compiler accepts by putting #<lang> at
the top of the file, where <lang> is the language you want to use.

See the section on Teaching at https://docs.racket-lang.org/

George Neuner <gneuner2@comcast.net> writes:

> On Wed, 10 Jan 2024 20:45:32 -0300, Julieta Shem <jshem@yaxenu.org>
> wrote:
>>
>>It's hard to pinpoint what it is with Racket. Maybe I'm not good enough
>>for Racket. Maybe I'm too stupid for Racket.
>
> The full #racket language is very powerful and it can be difficult to
> learn. However, there are a number of dedicated "learning" languages
> which limit what the programmer can do, and have better error messages
> to help newbies.

--8<---------------cut here---------------start------------->8---
Everything I say below is about me. I'm not at all evaluating anyone's
work from a non-particular and non-personal perspective.
--8<---------------cut here---------------end--------------->8---

Their error messages are very clear in these teaching languages. I'm
very grateful for having read HtDP. I consider it very highly --- I
feel there is no other publication that matches it on the objective it
set for itself. It's a unique book in the whole world to the best of my
knowledge.

I think there might be a non-small gap between HtDP and the Racket
language. I think the authors might recognize this because some of them
also wrote other books on the Racket language. I would believe that
their advice for someone like me would be to, having read HtDP, follow
up with the ``Realm of Racket'', say, which I have /tried/ and confess
the gaming context was an obstacle --- it's not like I can't abstract
all that away and focus on the language only. (I despise computer
games.)

Let's take a look at Beautiful Racket, which I've also read. Marvelous
work in the sense of showing what Racket can do, but I think it fails in
teaching because when I read a programming language book I'm putting an
engineer hat and looking for intuition on how things work on the inside
so that I can manipulate those primitives and build something I can
dream up. Beautiful Racket gives you tools that hide how the language
works (in the spirit of easeing the burden on the beginner's shoulders),
so after finishing the book, you must still continue to dig to see the
deeper level. It's the opposite of a draft such as

https://felleisen.org/matthias/lp/

that I found by accident in the last days. It's been great reading for
me. Also in the last days I've been trying to read the Evaluation
Model, but it's a bit difficult for a beginner. The draft above is
helpful because it seems to show Racket works in a very simplified
manner from the ground up in a pedagogical context.

Another hypothesis I've been considering lately (to explain my failures)
is that Racket has been taking the language-orientation hard and that
doesn't help a beginner to climb up slowly (with my psychology and
background). Let me elaborate on this point. People here gave me the
try-Common-Lisp insight in the last days. I ``invented'' some
program-project to write in it and I've been writing it (very slowly)
and having a lot of fun. But why? I think it's because of the
permissiveness of Common Lisp. Here's an example. I created a macro
that avoided some redundancies but it actually needed a variable capture
to even do what I wanted. I wanted the very wrong thing. I did it, saw
it working and then found a way of not committing such ``grave'' crime.
In Racket, I think I would not even manage to pull something like that
off because the language is designed to avoid such crimes. This implies
I need proper education before I can play with it and that seems to hurt
my solo pedagogical adventure.

I believe that the more I do Common Lisp, the more I understand Racket.
By seeing the crime I was committing, I thought of Racket --- ``oh,
maybe that's why Racket macros must received syntax objects with lexical
and scope information to go along with it''. ``The compiler won't let
me mix them up unless I learn how to hack these objects myself, which
being so clueless here I wouldn't even know how to do --- bummer. I
can't continue to do what I want, so I can't continue my Racket writing
pratice. I need to continue my documentation harvesting and so on and
maybe some days later I can come back to the writing.'' Sure I can ask
for help and so on. I've been doing it. If a ladder is so steep that a
weak person can't go up, it seems to delay the moment where one finds
enough strength to go up.

I understand serious languages are designed to protect programmers from
making unwise things, but maybe that has an impact on education. Seeing
the lab explode is likely educational and things do not explode if
building the contraptions are sufficiently hard.

Keep in mind that I'm not asking the Racket language to be any easier on
me or somehow adapt to my psychology. I'm a USENET member, so I can
share my experience just for the fun of it. I should also say that
Common Lisp has allowed me in a few days to get an enthusiasm than I
haven't gotten with any Racket program I've written in the past --- I
wrote two small systems that worked in production for various years and
are now retired; both of them would periodically download information
from an API source, store it locally and serve it to other systems. I
totally consider that my Racket reading and (little) practice has surely
prepared me for having all the fun I'm having with Common Lisp in the
last days.

On Mon, 15 Jan 2024 00:32:11 -0300
Julieta Shem <jshem@yaxenu.org> wrote:

> example. I created a macro that avoided some redundancies but it
> actually needed a variable capture to even do what I wanted. I
> wanted the very wrong thing. I did it, saw it working and then found

Variable capture in macros isn't necessarily wrong. The book "Let Over
Lambda"[1] by Doug Hoyte presents some interesting examples of
intentional variable capture in Common Lisp macros.

[1] https://letoverlambda.com

On Mon, 15 Jan 2024 00:32:11 -0300, Julieta Shem <jshem@yaxenu.org>
wrote:

>George Neuner <gneuner2@comcast.net> writes:
>
>> On Wed, 10 Jan 2024 20:45:32 -0300, Julieta Shem <jshem@yaxenu.org>
>> wrote:
>>>
>>>It's hard to pinpoint what it is with Racket. Maybe I'm not good enough
>>>for Racket. Maybe I'm too stupid for Racket.
>>
>> The full #racket language is very powerful and it can be difficult to
>> learn. However, there are a number of dedicated "learning" languages
>> which limit what the programmer can do, and have better error messages
>> to help newbies.
>
>--8<---------------cut here---------------start------------->8---
>Everything I say below is about me. I'm not at all evaluating anyone's
>work from a non-particular and non-personal perspective.
>--8<---------------cut here---------------end--------------->8---
>
>Their error messages are very clear in these teaching languages. I'm
>very grateful for having read HtDP. I consider it very highly --- I
>feel there is no other publication that matches it on the objective it
>set for itself. It's a unique book in the whole world to the best of my
>knowledge.
>
>I think there might be a non-small gap between HtDP and the Racket
>language. I think the authors might recognize this because some of them
>also wrote other books on the Racket language. I would believe that
>their advice for someone like me would be to, having read HtDP, follow
>up with the ``Realm of Racket'', say, which I have /tried/ and confess
>the gaming context was an obstacle --- it's not like I can't abstract
>all that away and focus on the language only. (I despise computer
>games.)
>
>Let's take a look at Beautiful Racket, which I've also read. Marvelous
>work in the sense of showing what Racket can do, but I think it fails in
>teaching because when I read a programming language book I'm putting an
>engineer hat and looking for intuition on how things work on the inside
>so that I can manipulate those primitives and build something I can
>dream up. Beautiful Racket gives you tools that hide how the language
>works (in the spirit of easeing the burden on the beginner's shoulders),
>so after finishing the book, you must still continue to dig to see the
>deeper level. It's the opposite of a draft such as
>
> https://felleisen.org/matthias/lp/
>
>that I found by accident in the last days. It's been great reading for
>me. Also in the last days I've been trying to read the Evaluation
>Model, but it's a bit difficult for a beginner. The draft above is
>helpful because it seems to show Racket works in a very simplified
>manner from the ground up in a pedagogical context.
>
>Another hypothesis I've been considering lately (to explain my failures)
>is that Racket has been taking the language-orientation hard and that
>doesn't help a beginner to climb up slowly (with my psychology and
>background). Let me elaborate on this point. People here gave me the
>try-Common-Lisp insight in the last days. I ``invented'' some
>program-project to write in it and I've been writing it (very slowly)
>and having a lot of fun. But why? I think it's because of the
>permissiveness of Common Lisp. Here's an example. I created a macro
>that avoided some redundancies but it actually needed a variable capture
>to even do what I wanted. I wanted the very wrong thing. I did it, saw
>it working and then found a way of not committing such ``grave'' crime.
>In Racket, I think I would not even manage to pull something like that
>off because the language is designed to avoid such crimes. This implies
>I need proper education before I can play with it and that seems to hurt
>my solo pedagogical adventure.
>
>I believe that the more I do Common Lisp, the more I understand Racket.
>By seeing the crime I was committing, I thought of Racket --- ``oh,
>maybe that's why Racket macros must received syntax objects with lexical
>and scope information to go along with it''. ``The compiler won't let
>me mix them up unless I learn how to hack these objects myself, which
>being so clueless here I wouldn't even know how to do --- bummer. I
>can't continue to do what I want, so I can't continue my Racket writing
>pratice. I need to continue my documentation harvesting and so on and
>maybe some days later I can come back to the writing.'' Sure I can ask
>for help and so on. I've been doing it. If a ladder is so steep that a
>weak person can't go up, it seems to delay the moment where one finds
>enough strength to go up.
>
>I understand serious languages are designed to protect programmers from
>making unwise things, but maybe that has an impact on education. Seeing
>the lab explode is likely educational and things do not explode if
>building the contraptions are sufficiently hard.
>
>Keep in mind that I'm not asking the Racket language to be any easier on
>me or somehow adapt to my psychology. I'm a USENET member, so I can
>share my experience just for the fun of it. I should also say that
>Common Lisp has allowed me in a few days to get an enthusiasm than I
>haven't gotten with any Racket program I've written in the past --- I
>wrote two small systems that worked in production for various years and
>are now retired; both of them would periodically download information
>from an API source, store it locally and serve it to other systems. I
>totally consider that my Racket reading and (little) practice has surely
>prepared me for having all the fun I'm having with Common Lisp in the
>last days.

I never read any of those books 8-) I learned Scheme and dabbled with
Lisp long before Racket existed.

The thing to keep in mind is that Racket essentially is an enhanced
Scheme. *Most* of what you learn re: Scheme is transferable to
Racket. The major difference is that, by default, Racket has
immutable pairs (conses) and structs - so, e.g., simple demo programs
that use set-car! and set-cdr! just won't work.

Making your structs mutable is an option - the default idiom is RAII.

Also optional are immutable strings, vectors, hashtables, boxes, etc.
[some things can be done more efficiently when the compiler knows the
data won't change].

And if you really DO need mutable pairs in Racket, they do exist - but
as a separate type called 'mpair'. Or you can use #lang R5RS or R6RS
for code that needs mutable pairs. Any #lang module can export
functions to be used by any other #lang module.

[Honestly, except for a quick hack job, I have never had a use for
mutable pairs. Anything you can do with a pair is better done with a
struct or a box. That goes for Lisp as well.]

And for the rest: anything beyond what is in R_RS Scheme necessarily
is implementation specific. Racket has more to learn than some other
implementations because, out-of-the-box, it addresses many programming
tasks ... but you learn things as you need them.

Typically it takes years to become really proficient with most
languages and/or their implementations: standard libraries, runtimes,
etc. Why should Racket be any different?

YMMV,
George

Julieta Shem <jshem@yaxenu.org> writes:

> having read HtDP. I consider it very highly

Yes, a nice and well-structured book.

> Beautiful Racket gives you tools that hide how the language works (in
> the spirit of easeing the burden on the beginner's shoulders), so
> after finishing the book, you must still continue to dig to see the
> deeper level.

Well, aren't Lisps supposed to be extremely high-level languages?

> It's the opposite of a draft such as
>
> https://felleisen.org/matthias/lp/
>
> that I found by accident in the last days.

Thanks for the pointer, I did not know it.

> I created a macro that avoided some redundancies but it actually
> needed a variable capture to even do what I wanted.

Could it be that you re-invented anaphoric macros?

https://unintelligible.org/onlisp/onlisp.html#SEC99

"On Lisp" as a whole will probably suit you well.

> I wanted the very wrong thing. I did it, saw it working and then
> found a way of not committing such ``grave'' crime.

With your C background you should know that you can do many things as
long as you know what you are doing. (-:

Best regards

Axel

Axel Reichert <mail@axel-reichert.de> writes:

> Julieta Shem <jshem@yaxenu.org> writes:

[...]

>> Beautiful Racket gives you tools that hide how the language works (in
>> the spirit of easeing the burden on the beginner's shoulders), so
>> after finishing the book, you must still continue to dig to see the
>> deeper level.
>
> Well, aren't Lisps supposed to be extremely high-level languages?

The context here is Beautiful Racket. Instead of teaching you how to
use the Racket primitives, it teaches you how to use its own primitives.
So in practice you learn the Beautiful Racket language, not Racket. It
works like a tour to see what the Racket language can do if you master
it --- likely its very objective. But then when you're done, you still
need to study the Racket language. And with a POSIX background, you'll
wonder where things are in the Racket language as well.

It's the language barrier. You may know what you want to say, but if
you're in a new world you still need to learn all the new world's ways.

>> I created a macro that avoided some redundancies but it actually
>> needed a variable capture to even do what I wanted.
>
> Could it be that you re-invented anaphoric macros?
>
> https://unintelligible.org/onlisp/onlisp.html#SEC99

Thank you for the name of it. Paolo Amoroso had already pointed out
Doug Hoyte's book. (Thanks, Paolo.)

> "On Lisp" as a whole will probably suit you well.

Thank you!

Paolo Amoroso <info@paoloamoroso.com> writes:

> On Mon, 15 Jan 2024 00:32:11 -0300
> Julieta Shem <jshem@yaxenu.org> wrote:
>
>> example. I created a macro that avoided some redundancies but it
>> actually needed a variable capture to even do what I wanted. I
>> wanted the very wrong thing. I did it, saw it working and then found
>
> Variable capture in macros isn't necessarily wrong. The book "Let Over
> Lambda"[1] by Doug Hoyte presents some interesting examples of
> intentional variable capture in Common Lisp macros.

Thank you! I think that's chapter 6, anaphoric macros.

Julieta Shem <jshem@yaxenu.org> writes:

>> Could it be that you re-invented anaphoric macros?
>>
>> https://unintelligible.org/onlisp/onlisp.html#SEC99
>
> Thank you for the name of it. Paolo Amoroso had already pointed out
> Doug Hoyte's book. (Thanks, Paolo.)
>
>> "On Lisp" as a whole will probably suit you well.
>
> Thank you!

.... and will be far easier than "Let Over Lambda" (but still quite
advanced).

Best regards

Axel