#schemelang — Public Fediverse posts

The challenge of writing portable Scheme code is that every implementation has myriad little idiosyncrasies. Today I discovered the #MITScheme tries to read #Emacs -style file header comments (for example ;; -*- encoding: utf-8 -*-) and this can cause the reader to crash for some reason. I am not sure if it is a bug or a feature, but it did throw me off for a whole day while I tried to figure out why MIT Scheme wouldn’t compile a library file.

I also happen to be hung-up on a bug in #Guile 3.0.11. It seems to me like the optimizer is emitting bad code, because I get a SEGFAULT on an expression that #Gauche has no trouble executing. I am still working on a bug report, and trying to figure out a work-around.

#tech #software #Scheme #Schemacs #SchemeLang #R7RS #Lisp #GuileScheme #GaucheScheme

The challenge of writing portable Scheme code is that every implementation has myriad little idiosyncrasies. Today I discovered the #MITScheme tries to read #Emacs -style file header comments (for example ;; -*- encoding: utf-8 -*-) and this can cause the reader to crash for some reason. I am not sure if it is a bug or a feature, but it did throw me off for a whole day while I tried to figure out why MIT Scheme wouldn’t compile a library file.

I also happen to be hung-up on a bug in #Guile 3.0.11. It seems to me like the optimizer is emitting bad code, because I get a SEGFAULT on an expression that #Gauche has no trouble executing. I am still working on a bug report, and trying to figure out a work-around.

#tech #software #Scheme #Schemacs #SchemeLang #R7RS #Lisp #GuileScheme #GaucheScheme

The challenge of writing portable Scheme code is that every implementation has myriad little idiosyncrasies. Today I discovered the #MITScheme tries to read #Emacs -style file header comments (for example ;; -*- encoding: utf-8 -*-) and this can cause the reader to crash for some reason. I am not sure if it is a bug or a feature, but it did throw me off for a whole day while I tried to figure out why MIT Scheme wouldn’t compile a library file.

I also happen to be hung-up on a bug in #Guile 3.0.11. It seems to me like the optimizer is emitting bad code, because I get a SEGFAULT on an expression that #Gauche has no trouble executing. I am still working on a bug report, and trying to figure out a work-around.

#tech #software #Scheme #Schemacs #SchemeLang #R7RS #Lisp #GuileScheme #GaucheScheme

The challenge of writing portable Scheme code is that every implementation has myriad little idiosyncrasies. Today I discovered the #MITScheme tries to read #Emacs -style file header comments (for example ;; -*- encoding: utf-8 -*-) and this can cause the reader to crash for some reason. I am not sure if it is a bug or a feature, but it did throw me off for a whole day while I tried to figure out why MIT Scheme wouldn’t compile a library file.

I also happen to be hung-up on a bug in #Guile 3.0.11. It seems to me like the optimizer is emitting bad code, because I get a SEGFAULT on an expression that #Gauche has no trouble executing. I am still working on a bug report, and trying to figure out a work-around.

#tech #software #Scheme #Schemacs #SchemeLang #R7RS #Lisp #GuileScheme #GaucheScheme

CHICKEN Scheme 6.0 has been released:

https://call-cc.org

#SchemeLang #Scheme #Lisp

CHICKEN Scheme 6.0 has been released:

https://call-cc.org

#SchemeLang #Scheme #Lisp

CHICKEN Scheme 6.0 has been released:

https://call-cc.org

#SchemeLang #Scheme #Lisp

CHICKEN Scheme 6.0 has been released:

https://call-cc.org

#SchemeLang #Scheme #Lisp

CHICKEN Scheme 6.0 has been released:

https://call-cc.org

#SchemeLang #Scheme #Lisp

I am starting to become very annoyed with #Guile Scheme because they are so far behind in providing some very important modern SRFIs.

Of course I could implement these myself and submit a patch, but in the mean time I would have to wait for my patch to be accepted and distributed in the next Guile version. And while I waited I would have to just implement these SRFIs in my own source code for myself. I don’t have time, so I always end up just implementing the APIs that I need for my own project, usually as a wrapper around some other Guile API that does provide that functionality but in a non-standard way.

For the past two years or so I have kept on running into issues caused by the fact that Guile does not provide SRFI-125 (hash tables) and SRFI-128 (comparators). Guile provides SRFI-69 (the old hash tables) but it doesn’t use comparators, and so the semantics for things like make-hash-table and alist->hash-table in Guile are not compatible with most other R7RS-compliant Scheme implementations. I keep having to go back and update various cond-expand statements to get around this. Some data structures are so fundamental to modern software that you just can’t do without them. Providing these SRFIs should really be a priority.

Also the following would be really nice to have in Guile, like really soon:

• SRFI-160: homogeneous numerical vectors, Guile only provides the older version of it, SRFI-4.
• SRFI-170: POSIX API: Guile provides all of these APIs but not always in a way that follows SRFI-170.
• SRFI-180: JSON, Guile provides all of these APIs but not fully compatible with SRFI-180.
• SRFI-181: Custom ports, Guile provides similar features built-in but not in a way that follows SRFI-181.

#tech #software #Lisp #SchemeLang #Scheme #R7RS #GuileScheme #FunctionalProgramming

I am starting to become very annoyed with #Guile Scheme because they are so far behind in providing some very important modern SRFIs.

Of course I could implement these myself and submit a patch, but in the mean time I would have to wait for my patch to be accepted and distributed in the next Guile version. And while I waited I would have to just implement these SRFIs in my own source code for myself. I don’t have time, so I always end up just implementing the APIs that I need for my own project, usually as a wrapper around some other Guile API that does provide that functionality but in a non-standard way.

For the past two years or so I have kept on running into issues caused by the fact that Guile does not provide SRFI-125 (hash tables) and SRFI-128 (comparators). Guile provides SRFI-69 (the old hash tables) but it doesn’t use comparators, and so the semantics for things like make-hash-table and alist->hash-table in Guile are not compatible with most other R7RS-compliant Scheme implementations. I keep having to go back and update various cond-expand statements to get around this. Some data structures are so fundamental to modern software that you just can’t do without them. Providing these SRFIs should really be a priority.

Also the following would be really nice to have in Guile, like really soon:

• SRFI-160: homogeneous numerical vectors, Guile only provides the older version of it, SRFI-4.
• SRFI-170: POSIX API: Guile provides all of these APIs but not always in a way that follows SRFI-170.
• SRFI-180: JSON, Guile provides all of these APIs but not fully compatible with SRFI-180.
• SRFI-181: Custom ports, Guile provides similar features built-in but not in a way that follows SRFI-181.

#tech #software #Lisp #SchemeLang #Scheme #R7RS #GuileScheme #FunctionalProgramming

I am starting to become very annoyed with #Guile Scheme because they are so far behind in providing some very important modern SRFIs.

Of course I could implement these myself and submit a patch, but in the mean time I would have to wait for my patch to be accepted and distributed in the next Guile version. And while I waited I would have to just implement these SRFIs in my own source code for myself. I don’t have time, so I always end up just implementing the APIs that I need for my own project, usually as a wrapper around some other Guile API that does provide that functionality but in a non-standard way.

For the past two years or so I have kept on running into issues caused by the fact that Guile does not provide SRFI-125 (hash tables) and SRFI-128 (comparators). Guile provides SRFI-69 (the old hash tables) but it doesn’t use comparators, and so the semantics for things like make-hash-table and alist->hash-table in Guile are not compatible with most other R7RS-compliant Scheme implementations. I keep having to go back and update various cond-expand statements to get around this. Some data structures are so fundamental to modern software that you just can’t do without them. Providing these SRFIs should really be a priority.

Also the following would be really nice to have in Guile, like really soon:

• SRFI-160: homogeneous numerical vectors, Guile only provides the older version of it, SRFI-4.
• SRFI-170: POSIX API: Guile provides all of these APIs but not always in a way that follows SRFI-170.
• SRFI-180: JSON, Guile provides all of these APIs but not fully compatible with SRFI-180.
• SRFI-181: Custom ports, Guile provides similar features built-in but not in a way that follows SRFI-181.

#tech #software #Lisp #SchemeLang #Scheme #R7RS #GuileScheme #FunctionalProgramming

I am starting to become very annoyed with #Guile Scheme because they are so far behind in providing some very important modern SRFIs.

Of course I could implement these myself and submit a patch, but in the mean time I would have to wait for my patch to be accepted and distributed in the next Guile version. And while I waited I would have to just implement these SRFIs in my own source code for myself. I don’t have time, so I always end up just implementing the APIs that I need for my own project, usually as a wrapper around some other Guile API that does provide that functionality but in a non-standard way.

For the past two years or so I have kept on running into issues caused by the fact that Guile does not provide SRFI-125 (hash tables) and SRFI-128 (comparators). Guile provides SRFI-69 (the old hash tables) but it doesn’t use comparators, and so the semantics for things like make-hash-table and alist->hash-table in Guile are not compatible with most other R7RS-compliant Scheme implementations. I keep having to go back and update various cond-expand statements to get around this. Some data structures are so fundamental to modern software that you just can’t do without them. Providing these SRFIs should really be a priority.

Also the following would be really nice to have in Guile, like really soon:

• SRFI-160: homogeneous numerical vectors, Guile only provides the older version of it, SRFI-4.
• SRFI-170: POSIX API: Guile provides all of these APIs but not always in a way that follows SRFI-170.
• SRFI-180: JSON, Guile provides all of these APIs but not fully compatible with SRFI-180.
• SRFI-181: Custom ports, Guile provides similar features built-in but not in a way that follows SRFI-181.

#tech #software #Lisp #SchemeLang #Scheme #R7RS #GuileScheme #FunctionalProgramming

A person called Jonathan Kraut wrote an #assembler called Sassy in #R5RS #Scheme, which is used as the native code generating phase for the Larceny scheme compiler.

#tech #Software #SchemeLang #IA32 #FunctionalProgramming #Compiler

A person called Jonathan Kraut wrote an #assembler called Sassy in #R5RS #Scheme, which is used as the native code generating phase for the Larceny scheme compiler.

#tech #Software #SchemeLang #IA32 #FunctionalProgramming #Compiler

A person called Jonathan Kraut wrote an #assembler called Sassy in #R5RS #Scheme, which is used as the native code generating phase for the Larceny scheme compiler.

#tech #Software #SchemeLang #IA32 #FunctionalProgramming #Compiler

A person called Jonathan Kraut wrote an #assembler called Sassy in #R5RS #Scheme, which is used as the native code generating phase for the Larceny scheme compiler.

#tech #Software #SchemeLang #IA32 #FunctionalProgramming #Compiler

Apropos of nothing: Big thanks to Shiro Kawai for creating Gauche Scheme, which so far has been one of the best Scheme implementations I have used. It has worked well on every computer I have tried it on so far ({Linux, FreeBSD, MacOS} x {x86_64, i386, aarch64}). It is stable, very fast, and supports a large number of the more recent SRFIs (Scheme language extensions), it has very good compatibility with the R7RS language standard, and the Gauche REPL gosh is pretty easy to use as well.

I always run the REPL in R7RS mode, so gosh -r7 -I. -i . Scheme people, give it a try sometime if you haven’t already!

https://practical-scheme.net/gauche/

#tech #software #Scheme #R7RS #Lisp #SchemeLang #FunctionalProgramming #Gauche

Apropos of nothing: Big thanks to Shiro Kawai for creating Gauche Scheme, which so far has been one of the best Scheme implementations I have used. It has worked well on every computer I have tried it on so far ({Linux, FreeBSD, MacOS} x {x86_64, i386, aarch64}). It is stable, very fast, and supports a large number of the more recent SRFIs (Scheme language extensions), it has very good compatibility with the R7RS language standard, and the Gauche REPL gosh is pretty easy to use as well.

I always run the REPL in R7RS mode, so gosh -r7 -I. -i . Scheme people, give it a try sometime if you haven’t already!

https://practical-scheme.net/gauche/

#tech #software #Scheme #R7RS #Lisp #SchemeLang #FunctionalProgramming #Gauche

Apropos of nothing: Big thanks to Shiro Kawai for creating Gauche Scheme, which so far has been one of the best Scheme implementations I have used. It has worked well on every computer I have tried it on so far ({Linux, FreeBSD, MacOS} x {x86_64, i386, aarch64}). It is stable, very fast, and supports a large number of the more recent SRFIs (Scheme language extensions), it has very good compatibility with the R7RS language standard, and the Gauche REPL gosh is pretty easy to use as well.

I always run the REPL in R7RS mode, so gosh -r7 -I. -i . Scheme people, give it a try sometime if you haven’t already!

https://practical-scheme.net/gauche/

#tech #software #Scheme #R7RS #Lisp #SchemeLang #FunctionalProgramming #Gauche

Apropos of nothing: Big thanks to Shiro Kawai for creating Gauche Scheme, which so far has been one of the best Scheme implementations I have used. It has worked well on every computer I have tried it on so far ({Linux, FreeBSD, MacOS} x {x86_64, i386, aarch64}). It is stable, very fast, and supports a large number of the more recent SRFIs (Scheme language extensions), it has very good compatibility with the R7RS language standard, and the Gauche REPL gosh is pretty easy to use as well.

I always run the REPL in R7RS mode, so gosh -r7 -I. -i . Scheme people, give it a try sometime if you haven’t already!

https://practical-scheme.net/gauche/

#tech #software #Scheme #R7RS #Lisp #SchemeLang #FunctionalProgramming #Gauche

Here is a fresh Ur-LISP for DOS: "SLED - Schemy Lisp en DOS":

https://sled.neocities.org

#RetroProgramming #RetroComputing
#Lisp #Scheme #SchemeLang
#DOS #FreeDOS #MSDOS #DOSBox

Here is a fresh Ur-LISP for DOS: "SLED - Schemy Lisp en DOS":

https://sled.neocities.org

#RetroProgramming #RetroComputing
#Lisp #Scheme #SchemeLang
#DOS #FreeDOS #MSDOS #DOSBox

Here is a fresh Ur-LISP for DOS: "SLED - Schemy Lisp en DOS":

https://sled.neocities.org

#RetroProgramming #RetroComputing
#Lisp #Scheme #SchemeLang
#DOS #FreeDOS #MSDOS #DOSBox

Here is a fresh Ur-LISP for DOS: "SLED - Schemy Lisp en DOS":

https://sled.neocities.org

#RetroProgramming #RetroComputing
#Lisp #Scheme #SchemeLang
#DOS #FreeDOS #MSDOS #DOSBox

Here is a fresh Ur-LISP for DOS: "SLED - Schemy Lisp en DOS":

https://sled.neocities.org

#RetroProgramming #RetroComputing
#Lisp #Scheme #SchemeLang
#DOS #FreeDOS #MSDOS #DOSBox

I am borrowing the term, “The Prime Directive,” from the popular science fiction series Star Trek to describe my AI policy:

Every single line of code, every S-expression, every comment, every piece of documentation, every part of this software that serves a function must have that function be well-understood by at least one person (and of course, AI is not a person).

The term “well understood” is deliberately vague so that we (the Schemacs developer community) can decide on a case-by-case basis whether a person understands a function well enough.

Vibe coding is banned.

The definition of “Vibe Coding” is that you don’t bother to understand what the computer code means, if the software appears to behave in the way you expect you declare the code “correct.” By definition, vibe coding violates the Software Engineer’s Prime Directive.

Some LLM-generated output is OK.

If you suffer from some form of disability, and use an AI coding assistant to write code faster, this is perfectly acceptable so long you adhere to the Prime Directive — you must be able to defend the code you write by explaining the function of all of it’s component parts.

The term “disability” is deliberately vague because I don’t believe we as a community should define tests to decide whether someone qualifies as “having a disability.” If your disability is that you don’t like writing text, that is fine. Just obey the Prime Directive.

Unofficial AI Policy: we don’t need it.

This is a project for people to have fun. If you don’t like writing computer code, then don’t contribute computer code. There are plenty of other ways to contribute without needing AI coding.

There is no hurry, there is no deadline. Write code because you enjoy it, or because you want to learn how computers work. It is OK to take your time and enjoy yourself. There is really no reason to use AI for this project.

#tech #software #AI #LLMs #LLM #Scheme #R7RS #SchemeLang #Lisp #Schemacs #Emacs #EmacsLisp #Slop #VibeCoding #ClaudeCode #ChatGPT #SlopMachine

I am borrowing the term, “The Prime Directive,” from the popular science fiction series Star Trek to describe my AI policy:

Every single line of code, every S-expression, every comment, every piece of documentation, every part of this software that serves a function must have that function be well-understood by at least one person (and of course, AI is not a person).

The term “well understood” is deliberately vague so that we (the Schemacs developer community) can decide on a case-by-case basis whether a person understands a function well enough.

Vibe coding is banned.

The definition of “Vibe Coding” is that you don’t bother to understand what the computer code means, if the software appears to behave in the way you expect you declare the code “correct.” By definition, vibe coding violates the Software Engineer’s Prime Directive.

Some LLM-generated output is OK.

If you suffer from some form of disability, and use an AI coding assistant to write code faster, this is perfectly acceptable so long you adhere to the Prime Directive — you must be able to defend the code you write by explaining the function of all of it’s component parts.

The term “disability” is deliberately vague because I don’t believe we as a community should define tests to decide whether someone qualifies as “having a disability.” If your disability is that you don’t like writing text, that is fine. Just obey the Prime Directive.

Unofficial AI Policy: we don’t need it.

This is a project for people to have fun. If you don’t like writing computer code, then don’t contribute computer code. There are plenty of other ways to contribute without needing AI coding.

There is no hurry, there is no deadline. Write code because you enjoy it, or because you want to learn how computers work. It is OK to take your time and enjoy yourself. There is really no reason to use AI for this project.

#tech #software #AI #LLMs #LLM #Scheme #R7RS #SchemeLang #Lisp #Schemacs #Emacs #EmacsLisp #Slop #VibeCoding #ClaudeCode #ChatGPT #SlopMachine

I am borrowing the term, “The Prime Directive,” from the popular science fiction series Star Trek to describe my AI policy:

Every single line of code, every S-expression, every comment, every piece of documentation, every part of this software that serves a function must have that function be well-understood by at least one person (and of course, AI is not a person).

The term “well understood” is deliberately vague so that we (the Schemacs developer community) can decide on a case-by-case basis whether a person understands a function well enough.

Vibe coding is banned.

The definition of “Vibe Coding” is that you don’t bother to understand what the computer code means, if the software appears to behave in the way you expect you declare the code “correct.” By definition, vibe coding violates the Software Engineer’s Prime Directive.

Some LLM-generated output is OK.

If you suffer from some form of disability, and use an AI coding assistant to write code faster, this is perfectly acceptable so long you adhere to the Prime Directive — you must be able to defend the code you write by explaining the function of all of it’s component parts.

The term “disability” is deliberately vague because I don’t believe we as a community should define tests to decide whether someone qualifies as “having a disability.” If your disability is that you don’t like writing text, that is fine. Just obey the Prime Directive.

Unofficial AI Policy: we don’t need it.

This is a project for people to have fun. If you don’t like writing computer code, then don’t contribute computer code. There are plenty of other ways to contribute without needing AI coding.

There is no hurry, there is no deadline. Write code because you enjoy it, or because you want to learn how computers work. It is OK to take your time and enjoy yourself. There is really no reason to use AI for this project.

#tech #software #AI #LLMs #LLM #Scheme #R7RS #SchemeLang #Lisp #Schemacs #Emacs #EmacsLisp #Slop #VibeCoding #ClaudeCode #ChatGPT #SlopMachine

I am borrowing the term, “The Prime Directive,” from the popular science fiction series Star Trek to describe my AI policy:

Every single line of code, every S-expression, every comment, every piece of documentation, every part of this software that serves a function must have that function be well-understood by at least one person (and of course, AI is not a person).

The term “well understood” is deliberately vague so that we (the Schemacs developer community) can decide on a case-by-case basis whether a person understands a function well enough.

Vibe coding is banned.

The definition of “Vibe Coding” is that you don’t bother to understand what the computer code means, if the software appears to behave in the way you expect you declare the code “correct.” By definition, vibe coding violates the Software Engineer’s Prime Directive.

Some LLM-generated output is OK.

If you suffer from some form of disability, and use an AI coding assistant to write code faster, this is perfectly acceptable so long you adhere to the Prime Directive — you must be able to defend the code you write by explaining the function of all of it’s component parts.

The term “disability” is deliberately vague because I don’t believe we as a community should define tests to decide whether someone qualifies as “having a disability.” If your disability is that you don’t like writing text, that is fine. Just obey the Prime Directive.

Unofficial AI Policy: we don’t need it.

This is a project for people to have fun. If you don’t like writing computer code, then don’t contribute computer code. There are plenty of other ways to contribute without needing AI coding.

There is no hurry, there is no deadline. Write code because you enjoy it, or because you want to learn how computers work. It is OK to take your time and enjoy yourself. There is really no reason to use AI for this project.

#tech #software #AI #LLMs #LLM #Scheme #R7RS #SchemeLang #Lisp #Schemacs #Emacs #EmacsLisp #Slop #VibeCoding #ClaudeCode #ChatGPT #SlopMachine

மானியக்கடன் (SUBSIDIZED) வழங்கும் முகாம் 2026 -திண்டுக்கல் மாவட்டம் நடைபெறும் நாள் 16.07.2026

More details : https://tinyurl.com/jfbuxk9r

#subsidyrestructuring #loans #subsidized #schemelang #BreakingNews #Tamilpost

மானியக்கடன் (SUBSIDIZED) வழங்கும் முகாம் 2026 -திண்டுக்கல் மாவட்டம் நடைபெறும் நாள் 16.07.2026

More details : https://tinyurl.com/jfbuxk9r

#subsidyrestructuring #loans #subsidized #schemelang #BreakingNews #Tamilpost

மானியக்கடன் (SUBSIDIZED) வழங்கும் முகாம் 2026 -திண்டுக்கல் மாவட்டம் நடைபெறும் நாள் 16.07.2026

More details : https://tinyurl.com/jfbuxk9r

#subsidyrestructuring #loans #subsidized #schemelang #BreakingNews #Tamilpost

Brings Erlang’s lightweight threads model to #ChezScheme and is programmable with ordinary #Scheme S-expressions. The most obvious use case for this would be a highly scalable web server that would be very easy to develop and upgrade on the fly without re-deploying after every change to the API.

Guile could probably do something like this using @wingo ‘s Guile Fibers. I could see this being ported to Guile as well.

EDIT: this was made by Guenchi. So that’s what she was working on all this time.

Two of her projects made the front page of HN twice today. I hope people don’t see her old, abandoned “Schemacs” project and confuse it with the one I am making.

#tech #software #SchemeLang #R6RS

Brings Erlang’s lightweight threads model to #ChezScheme and is programmable with ordinary #Scheme S-expressions. The most obvious use case for this would be a highly scalable web server that would be very easy to develop and upgrade on the fly without re-deploying after every change to the API.

Guile could probably do something like this using @wingo ‘s Guile Fibers. I could see this being ported to Guile as well.

EDIT: this was made by Guenchi. So that’s what she was working on all this time.

Two of her projects made the front page of HN twice today. I hope people don’t see her old, abandoned “Schemacs” project and confuse it with the one I am making.

#tech #software #SchemeLang #R6RS

Brings Erlang’s lightweight threads model to #ChezScheme and is programmable with ordinary #Scheme S-expressions. The most obvious use case for this would be a highly scalable web server that would be very easy to develop and upgrade on the fly without re-deploying after every change to the API.

Guile could probably do something like this using @wingo ‘s Guile Fibers. I could see this being ported to Guile as well.

EDIT: this was made by Guenchi. So that’s what she was working on all this time.

Two of her projects made the front page of HN twice today. I hope people don’t see her old, abandoned “Schemacs” project and confuse it with the one I am making.

#tech #software #SchemeLang #R6RS

Brings Erlang’s lightweight threads model to #ChezScheme and is programmable with ordinary #Scheme S-expressions. The most obvious use case for this would be a highly scalable web server that would be very easy to develop and upgrade on the fly without re-deploying after every change to the API.

Guile could probably do something like this using @wingo ‘s Guile Fibers. I could see this being ported to Guile as well.

EDIT: this was made by Guenchi. So that’s what she was working on all this time.

Two of her projects made the front page of HN twice today. I hope people don’t see her old, abandoned “Schemacs” project and confuse it with the one I am making.

#tech #software #SchemeLang #R6RS

#LuaLang is probably my fav imperative language and #RacketLang or #SchemeLang my fav functional one. Can't decide between Racket and Scheme, I want to like Scheme more but I have much more experience with Racket.

#LuaLang is probably my fav imperative language and #RacketLang or #SchemeLang my fav functional one. Can't decide between Racket and Scheme, I want to like Scheme more but I have much more experience with Racket.

#LuaLang is probably my fav imperative language and #RacketLang or #SchemeLang my fav functional one. Can't decide between Racket and Scheme, I want to like Scheme more but I have much more experience with Racket.

R7RS Large has seen a new release and now #SchemeLang has nested defines.

I was reading it and was like, wasn’t that there forever? Then I remembered I been programming in #RacketLang 😹😹😹

R7RS Large has seen a new release and now #SchemeLang has nested defines.

I was reading it and was like, wasn’t that there forever? Then I remembered I been programming in #RacketLang 😹😹😹

R7RS Large has seen a new release and now #SchemeLang has nested defines.

I was reading it and was like, wasn’t that there forever? Then I remembered I been programming in #RacketLang 😹😹😹

R7RS Large has seen a new release and now #SchemeLang has nested defines.

I was reading it and was like, wasn’t that there forever? Then I remembered I been programming in #RacketLang 😹😹😹

R7RS Large has seen a new release and now #SchemeLang has nested defines.

I was reading it and was like, wasn’t that there forever? Then I remembered I been programming in #RacketLang 😹😹😹

(Reposting a blog post by @zyd copy-pasted in full from: this webpage)

As of 2026-05-18 … sort of.

Every Lisp, Scheme, and Lisp-adjacent project listed is a non-toy implementation that is at least somewhat active. When I first wrote this article (2026-03-12), most Lisps did not have a policy or even public stance on LLM contributions. In such cases I posted to their bug trackers or discussion lists to ask. Most maintainers kindly responded.

Every link is either a document or issue stating the project’s LLM policy, or a link to an open issue. Roughly categorized according to how strongly for or against LLM contributions.

If I’m missing a project that should be listed, lemme know.

• Fennel
• STklos Scheme
• Clojure
• ECL

• Loko Scheme

• Janet exception given for tests and bug reproductions
• GNU CLISP against on a specific reading of copyright law
• Emacs Lisp temporarily against LLMs, waiting for official policy
• Hy maintainer recommends against LLM contributions, no actual policy

• Chicken Scheme
• Chibi Scheme
• Cyclone Scheme
• Gambit
• Gauche
• Gerbil Scheme LLM generated code potentially in source tree
• Clasp
• CCL

• Bigloo
• Coalton
• Kawa Scheme
• Sagittarius Scheme
• Jank doesn’t accept external LLM contributions but permits usage by core developers
• Racket LLM generated code in source tree
• SBCL LLM generated code in source tree
• Carp LLM generated code in source tree

• Scheme 48 open issue
• Chez Scheme at least one maintainer is against, another skeptical, open issue
• Guile Scheme likely against but nothing officially stated, open issue
• MIT Scheme open issue
• ABCL open issue
• LFE open issue

#tech #software #Lisp #LispLang #SchemeLang #SchemeLang #GuileScheme #AI #LLM #LLMs #VibeCoding #AntiAI

(Reposting a blog post by @zyd copy-pasted in full from: this webpage)

As of 2026-05-18 … sort of.

Every Lisp, Scheme, and Lisp-adjacent project listed is a non-toy implementation that is at least somewhat active. When I first wrote this article (2026-03-12), most Lisps did not have a policy or even public stance on LLM contributions. In such cases I posted to their bug trackers or discussion lists to ask. Most maintainers kindly responded.

Every link is either a document or issue stating the project’s LLM policy, or a link to an open issue. Roughly categorized according to how strongly for or against LLM contributions.

If I’m missing a project that should be listed, lemme know.

• Fennel
• STklos Scheme
• Clojure
• ECL

• Loko Scheme

• Janet exception given for tests and bug reproductions
• GNU CLISP against on a specific reading of copyright law
• Emacs Lisp temporarily against LLMs, waiting for official policy
• Hy maintainer recommends against LLM contributions, no actual policy

• Chicken Scheme
• Chibi Scheme
• Cyclone Scheme
• Gambit
• Gauche
• Gerbil Scheme LLM generated code potentially in source tree
• Clasp
• CCL

• Bigloo
• Coalton
• Kawa Scheme
• Sagittarius Scheme
• Jank doesn’t accept external LLM contributions but permits usage by core developers
• Racket LLM generated code in source tree
• SBCL LLM generated code in source tree
• Carp LLM generated code in source tree

• Scheme 48 open issue
• Chez Scheme at least one maintainer is against, another skeptical, open issue
• Guile Scheme likely against but nothing officially stated, open issue
• MIT Scheme open issue
• ABCL open issue
• LFE open issue

#tech #software #Lisp #LispLang #SchemeLang #SchemeLang #GuileScheme #AI #LLM #LLMs #VibeCoding #AntiAI

(Reposting a blog post by @zyd copy-pasted in full from: this webpage)

As of 2026-05-18 … sort of.

Every Lisp, Scheme, and Lisp-adjacent project listed is a non-toy implementation that is at least somewhat active. When I first wrote this article (2026-03-12), most Lisps did not have a policy or even public stance on LLM contributions. In such cases I posted to their bug trackers or discussion lists to ask. Most maintainers kindly responded.

Every link is either a document or issue stating the project’s LLM policy, or a link to an open issue. Roughly categorized according to how strongly for or against LLM contributions.

If I’m missing a project that should be listed, lemme know.

• Fennel
• STklos Scheme
• Clojure
• ECL

• Loko Scheme

• Janet exception given for tests and bug reproductions
• GNU CLISP against on a specific reading of copyright law
• Emacs Lisp temporarily against LLMs, waiting for official policy
• Hy maintainer recommends against LLM contributions, no actual policy

• Chicken Scheme
• Chibi Scheme
• Cyclone Scheme
• Gambit
• Gauche
• Gerbil Scheme LLM generated code potentially in source tree
• Clasp
• CCL

• Bigloo
• Coalton
• Kawa Scheme
• Sagittarius Scheme
• Jank doesn’t accept external LLM contributions but permits usage by core developers
• Racket LLM generated code in source tree
• SBCL LLM generated code in source tree
• Carp LLM generated code in source tree

• Scheme 48 open issue
• Chez Scheme at least one maintainer is against, another skeptical, open issue
• Guile Scheme likely against but nothing officially stated, open issue
• MIT Scheme open issue
• ABCL open issue
• LFE open issue

#tech #software #Lisp #LispLang #SchemeLang #SchemeLang #GuileScheme #AI #LLM #LLMs #VibeCoding #AntiAI

(Reposting a blog post by @zyd copy-pasted in full from: this webpage)

As of 2026-05-18 … sort of.

Every Lisp, Scheme, and Lisp-adjacent project listed is a non-toy implementation that is at least somewhat active. When I first wrote this article (2026-03-12), most Lisps did not have a policy or even public stance on LLM contributions. In such cases I posted to their bug trackers or discussion lists to ask. Most maintainers kindly responded.

Every link is either a document or issue stating the project’s LLM policy, or a link to an open issue. Roughly categorized according to how strongly for or against LLM contributions.

If I’m missing a project that should be listed, lemme know.

• Fennel
• STklos Scheme
• Clojure
• ECL

• Loko Scheme

• Janet exception given for tests and bug reproductions
• GNU CLISP against on a specific reading of copyright law
• Emacs Lisp temporarily against LLMs, waiting for official policy
• Hy maintainer recommends against LLM contributions, no actual policy

• Chicken Scheme
• Chibi Scheme
• Cyclone Scheme
• Gambit
• Gauche
• Gerbil Scheme LLM generated code potentially in source tree
• Clasp
• CCL

• Bigloo
• Coalton
• Kawa Scheme
• Sagittarius Scheme
• Jank doesn’t accept external LLM contributions but permits usage by core developers
• Racket LLM generated code in source tree
• SBCL LLM generated code in source tree
• Carp LLM generated code in source tree

• Scheme 48 open issue
• Chez Scheme at least one maintainer is against, another skeptical, open issue
• Guile Scheme likely against but nothing officially stated, open issue
• MIT Scheme open issue
• ABCL open issue
• LFE open issue

#tech #software #Lisp #LispLang #SchemeLang #SchemeLang #GuileScheme #AI #LLM #LLMs #VibeCoding #AntiAI

In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

But I still think there could be things the Scheme community would want to glean from this snapshot of history.

I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf

[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf

[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdf

cc @sigue @ramin_hal9001 @screwlisp

#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

But I still think there could be things the Scheme community would want to glean from this snapshot of history.

I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf

[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf

[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdf

cc @sigue @ramin_hal9001 @screwlisp

#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

But I still think there could be things the Scheme community would want to glean from this snapshot of history.

I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf

[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf

[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdf

cc @sigue @ramin_hal9001 @screwlisp

#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

But I still think there could be things the Scheme community would want to glean from this snapshot of history.

I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf

[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf

[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdf

cc @sigue @ramin_hal9001 @screwlisp

#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

In going through some old papers, I ran across these very interesting documents from long ago that I can't seem to find public reference to. They seem to offer some important historical insight about the Dylan language. This is from back when Dylan was called Ralph as a working title. In those days, the still-being-designed Lisp-like language had not yet moved to an infix syntax, and it looked and acted more like Scheme with an object system similar in spirit to CLOS (the Common Lisp Object System).

My understanding is that there were some fairly deliberate choices made to NOT target the Lisp or Scheme community as users, which is part of why the move to infix. I think they wanted to appeal to a disaffected C++ crowd, but ultimately lost out to Java for that bid, and then having left the Lisp user base behind, ended up with a very small community as a result.

But I still think there could be things the Scheme community would want to glean from this snapshot of history.

I've included a scan of an email proposal I got from Dave Moon while he and I were at Symbolics, with his proposal for how to add conditions to the language. Note that Dylan did eventually go public and did have a condition system, so you could also just study that design directly. But what's useful here is to see how all that looked syntactically in a Scheme-like syntax. But, in that regard, I recommend starting by looking at the language itself.

[0] Ralph: A Dynamic Language with Efficient Application Delivery, by Andrew LM Shalit, July 25, 1991.
https://nhplace.com/kent/History/dylan/ralph-1991-07-25.pdf

[1] Ralph Conditions (part 1 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-1-of-2-1991-08-14.pdf

[2] Ralph Conditions (part 2 of 2)
https://nhplace.com/kent/History/dylan/ralph-moon-conditions-proposal-v1.1-part-2-of-2-1991-08-14.pdf

cc @sigue @ramin_hal9001 @screwlisp

#DylanLang #RalphLang #ComputerHistory #Harlequin #Lisp #CommonLisp #ConditionSystem #ConditionHandling #ErrorSystem #Scheme #SchemeLang #CLOS #AppleHistory #KentsHistoryProject

Just use a #ProgrammingLanguage that isn’t popular (e.g. #Haskell or some #Lisp dialect) to write your code, but publish human-readable intermediate form of that code in the public code repositories (e.g. the C programming language). Share the actual source code privately with trusted contributors in non-public branches, and require GPG signatures on actual contributions.

You could argue that not sharing source code is against the GPL, but the GPL does allow you to share the code as a hard copy printed on paper and sent over snail mail. Or you can just wait until the person asking is an actual human that you can trust not to use the source code for LLM training.

LLMs are unable to learn unpopular programming languages because they don’t have a sufficient corpus of training data to learn how to code it, so if your receive a contribution in C, thank the contributor but inform them that they will have to rewrite the contribution in your Lisp dialect before you can accept it.

#Scheme dialects like #Gambit , #Chicken , and #Bigloo would work well for this. So would a #CommonLisp implementation that translates to C such as #ECL . Although keep in mind that the idea is to use a less popular language, so you may have to further obscure these languages a little bit, but not in a way that would be difficult for humans. For example, using a macro system, you could use df instead of define, rename types of things like string? to utf8str?, use generic functions with mulitple dispatch so append will work on strings, lists, vectors, and bytevectors. Small tweaks like this might throw-off an LLM asked to write source code in Lisp.

#tech #software #LLMs #LLM #FOSS #FLOSS #OpenSource #SchemeLang #R7RS

Just use a #ProgrammingLanguage that isn’t popular (e.g. #Haskell or some #Lisp dialect) to write your code, but publish human-readable intermediate form of that code in the public code repositories (e.g. the C programming language). Share the actual source code privately with trusted contributors in non-public branches, and require GPG signatures on actual contributions.

You could argue that not sharing source code is against the GPL, but the GPL does allow you to share the code as a hard copy printed on paper and sent over snail mail. Or you can just wait until the person asking is an actual human that you can trust not to use the source code for LLM training.

LLMs are unable to learn unpopular programming languages because they don’t have a sufficient corpus of training data to learn how to code it, so if your receive a contribution in C, thank the contributor but inform them that they will have to rewrite the contribution in your Lisp dialect before you can accept it.

#Scheme dialects like #Gambit , #Chicken , and #Bigloo would work well for this. So would a #CommonLisp implementation that translates to C such as #ECL . Although keep in mind that the idea is to use a less popular language, so you may have to further obscure these languages a little bit, but not in a way that would be difficult for humans. For example, using a macro system, you could use df instead of define, rename types of things like string? to utf8str?, use generic functions with mulitple dispatch so append will work on strings, lists, vectors, and bytevectors. Small tweaks like this might throw-off an LLM asked to write source code in Lisp.

#tech #software #LLMs #LLM #FOSS #FLOSS #OpenSource #SchemeLang #R7RS

Just use a #ProgrammingLanguage that isn’t popular (e.g. #Haskell or some #Lisp dialect) to write your code, but publish human-readable intermediate form of that code in the public code repositories (e.g. the C programming language). Share the actual source code privately with trusted contributors in non-public branches, and require GPG signatures on actual contributions.

You could argue that not sharing source code is against the GPL, but the GPL does allow you to share the code as a hard copy printed on paper and sent over snail mail. Or you can just wait until the person asking is an actual human that you can trust not to use the source code for LLM training.

LLMs are unable to learn unpopular programming languages because they don’t have a sufficient corpus of training data to learn how to code it, so if your receive a contribution in C, thank the contributor but inform them that they will have to rewrite the contribution in your Lisp dialect before you can accept it.

#Scheme dialects like #Gambit , #Chicken , and #Bigloo would work well for this. So would a #CommonLisp implementation that translates to C such as #ECL . Although keep in mind that the idea is to use a less popular language, so you may have to further obscure these languages a little bit, but not in a way that would be difficult for humans. For example, using a macro system, you could use df instead of define, rename types of things like string? to utf8str?, use generic functions with mulitple dispatch so append will work on strings, lists, vectors, and bytevectors. Small tweaks like this might throw-off an LLM asked to write source code in Lisp.

#tech #software #LLMs #LLM #FOSS #FLOSS #OpenSource #SchemeLang #R7RS

Just use a #ProgrammingLanguage that isn’t popular (e.g. #Haskell or some #Lisp dialect) to write your code, but publish human-readable intermediate form of that code in the public code repositories (e.g. the C programming language). Share the actual source code privately with trusted contributors in non-public branches, and require GPG signatures on actual contributions.

You could argue that not sharing source code is against the GPL, but the GPL does allow you to share the code as a hard copy printed on paper and sent over snail mail. Or you can just wait until the person asking is an actual human that you can trust not to use the source code for LLM training.

LLMs are unable to learn unpopular programming languages because they don’t have a sufficient corpus of training data to learn how to code it, so if your receive a contribution in C, thank the contributor but inform them that they will have to rewrite the contribution in your Lisp dialect before you can accept it.

#Scheme dialects like #Gambit , #Chicken , and #Bigloo would work well for this. So would a #CommonLisp implementation that translates to C such as #ECL . Although keep in mind that the idea is to use a less popular language, so you may have to further obscure these languages a little bit, but not in a way that would be difficult for humans. For example, using a macro system, you could use df instead of define, rename types of things like string? to utf8str?, use generic functions with mulitple dispatch so append will work on strings, lists, vectors, and bytevectors. Small tweaks like this might throw-off an LLM asked to write source code in Lisp.

#tech #software #LLMs #LLM #FOSS #FLOSS #OpenSource #SchemeLang #R7RS

I was able to finish reading all of “The Genius of Lisp“ by @cdegroot and the whole book was as good as the free preview (chapter 8). I was able to speed-read through the detailed explanations of concepts I already knew, like tail recursion, garbage collection, the Y-combinator, Currying functions, and so on. But there were parts where I slowed down and read carefully, like the section on the Universal Turing Machine, and some of the details of the IBM-704 system architecture. Also the story of how the first Lisp implementation was created when one of McCarthy’s grad students implemented an M-Expression calculator, this was described in slightly more detail than what I recall McCarthy himself explaining in his 1960 paper — that or I had just forgotten those parts of the story.

The tone of this book reminds me a lot of popular physics books like Stephen Hawking’s “A Brief History of Time,” which was aimed more at general audiences than professionals. That said, there is a lot to enjoy about this book for professionals like myself as well. There are many good stories about the principals designers of Lisp throughout. The sections on the commercialization of Lisp for the first AI boom of the 1970s and it’s subsequent “AI winter,” were very interesting to read. And if you are a teacher, you might like how some of the concepts in the book are explained.

And I would definitely recommend this very strongly to 3rd-year high school students, or 1st and 2nd year college students, who are more genuinely curious about how computers work and want to know more than just how to make the next billion dollar app.

The next #LispyGopherClimate show with @screwlisp I look forward to talking about this book some more.

#tech #software #Lisp #ProgrammingLanguages #SchemeLang #Scheme #Clojure #Emacs #EmacsLisp #RetroComputing #LispyGopherClimateShow

I was able to finish reading all of “The Genius of Lisp“ by @cdegroot and the whole book was as good as the free preview (chapter 8). I was able to speed-read through the detailed explanations of concepts I already knew, like tail recursion, garbage collection, the Y-combinator, Currying functions, and so on. But there were parts where I slowed down and read carefully, like the section on the Universal Turing Machine, and some of the details of the IBM-704 system architecture. Also the story of how the first Lisp implementation was created when one of McCarthy’s grad students implemented an M-Expression calculator, this was described in slightly more detail than what I recall McCarthy himself explaining in his 1960 paper — that or I had just forgotten those parts of the story.

The tone of this book reminds me a lot of popular physics books like Stephen Hawking’s “A Brief History of Time,” which was aimed more at general audiences than professionals. That said, there is a lot to enjoy about this book for professionals like myself as well. There are many good stories about the principals designers of Lisp throughout. The sections on the commercialization of Lisp for the first AI boom of the 1970s and it’s subsequent “AI winter,” were very interesting to read. And if you are a teacher, you might like how some of the concepts in the book are explained.

And I would definitely recommend this very strongly to 3rd-year high school students, or 1st and 2nd year college students, who are more genuinely curious about how computers work and want to know more than just how to make the next billion dollar app.

The next #LispyGopherClimate show with @screwlisp I look forward to talking about this book some more.

#tech #software #Lisp #ProgrammingLanguages #SchemeLang #Scheme #Clojure #Emacs #EmacsLisp #RetroComputing #LispyGopherClimateShow