At least Hofstadter was successful at getting me interested in math beyond high school.
For some of us, we can just about handle the simple algebraic infix stuff, and we'll never make that leap to "my god, it's full of CARs".
This is categorically not the case.
Let me paraphrase my own post from Lobsters a year or two back:
I hypothesise that, genuinely, a large fraction of humanity simply lacks the mental flexibility to adapt to prefix or postfix notation.
Algebraic notation is, among ordinary people, almost a metonym for “complicated and hard to understand”. I suspect that most numerate people could not explain BODMAS precedence and don’t understand what subexpressions in brackets mean.
I have personally taught people to program who did not and could not understand the conceptual relationship between a fraction and a percentage. This abstraction was too hard for them.
Ordinary line-numbered BASIC is, I suspect, somewhere around the upper bound of cognitive complexity for billions of humans.
One reason for the success of languages with C syntax is that it’s the tersest form of algebraic notation that many people smart enough to program at all can handle.
Reorder the operators and you’ve just blown the minds of the majority of your target audience. Game over.
I admire Lisp hugely, but I am not a Lisp proponent.
I find it fascinating and the claims about it intrigue me, but to me, personally, I find it almost totally unreadable.
Those people I am talking about? I say this became I am one.
I myself am very firmly in the camp of those for whom simple algebraic infix notation is all I can follow. Personally, my favourite programming language is still BASIC.
The key is "writing and maintaining" Lisp software.
Lisp often won't get learned by reading or writing ABOUT it, but by reading AND writing actual Lisp code.
It's a bit like riding a bike. You can study bikes for a long time, but you will typically not be able to ride a bike. That's something which can be learned when actually practicing to ride the bike. This means also not needing to consciously think about it, but by moving tasks to internal automatisms. Lisp code is data and this wants to be "manipulated". This manipulation is a key to learn Lisp. The other key element is to work with a system which gives live feedback -> interactive programming. "Interactive" means to do things, to fail, to improve, to do it again.
It's in part the experience of actually using an interactive programming system.
I think programming languages are also long overdue for some controlled trials. They can't be blinded: any experimental subject bright enough to learn to program is probably going to know what language they are programming in.
But trials comparing the effectiveness of different languages. How long they take to attain a specified level of proficiency, how long to learn enough to produce working code, and importantly, readability: for instance, how long it takes to find intentionally-planted bugs in existing, unfamiliar code.
NeXT did this, way back in the 1980s, and Sun lost badly:
https://www.youtube.com/watch?v=UGhfB-NICzg
There is a writeup of some of it here:
http://www.kevra.org/TheBestOfNext/BooksArticlesWhitePapers/...
But speaking as a non-video-liker, this 17min one is worth it.
You may be right there, but I think there is a point you are smoothing over and almost trying to hide here.
What if someone can't get to the point where they are able to write useful code?
If you can't start riding a bike without stabilisers or someone holding it, then you're never going to learn to ride well.
At around age 11 or 12 I tried to learn to roller-skate. My parents bought me skates, and I put them on and tried to stand up.
I fell over so much over a few days that I bruised my pelvis and walking became very painful, let alone lying down. It was horrible and I gave up.
25 years later I managed to learn to ride a snowboard, after years of failure, because of having to do an emergency turn to avoid hitting some children and getting up on one edge and learning that edge-riding is the key. Nobody told me, including 3 paid days of lessons with a professional teacher.
It took great persistence and physical pain but I did it. I gave up on skating of any kind.
My core point is that people vary widely in abilities. Some people pick up a complex motor skill in 10-15min and can do it and their skills grow from there. Others may struggle for days or weeks to attain that... And most are not doggedly determined enough to try for that long.
Algebra is most schoolchildren's way of describing "something extremely hard to learn and pointless in everyday life." For ordinary humans, the concepts of "variables" and "symbols" that manipulate them IS A WAY TO TALK ABOUT something super-difficult.
But most of it, with effort, can just about get through. Very very few choose to follow it further.
And yet, there are a few families of programming languages -- Lisp, Forth, Postscript, HP calculator RPN -- whose basic guiding assumption is "you will easily master this basic action, so let's throw it away and move on to the logic underneath".
And the people who like this family of languages are annoyed and offended that other languages that do not require this are hundreds of times more popular and are used by millions of people.
Worse still, when someone comes and says "hey, maybe we can simplify that bit for ordinary folks", they mock and deride the efforts.
Maybe just allow yourself to think: perhaps this stuff that's easy for me is hard for others, and I should not blame them for them finding it hard?
a/b = c/d, we know a, b and c, solve for d, which is cb / a.
In German: "es ist noch nie ein Meister vom Himmel gefallen". We all start somewhere, we go to school, we have teachers, we have trainers/coaches, we have mentors, ...
I don't think studying it alone will help, best is with people around. Parents and friends will help us to learn how to ride a bike. They will give an example, they will give feedback on our attempts, they will propose what and how to try to master it. After the initial basic hurdle is done, then comes a lot of practice. But again, best by being embedded in a community. Learning such skills is a social activity.
There is a lot of pedagogical material to learn programming with Lisp, Logo, Scheme. I had courses about software development, using languages like PASCAL, LISP, Scheme and others. We got exercises and feedback. We got access to computers, cpu time and an environment for coding. I looked around and setup my own tools and wrote stuff with it. I discussed this stuff (code, environment, architecture, styles, ...) with a friend.
> perhaps this stuff that's easy for me is hard for others, and I should not blame them for them finding it hard?
Lot's of people are frightened by thinking/hearing that it is hard, while in fact it actually isn't.
For example one of reads that German is very difficult for native English speakers. There are a lot of justifications given for that. The actual data says something different. German is very near to English, English even is a Germanic language: https://en.wikipedia.org/wiki/Germanic_languages
The actual ranking: https://effectivelanguagelearning.com/language-guide/languag...
Trying to learn Lisp without actually trying to write code, sounds like trying to learn a language without actually trying to speak with people. Possible, but unnecessary hard.
We need to make our brain adapt to the new language by moving into an environment, where the words connect to the real world and thus to meaning.
Maybe just allow yourself to think: Giving feedback is not "blaming". That's an early concept needed for moving forward.
I became a father 5 years ago, so strictly, my mother is a grandmother. I could ask her, but I am very confident she does not know.
I have a science degree, and I just barely scraped through a statistics 101 course with great difficulty. I am pretty smart; I speak 6 foreign languages, and I have held down a career in software for approaching 40 years now, by understanding hard stuff and making it work, or documenting it, or explaining it.
But I find algebra hard, just scraped through a mathematics 'O' level in 1986 by taking corrective classes and resitting the 1985 exam that I failed.
I stand by what I said.
I've never heard this rule. Looking at the Wolfram explanation, I could do that, yes. But I've never heard of this, and I am pretty confident my mother could not do this.
Let me try to demonstrate with a parallel example.
> "es ist noch nie ein Meister vom Himmel gefallen"
My best guess is: A master does not ready from heaven fall?
One does not instantly become a master?
Different people find different skills easy.
So: ich kann ein bisschen Deutsch spreche. Nicht so viel, und mein Deutsch is nicht gut; es is sehr, sehr schlecht. Aber fur meine Ferien es genug ist.
Ich hat drei Tage Deutsch gestudiert, unt es war in 1989. Drei tage, am ein bus vom Insel Man nach der Rhein.
I am fairly good with languages. I can communicate in 6 foreign languages. Currently, I am studying Czech, because my wife is Czech, and I would like to be able to speak with her family, some of whom speak no English, or German, French, Spanish or anything else I speak at all.
Czech is really hard. It makes German look like an easy beginner's language. In place of German's 4 cases, Czech has 7; in place of German's 3 genders, Czech has 4. (Czechs think there are 3, but really there are 4. Polish has 5.)
I am somewhere past A2 level Czech, beginning B1, and I can hold a simple conversation, mainly in the present tense. But I started at age 45 and it took me about 5 or 6 years of work to get to this level. Basic tourist German I got in about 30 or 40 hours of hard work when I was 20 years old.
I am not bad at languages.
I am terrible at mathematics and very poor at programming. I used to be capable and proficient in BASIC and fairly good in FORTRAN. I managed a simple RLE monochrome image compression and decompression program in C, and an implementation of Conway's Game of Life in Pascal, and that is the height of my achievement.
I am pretty good at getting other people's code working, though. Enough to be paid to do it for decades.
I find Python quite hard -- weird complicated stuff like objects comes in early, and nasty C syntax peeks through even simple stuff like printing numbers.
Lisp, though, switches from just about comprehensible code to line noise very quickly after the level of "Hello world".
I got hold of a copy of SICP. It's famous. It's meant to be really good.
I could not follow page 1 of the actual tutorial.
Perhaps you know it.
In section 1.1.1, it says:
« (+ (* 3 (+ (* 2 4) (+ 3 5))) (+ (- 10 7) 6))
which the interpreter would readily evaluate to be 57. We can help ourselves by writing such an expression in the form
(+ (* 3 (+ (* 2 4) (+ 3 5))) (+ (- 10 7) 6))
following a formatting convention known as pretty-printing, in which each long combination is written so that the operands are aligned vertically. The resulting indentations display clearly the structure of the expression.6 »
The "helpful" pretty-printed part is incomprehensible to me. Section 1.1.1 is about where I gave up.
I think that this kind of issue is not just me.
Again: I submit that a bunch of people good at a very difficult skill are badly over estimating how good ordinary folks would be at it.
Most people can't program. Most people can't do mathematics. Most people are not good at this stuff.
The people that can do maths and can program mostly can only program in simple, infix-notation, imperative languages. Functional languages, or even prefix- and postfix-notation, is a step further than I suspect that 99% of humans can go.
And the attitude of those who can do it to those of us who can't do it is really not pleasant.
No doubt about that.
SICP is the wrong book.
SICP is for people who are good at maths. Most of the examples are maths related. That's a well known complaint about the book. Often such maths-heavy introductory courses filter out the students who are not good at maths. On purpose.
SICP is not for beginners learning Lisp programming. SICP was an university introductory course book for computer science. It was developed out of maths-heavy CS lectures. Various other books tried to improve it both to make some of the topics easier to learn or to make it more advanced in programming language technology.
Easier SICP from Brian Harvey
https://www.youtube.com/watch?v=cuTOo_Kj4U0&list=PL91cR71aKp...
or him adopting this stuff to Logo: Computer Science Logo Style. https://people.eecs.berkeley.edu/~bh/
Or his book "Simply Scheme": https://people.eecs.berkeley.edu/~bh/ss-toc2.html
But what you are looking for is a book for a software developer wanting to learn practical Lisp programming with different examples.
However, I do want to say something about listing out your qualifications and experience like you did on here... in the petty power struggles and trolling on the internet it does the exact opposite of what it seems like it should. It's putting the other person in charge of deciding if you are "good enough" to participate or have an opinion, by implicitly making an effort to convince them and asking them to judge you. Your opinion and reasoning carry more weight on their own, without arguing why you should have the right to have them.
Outside of expressions, those languages are essentially prefix in that the operator comes before the list of arguments.
What I was trying to say was: "I am pretty smart, but I can't do this."
Which means: "different people are smart in different ways."
Which means: "what is no problem for Lisp coders can be a pretty big problem for other folks."
Polish has 3 genders (masculine, feminine and neuter), just like Czech. And 7 cases, like Czech.
In no particular order:
1. żeński
2. nijaki
3. męski męskożywotny
4. męski męskorzeczowy
5. męski męskoosobowy
Contrast with Czech:
1. žensky
2. středny
3. mužsky životny
4. mužsky neživotny
You may not notice them, you may not consider them to be genders, but they look like it, they act like it; they're there and they make life very difficult for foreign learners.
If it looks like a duck, walks and swims and quacks like a duck, it's a duck.
I lived in Czechia 10 years and after over half a decade of bloody hard work, I got to beginning B1 level Czech. It has 4 genders and they change adjectives and the accusative declination, and it is not important to me that Czechs don't consider them genders. They're genders. The levels of the hierarchy do not matter, merely the number of nodes.
A comparison: English has no future tense, strictly speaking. But in reality, really, it does: "I will say X". In fact arguably two: "I am going to say X." Technically to a linguist it's not a tense, it's a mode expressed with an auxiliary verb, but that doesn't matter. Acts like a tense. Used like a tense. It's a tense.
Slavic nouns come in arbitrary categories and you need to know which category it's in to conjugate it properly. French and Spanish have 2, German has 3, Czech has 4, Polish has 5. What they are called? Don't care. Not important to me.
I do not know Polish or speak Polish. I am 100% not claiming any authority here.
For one, "męski męskożywotny" is not what it is called, it is just męskożywotny (the gender is already in the word, male male-animate, has a weird ring to it).
But all that means is that the object is of a masculine gender, and is living.
Męskoosobowy (masculine, person) -- małego chłopca (small boy)
Męskozwierzęcy (masculine, animal) -- małego psa (small dog)
Męskorzeczowy (masculine, thing) -- mały dom (small house)
Żeński (feminine) -- małą górę (small hill)
Nijaki (neuter) -- małe zwierzę (small animal)
The three masculine examples are all of the same gender, masculine -- the difference is if they are a person, animal or thing. None of which are genders, a house and a dog are both masculine.
I'm not going to argue about the complexity of Slavic, specially West Slavic languages -- cause they are complicated. :-). But you are absolutely incorrect in saying that we (Czech or Polish) have more than 3 genders. That you don't think it is particularly important is a bit sad, since these are the things that make Slavic such a fun language group.
I doubt it. Firstly, there are entire prefix and postfix natural languages, which have capable native speakers of all intellectual persuations. But in natural languages, sentences do not go to very deep levels of nesting before people get confused.
In programming, we have the deep nesting quite often. Nobody has the mental flexibility to adapt to it. We indent the code instead.
Nobody can read a large Lisp program (or even a small one) if it is flattened into one long line, which is then wrapped to a paragraph.
Within a single line of Lisp, there is rarely much nesting going on where the prefix notation causes a problem. The rest is indentation.
Everyone doing serious programming relies on their editor for that, which helps them spot nesting errors.
Then I still won't believe it's a Lisp syntax problem, unless they have a background of success with other languages.
Some people don't have a knack for programming. Among them, some try this and that, and falter in various ways.
> And the people who like this family of languages are annoyed and offended that other languages that do not require this are hundreds of times more popular and are used by millions of people.
Those other languages are harder because of their syntax.
Languages that remove syntax are an affront to the self-image that people have built up over their mastery of convoluted syntax.
For most ordinary people, learning programming is equated with learning syntax. When they are memorizing things like that >> has a higher precedence than +, they feel they are getting smarter.
The idea that this stuff is not necessary, and that you actually don't know jack if you don't know semantics, is a huge threat.
Once a beginner is off into a syntax-heavy language, chances are high we have lost them forever, due to simple ego effects.
(+ (* 3
(+ (* 2 4)
(+ 3 5)))
(+ (- 10 7)
6))
I mean, how could they present this differently? Pretty much any Lisp book should explain this stuff the same way. Look, we have these parentheses and that's what the machine cares about, but we split across and indent like this.
If someone finds that reformatting to be incomprehensible and unreadable, virtually no different from the original one liner, they may have some cognitive issue (a form of dyslexia or something like it). Likely they will struggle with programming in any language.
I don't suspect it's "cognitively typical" not to find the visual structure of the above formatting to be obviously helpful.
Given the multi-line layout:
(+ (* 3
(+ (* 2 4)
(+ 3 5)))
(+ (- 10 7)
6))
It can't be that only a minority of people have it as a "special skill" to see a simple visual pattern with hierarchical grouping and alignment.
The semantics is future, but tense is a matter of syntax.
The modal verb which establishes future semantics it not in a future tense; it is in its dictionary form: to will.
In archaic English we can say things like "As I will it, so it shall be" where the verb isn't acting as a modal. The modal will comes from that one, I believe.
Let me see if I can recall an example. Okay, how about the word for horse, which is kôn, and man which is muž. This is masculine: ten kôn (that[masc] horse), ten muž (that[masc] man).
However, in the third person we have tý muži (those[masc] men) and tie koňe (those[fem? neut?] horses)?
The demonstrative tie is the same like the feminine one, tie ženy (those[fem] women) or neuter tie deti (those children).
Even if that is a special gender difference, it does not fall along the animate versus inanimate line, because horses are clearly animate.
Inanimate objects that are masculine in the singular do fall into this: ten stôl (that[m] table), tie stoly (those[f] tables).
It might be human versus non-human. Collections of non-human male gender things are not themselves males, but neuters.
It's similar to la and le in French. You cannot say "Vive le France"; it has t obe "la France".
They are used as helpers in communicating the gender of a noun. If we say "ten stôl", it reaffirms that the noun is masculine. "tá stôl" is ungrammatical.
Other words are like this. E.g. interrogative wh- words: "ktorý muž?" (which man?) "ktorá žena?" (which woman?)
> It can't be that only a minority of people have it
Only a minority of people have the ability to understand algebra.
Of them, only a minority can usefully use it and apply it.
Of them, only a minority can formulate an algorithm and construct code to perform it.
Of them, only a minority can tolerate having the helpful algebraic notation removed and replaced with a bare abstract syntax tree decorate with parentheses.
Why do you think most people only understand enough about Lisp to make jokes about all the parens?
Why do you think most people gravitate towards the simplest, shortest, infix-notation language and moved the entire industry on to that?
By coincidence?
Sure. And you are also aware that there are natural languages which are regarded as being very hard for non-native adults to learn, right?
Some natural human languages are easier than others. This is axiomatic.
Some programming languages are easier than others too. Excluding the ones that are designed to be, from INTERCAL to Ook!
Not everyone likes it, or ends up going into a field that requires math, but that's not the same thing as having no ability to understand it.
Why most people only understand enough about Lisp to make jokes about all the parens is like asking why some people only understand enough about Poland to tell jokes, like four Polaks turning a ladder so a fifth one can change a light bulb.
It's usually gratuitous syntax like noun cases, especially when the same feature is not present in any shape in one's native language.
Also writing systems that have large numbers of symbols, which have multiple interpretations.
In any case all mainstream programming languages have prefix notation in the form of function calls. And also statement constructs that begin with a command word followed by argument material.
Imperative sentences in English amount of prefix notation because the subject is omitted (it is implicitly "you") so we're left with verb and object.
You're focussing on the detail while ignoring the general picture.
I am not comparing Lisp to Mandarin Chinese or something. That would be silly.
What I am saying is that there are a whole bunch of languages (both kinds) which presumably seem perfectly easy to those who grew up with them, but if you didn't and you come to them after learning something else that's much simpler and doesn't do the fancy stuff, then they seem really hard. Consistently, for lots of people, regardless of background.
Doesn't matter how good your Arabic, Mandarin will be hard, and vice versa.
https://www.geeksforgeeks.org/hardest-languages-in-the-world...
That list isn't sorted by your source language, your L1. That doesn't matter.
If they come from an infix-notation imperative language then most people are going to find moving to an impurely-functional prefix-notation one is really hard. And most languages are infix-notation imperative languages.
(+ (* 3
(+ (* 2 4)
(+ 3 5)))
(+ (- 10 7)
6))
There are hardly any Lisp programmers today who didn't "come from" prefix languages.
All mainstream languages are heavily steeped in prefix notation. The infix stuff is just a small core, typically. Mainly it is for arithmetic. Sometimes for string manipulation or set operations on containers, perhaps I/O.
Libraries are invoked with f(a, ...) prefix or perhaps obj.f(a, ...) mixed infix and prefix.
Libraries have far more content larger than the infix material.
Even small programs are divided into functions, invoked with prefix. Prefix is relied on for major program organization.
Command languages use prefix: copy filea.txt this/dir.
Statement and definition structures in mainstream languages are prefix: class foo {, goto label, return 42, procedure foo(var x : integrer), ...
The idea that programmers coming to Lisp are confused by prefix does not hold water.
"harder" is relative to a reference. Even "hard" is relative.
The simple nested arithmetic code you stopped at in SICP is easy for most people working as developers. Maths from 5th year school are sufficient. Nested lists, prefix notation isn't "hard" for "most" people.
It's just lightly harder for someone who has never seen that. When they have seen XML or JSON, then it's even easier.
Actually "hard" Lisp code looks and feels different. First "harder" hurdles in Lisp are typically evaluation, recursion, macro expansion, compile-time vs. runtime, meta-notation (code as data), ...
I learned 2 years PASCAL and MODULA 2 on an Apple ][ (and i still think that was fun), before getting in contact with the Lisp alien world. I was hooked in a short time.
The usual mathematical notation is two-dimensional. Fractions are written a / b and
a
-
b
When I verbalize a * (b + c) as a natural language expression then it is:
Multiply a with the sum of b and c.
In German:
Multipliziere a mit der Summe aus b und c.
(* a (+ b c))
(* a
(+ b c))
(* a
(+ b
c))
(* a (+ b
c))
(*
a
(+
b
c))
A pretty printer in Lisp is a function, which takes an expression and writes it in some layout. Thus Lisp can generated 2d-layouts of expressions. Most Lisp-supporting editors can indent or even layout Lisp expressions. This helps Lisp developers using a common layout of code, supported by the tools.
This is a very Lispian sort of attitude. "No, you are wrong, this is in fact the correct way..."
There is an existence proof that the attitude of "just keep at it and it will make sense" is not true, and it's an international software industry of buggy, leaky, insecure C code that keeps hundreds of thousands of people in work and makes _tens of millions of dollars_ every year.
If the alternative really was better, someone would have found a way to make money from it, but they have not.
And yet, despite the terrible macho-man culture of the software industry, where it is a sign of how elite you are to write in a non-bounds-checked language with manual memory management and they make jokes about "blowing your own leg off" and "write-only code", Borland made hundreds of millions selling the same people Pascal for decades, and it's still on sale now.
https://www.embarcadero.com/products/delphi
My first full time job in FOSS was documenting Java tooling, for a Linux company that told me in my New Hire Orientation how much the company hated Java.
I have met and talked with some Java developers. They are scary. Some of them are the kids who couldn't get onto Computing courses but they are pro Java developers. They can just bodge it together and it works, safely.
IMHO the Lisp industry and community needs to listen to the people trying to make easier, clearer Lisps, such as CGOL and PLOT and Lunar and Dylan, and engage with them, and try to understand why and embrace it, not just continually telling them they are wrong wrong wrong.
Plain old algebraic notation works and non-specialists can, with effort, master it.
But even more than that: the most widely-used programming language in the world today is Microsoft Excel formulæ.
BTW: Recursion is trivial. I had recursive BBC BASIC V code working beautifully when I was 20.
Why post here, when you are not willing to accept feedback from other people? I get that you have trouble learning Lisp, but I have been hearing the same stuff for decades. Nothing what you tell is new. I had to deal with the same arguments 40 years ago and when you read old Lisp books from the mid 60s -> the same song. I've seen some people getting Lisp and others not. For me the question was always how to help people "to get it" - attitudes like your's, giving up early, is typically an early dead end. The mental block is the bigger problem than the actual thing to learn.
"Anyone could learn Lisp in one day, except that if they already knew Fortran, it would take three days.” — Marvin Minsky.
There is truth to that. People who already have an idea how things should work, need to let that go. Unlearn and start from a neutral position.
> international software industry of buggy, leaky, insecure C code that keeps hundreds of thousands of people in work and makes _tens of millions of dollars_ every year.
Yeah, and I have a lot of respect for that. I use software written in C everyday. It does useful stuff, independent how many problems it has.
> Some of them are the kids who couldn't get onto Computing courses but they are pro Java developers.
I work in a company, which has several hundred people developing in Java. In fact the part of the company I work with is responsible for backend work, which connects several million cars. I've met extremely bright people, doing hard work. I'm not going to try selling them Lisp.
> IMHO the Lisp industry and community needs to listen to the people trying to make easier
IMHO "the Lisp industry" does not exist as an entity and has neither the resources nor the interest to do what. Nobody is interested in CGOL, PLOT or Dylan. These were dead end. Nice experiments. I like experiments.
Lisp people worked on Dylan, when the Lisp jobs went away. Dylan went nowhere. As some former Lisp people working on Dylan, some are still thinking its a good idea and others have given up on it. Harlequin had several language offerings: Postscript RIPs, Lisp, ML, Dylan, Memory management. LispWorks survived, when Harlequin went bankrupt, because it had customers with software. Dylan did not survive. It was eventually open sourced and still has not much going on.
The non-existent "Lisp industry" would alienate its core customers. People who want a different tool.
You THINK that there it would be a way, but we have heard for decades these same ideas. The problem is not people who can give advice (I've seen lots of talks & papers about this topic) - the problem is that these people have nothing to offer, they are themselves not involved. Nobody will listen to you, because people in the IT industry get all kinds of advice, but "needs to listen" does not pay the bills.
Clojure exists, because people developed it, had a market niche and it survived. In the same original niches (enterprise consulting for web technology, ...) were and still are a zillion other offerings. Every year new and old ideas come and go.
> Recursion is trivial
Then SICP should be trivial for you, because its content is based on Scheme with lots of recursion.
> IMHO the Lisp industry and community needs to listen to the people trying to make easier, clearer Lisps, such as CGOL and PLOT and Lunar and Dylan, and engage with them, and try to understand why and embrace it, not just continually telling them they are wrong wrong wrong.
You misinterpret the Lisp community. "People are not wrong". It's just that the people in the various Lisp communities focus on their own stuff and that's their right.
I have my garden at home, I'm not responsible to sell stuff to all kinds of other garden owners. That's not my business. I'm happy with my garden.
Actually, languages like Python, Java, JavaScript, Ruby, Exlixir, OCAML, F#, Wolfram language and many others, ... they have already taken most of the Lisp features (typical argument we hear: why use Lisp, when other languages already have its most important features?).
You may not aware of it, but languages with lots of features from Lisp are in wide use already.