At my university, scheme is taught in more than a handful of classes, including the introduction to computer science class. It had, overall, very mixed reviews. Beyond the validity of the teacher, kids had two major complaints at first: “Why would we learn scheme when we could be designing apps?” and “(((() ((() () (((())))))))) is so hard to read.”
By the end of the semester, when most people had learned how to write decently clean code, with good indentation, most kids stopped complaining about the latter, but a ton of people still complained about the former. Maybe it’s just because they were actually forced to sit down for an entire semester and type more parenthesis than they ever have before, and they got used to it. Or maybe some of them began treating the code like a tree structure, as in this article. Either way, personally, Lisps have always been very readable for me, and I thought this article described why perfectly.
Did you find the lisp more readable than the python examples? E.g. in the example of:
vec = [10, 20]
vec = 7
vec += 2
(setq vec (vector 10 20))
(setf (elt vec 0) 7)
(cl-incf (elt vec 1) 2)
It seems to me that, while the lisp may not be bad, it’s noticeably less readable: extra noisy brackets at the start/end of the lines, method names that are neither English words nor standard symbols and require domain knowledge to understand, the cumbersome (elt vec x) that blends into the rest of the line. But I suppose that could be an artifact of knowing Python.
I wouldn’t say it’s more or less readable, but I certainly don’t struggle with it either.
I do think that example is perfect at showing where lisp can be difficult to read, especially when you’re quickly skimming. On one hand, it is very easy to miss the elt parts in the middle of lines, but on the other hand
(vector 10 20))
(setf (elt vec 0)
(cl-incf (elt vec 1)
is a little obnoxious in vertical space consumption.
EDIT: hit tab and then space and accidentally submitted. Formatting was bad too.
First: I completely agree about readability. The parentheses are a short-term annoyance when learning, but quickly become second nature.
Second: some students (in anything, not just computing) are frustratingly opposed to learning fundamentals. When learning a new instrument, any teacher worth their salt will make you learn the notes, the scales, how to read music, etc. And many new students (particularly young ones) are likely to find this frustrating. “Why can’t I just play X?” they’ll ask. And some of them will drop the lessons and learn to play on their own, getting the sheet music or tab off the internet and copying the styles and songs of their favorite artists. Some of them will even get pretty good at it, maybe make their own songs, maybe even hit it big. And then they’ll go into interviews and talk about how they did it without real training, and it’ll teach a whole bunch of kids learning it that maybe they don’t need training either. So they’ll give it up.
What they’ll miss is that the people who made it big still likely had to work at it. They’re looking for a shortcut. They know “I want to play Van Halen” or “I want to make an app,” and they don’t care about all the other stuff. They want to do that one thing. And the same attitude that told them they don’t need lessons will leave them frustrated when the songs they’re learning are too hard. The shortcut doesn’t work because they won’t.
In the end, when they’re complaining about learning Lisp, they’re complaining about doing something new and hard that they weren’t expecting. It doesn’t seem to fit the plan of what they wanted, and it’s so foreign, so weird. And they reject it.
Edsger Dijkstra, in “On the Cruelty of Really Teaching Computer Science” (EWD 1036), discusses at length the nature of these “radical novelties” and the ways in which people respond to them. That is all that’s happening here, and it’s not surprising. The only mistake made in these situations is giving in and switching to something “practical” which placates the students because it fits their conceptions and isn’t challenging. It is sad to me that so many universities do so (even UT Austin, where Dijkstra has worked, which switched to Java from Haskell as their introductory language after Dijkstra’s death). This is a capitulation to the whims of the crowd, forgoing the fundamentals of logic that underlie all computing and jumping instead to the mechanical and “pragmatic” to the detriment of all.
I agree one hundred percent, and I love the transcript, thank you.
I think you’re completely right, and I think that’s why things like tablature (for the most part) exist: the average 16 year old boy trying to woe a classmate with a guitar won’t be bothered to learn musical theory (chords, progressions, etc), and instead will just get the tablature from the internet because it’s easy. They don’t care about how chords come together to work, he just wants to hear the song, a final product.
I think this attitude is extremely prevalent in computer science education today, especially for the kids in my introduction to programming class. I would be working in the lab, and I would see 5-6 kids at any one time just searching for possible answers on StackOverflow. They didn’t care about the process of learning scheme, they cared about the results and their grade. But without the process, their results will (probably) be bad. Same thing goes with apps. There are so many iOS questions on StackOverflow and so many tutorials that someone could reasonably design and build an app without understanding anything they type into Xcode. It’s just kind of disappointing.
That’s definitely the downside of the wide availability of code examples, app tutorials, and the like. On the one hand, when read carefully they provide very useful direction. On the other, a person can simply skim through, grab the code, and miss the far more important text around it.
For the Web Programming course I help lead (I am the Teaching Assistant, and helped write the lesson plans and online textbook) the professor and I work very hard to make students read instead of just grabbing any available code. We’ve found that requiring reading write-ups and making assignments more specific (make a site that does X using Y, rather than make a site that uses Y) has helped curtail some of the skimming. It’s not perfect, but it’s something.
I agree that on a university level, that attitude of just searching for the fix without understanding the problem is harmful. But at a high-school or middle-school level, I think there’s definitely validity to the model of just getting something working even if the final product isn’t great. As software developers, I look at a pile of crap code and think about the maintenance overhead, how unreadable it will be to someone in the future, and how difficult it is to make simple modifications. But for a kid who’s just putting something together for fun, the code is disposable and the output is the point.
This is the coding equivalent of the kid who knows just enough chords to have fun when he brings his guitar along to the beach; just because he’s never going to become an expert doesn’t mean he’s wasting his time.