I wonder if any teacher already tried to teach LISP as a first language instead of java or C, and what there was to learn about it.
IMO nobody [3] considered it programming. I was a geek and thought it was pure vapor [4], programming needed to be cpp with graphics or GUI or memory cells. I don't know what other people thought about it but I'd bet they forgot about it the minute they left the class. I mean pairs and cons cells ? what can you do with that ? ... beside map/fold/compose/curry. But that would need to talk about closures... can 20yo handle hot thangs like these ?
----
[1] in my days, first 2 years were 80% math/phys 20% programming
[2] casual introductory modules, at that point students don't know if they go pure science CS or IT.
[3] except the wearing IOCCC tshirts teacher
[4] infinite idiocy of my young self
Student's inability to understand this is their own failure and ignorance.
As to the topic at hand, in JS, those ideas of higher-order functions which don't exist in C (to any meaningful extent) are the primary means of abstraction. I've seen very many C++ or Java programmers think they can handle JS just fine. It's never too long before those functional concepts they considered useless (or even worse, were never taught) begin to haunt them.
[1] growing with computer as a user, what amaze you is what you can perceive : gui, games, external devices. Which are all designed to amaze. When you get to know how computers are made, your first desire is to reproduce these things. Abstraction, expressiveness aren't on your map yet.
Not only that, there are multiple levels of abstraction to fully grasp everything.
For some people thinking in the abstract way of computing is already too much.
Then those think they have mastered the basic concepts of computer abstractions like loops, decisions, data structures, there is the next level of meta-abstractions.
Meta-abstractions used to manipulate the said abstractions to fully mold the whole computer system like clay. The same way mathematical abstractions reason about the common man mathematics.
Very few are able to move between abstraction levels, and those that do forget how it was their view of the world before they fully grasped it.
I believe that first the algol genealogy suffers from the ~difficulty of crossing metalevels, secondly, the people behind these languages were able to do so and see the language as a vehicle, a mean, not an end. But beginners see the finger, not the moon and end up thinking in terms of builtin constructs. Lisp being already unrelated to any machine, and with the serendipity of sexp easy homoiconicity you see swim in this universe of abstraction levels.
> Very few are able to move between abstraction levels, and those that do forget how it was their view of the world before they fully grasped it.
I enrolled Coursera MOOC teaching scheme and sml, watching many students being emotional (anger, despair) about interpretation (especially when circular) reminded me of myself in college. The worst part is that the best I could say was "keep trying, you will understand". I wanted to tell them about the beauty and the freedom you feel but our minds were too separate and my understanding not good enough yet.
And nowadays they cannot runaway as functional programming concepts begin to infect their languages as well.
They are left with:
- stay in the past, hoping to retire before being forced into newer versions of their languages
- learn and embrace FP and get to discover how OOP and FP can work together
- try to jump to other languages that are still friendly to old school developers
The PLT Group's homepage: http://www.ccs.neu.edu/racket/
[1]: http://racket-lang.org/ [2]: http://htdp.org/
It's not that programming now "largely consists of debugging and customizing already existing code, often via frameworks". For one thing, it's only the narrow, web-constrained definition of "framework" that even vaguely works that way. Second, I'd argue that, unless the code which programmers debug has been written somewhere until the late 1990s, new code gets written often enough that programming largely consists of writing new code instead of debugging old one. That there are programmers hopelessly churning on the umpteenth bug because someone at the end of the Internet decided to change the format of their JSON objects and the mapping of their HTTP request handlers (pretentiously calling that "an API") is not a testament to how programming has evolved, it's merely a proof that not every change counts as evolution.
Instead, the choice of Python over Scheme -- which has been received with mixed feelings by almost every programmer able to write a Quicksort function without googling for compiler errors -- seems to have been driven by related, but vastly different reasons, such as:
* There are vast amounts of interactions spread over multiple languages, machines and platforms. Independently reasoning about objects, while essential to programming, is as central to teaching as integration in already existing architectures is. Unlike the early 1980s, when pretty much every new computer meant a new editor, a new set of programs and more often than not, a couple of new languages, being able to reason about existing architectures is incredibly important. Scheme is able to provide this, but requires fairly intimate knowledge of the implementation, whereas Python pretty much gives this away for free.
* A considerable deal of modern CS/CompEng research is centered around studying non-fundamental applications. It's important to have access to tools that allow people to whip up quick experiments. Whether Python does this better than Scheme is debatable, but Python does arguably score better in terms of integration and, therefore, in terms of being able to glue new fundamental discoveries to practical problems that they solve. Perl does that too, arguably better than Python, actually, but there are lines even seasoned teachers would rather not cross.
* Many of the so-called real problems come from more specific fields, are sloppier and can often be less rigorously stated than those for which SICP was initially written. Again, this is debatable, but Python is more universal and easier to convey. I don't know how much truth is behind this. I tend to disagree, because personal experience has shown me that this is the argument preferred by the kind of people who think that cool 3D data visualisation programs are a good example of a real-life problem and rotation matrices are a typical example of a useless problem that doesn't stem from real life applications.
This is why web development is so dull to me. You're always coloring by number.
A few years ago, MIT restructured their entire CS curriculum (not just the intro class) in a way that required redesigning the individual curricula of each of the classes, including the intro class. As a result, they couldn't use SICP, since it didn't cover the same topics. At this time, they ended up switching to using Python for the class.
This is sometimes presented by people who dislike functional programming as an indictment of Scheme/Lisp, though this is very misleading. Nobody made the decision to "abandon" SICP - "they" made the decision to redesign the entire curriculum (top to bottom), which meant writing new syllabi/textbooks for all/most of their classes, especially the intro class, and then "they" made the decision to write the new syllabus/book for that new intro class in Python[0].
Some schools (University of Minnesota is one) still use SICP.
Personally, I think that SICP is the best way to be introduced to both the fundamentals of computer science and programming. The only caveat is that it requires a certain level of dedication before-the-fact (something that could be reasonably assumed in an MIT intro class). So it's not the best choice for someone who "just wants to dabble" in programming and see if they like it (try Python or Ruby for that), or for someone who wants to understand computer architecture and engineering (try C for that), but for everyone else, it's unparalleled.
The nice thing about SICP is that it focuses very little on learning the nitty-gritties of Scheme (partly because there's so little to learn!), whereas most other introductory materials I've seen have to focus on Java-specific, Python-specfic, etc. features. Reading SICP feels more like reading a math textbook that "just happens" to come with a REPL for mathematical expressions, as opposed to learning the ins and outs of a given programming language or environment.
[0] Of course, "they" refers to many different people, very few of whom would be in the same "they" as it was in the 1980s when SICP was first written, so one has to keep that in mind before concluding that MIT "changed their mind".
MIT's EECS undergraduate enrollment cratered after the "dot.com" crash, more than halved, after being 40% of the student body for decades.
The department panicked.
And it was most certainly ordered that Scheme be entirely purged from the base curriculum, even while they claimed they were teaching SICP concepts and functional programming in 6.005, they were using Java, a language that's "not even wrong" for the purpose (that, at least, has been improved to Python, which is only [fill in the blank] hostile to FP).
Not one of the department's finer moments, from my no direct interest in EE at all viewpoint, but from a less biased one you can safely say a MIT EECS degree now means something quite different. And it's a damned shame for those outside the department, for whom 6.001 was truly valuable, that MIT no longer offers anything in its niche (outside of a rearguard 1 month version of it during January).
I really do recommend it for anyone trying to get into functional programming or to understand the nirvana of Lisp / Scheme.
Full lecture series based on the first edition of SICP. I viewed and read after nearly 10 years programming in more mainstream languages (self-taught), and honestly think that 10 years was partly wasted because I didn't learn Scheme earlier.