> I have spent years writing about and studying Lisp, including buying several books.
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 agree, even after only working through examples and small learning projects in "Common Lisp: A Gentle Introduction to Symbolic Computation" writing is quite easy. Maybe the secret is writing lisp instead of writing about and studying it. The same approach also works with every other programming language, as a bonus :)
> The key is "writing and maintaining" Lisp software.
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?
> If you can't start riding a bike without stabilisers or someone holding it, then you're never going to learn to ride well.
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
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.
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.
> 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.
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).
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ę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.
> 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.
Well, this is true. I am 56, and my last living grandmother died over 30 years ago.
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.
I don't think it came across clearly but I was teasing the commenter you were replying to (and not you) for making an absurd claim in a confusing, sexist, and ageist way. Although my own grandparents are also dead, I know quite a few grandmas, including my stepmom (who had a ~5 decade career as a software engineer) - that are brilliant mathematicians and/or coders - so I take exception to the idea of using the word grandma as a stand-in for an ignorant person. Also, every person educated through public school in a wealthy country that isn't mentally disabled knows actual algebra and has studied it for 6+ years, not just the "rule of 3" whatever that is.
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.
Dunno. The only programming rule of 3 I know is that, in a C++ class, you provide a destructor, a copy constructor, and an assignment operator. But that doesn't fit either, because it's not really algebra, and every grandma certainly does not know it, and it doesn't fit in a Lisp article anyway.
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.