> Most people can't program. Most people can't do mathematics. Most people are not good at this stuff.

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.

Although the SICP is an awful book, the thing in section 1.1.1 that OP refers to where it presents formatting an expression:

  (+ (* 3
        (+ (* 2 4)
           (+ 3 5)))
     (+ (- 10 7)
        6))

is a decent point.

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.

I disagree.

I was fine with Pascal, Fortran, minimally competent in C, and happy in half a dozen dialects of BASIC, which remains my preferred language.

I don't know, man. If a big truck is hurtling towards me, I'd prefer that the person behind the wheel not have the cognitive impairment that prevents them from being able to grok the visual structure of:

  (+ (* 3
        (+ (* 2 4)
           (+ 3 5)))
     (+ (- 10 7)
        6))

It's just very basic recognition of shapes suggested by incomplete contours.

Pascal, Fortran, C, ... All these languages use prefix notation for function calls.

Fortran:

    min(size(b), size(a))

Lisp:

    (min (size b) (size a))

I suspect you might have some dyslexia-like cognitive or visual issue that makes it hard to work with programming language syntax.

Given the multi-line layout:

  (+ (* 3
        (+ (* 2 4)
           (+ 3 5)))
     (+ (- 10 7)
        6))

I strongly suspect most ordinary people with neurotypical visual pipelines would find it helpful and more comprehensible over the same expression formatted as one line, regardless of their aptitude for math, or the semantics of programming.

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.

I would say that it is a bang-on certainty that...

> 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?

Algebra is taught in public schools. The majority of children are able to get through the classes: do the homework and pass the tests. Not sure where you're getting your statistics.

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.

Basically no programming language is an infix-only-notation language. Most programming languages are using mixed notation: prefix, infix and possibly postfix. In most languages function calls are prefix. For a subset of functions there are infix operators: a + b, instead of +(a,b). For control flow many programming languages use a more elaborate syntax.

The usual mathematical notation is two-dimensional. Fractions are written a / b and

    a
    -
    b

Also think of square roots and all kinds of other mathematical notation.

When I verbalize a * (b + c) as a natural language expression then it is:

    Multiply a with the sum of b and c.

The operators are prefix.

In German:

    Multipliziere a mit der Summe aus b und c.

in Lisp:

    (* a (+ b c)) 

or

    (* a
       (+ b c))

or

    (* a
       (+ b
          c))

or

    (* a (+ b
            c))

or

         (*

            a

    (+ 

             b
        c)) 

The latter, more random layout, will not be used by Lisp programmers, because it does not follow the usual layout rules. But it is possible, since the layout of the lists is not significant in Lisp.

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.

> 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.)

Polish has 3 genders (masculine, feminine and neuter), just like Czech. And 7 cases, like Czech.

Nope.

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.

Personal (męskoosobowy), animate (męskożywotny), and inanimate (męskorzeczowy) are not genders. Which is the same situation with Czech (životny - animate, etc).

I’m Polish. And did study Polish on top of that.

Let me elaborate slightly.

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'm Slovak here. Although there are three genders, there are certain situations in which certain kinds of nouns undergo changes according to a finer subdivision than the 3 genders. I'm no expert on that. I don't think it necessarily amounts to separate genders. Or does it?

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.

I find it strange that you are labelling ten/tie/.. as with gender. I don't know Slovak, but I'd expect it is the same as in Polish that the gender is on the subject. E.g., stôl is stół in Polish, and "męskorzeczowy", so masculine. "Ten stół" or "te stóły" -- te or ten is neither feminine nor masculine.

These demonstrative particles themselves don't have gender since they are not nouns, but they have a gender-based variety, and must pair correctly with the nouns by gender.

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?)

"I will ..." is a nonpast tense, though.

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.