I think I fail to understand your somewhat poetic and evocative language, I'm afraid that I'm going to ask you to dumb it down for me:
>"The language doesn't really matter", as such it's imperative Scheme is used.
This is an obvious contradiction and clearly you meant it that way but what do you imply exactly?
>I strongly feel that if you've worked your way through SICP, and, once finished, you think "Neat. I'll rewrite this but with language X," you've really missed out on value of SICP.
>It's challenging enough to follow for people who know a Lisp going in, but using a language more mainstream and familiar to make it easier is largely counter-productive.
You claim that using an other language for SICP is "[missing] out on value" and "largely counter-productive" but you don't produce any evidence or argument to support that.
Going through SICP using a static and non-reflective language like C does seem very frustrating but using a very dynamic language like Python might indeed be a decent fit. At least I can't see what's so obviously wrong about it.
I am not craigsmansion, but I think I know what he or she meant. The lessons in SICP are about fundamental computing concepts and independent of any language. The authors simply chose Scheme because it is easy to learn and let them teach those lessons comfortably.
This means that rewriting it using a different language is mostly a waste of time: it's not a very short book, so rewriting takes a while and what is gained? It seems to me that, at most, you learn that specific language in addition to the fundamental concepts. I personally, would not think that is worth the effort.
> The lessons in SICP are about fundamental computing concepts and independent of any language. The authors simply chose Scheme because it is easy to learn and let them teach those lessons comfortably.
Exactly, And for some of their audience they may already be more familiar with a different language -- so why not lower the barrier of entry?
As someone who just picked up SICP to see what the big deal was, I think that the choice of Scheme actually does add something: the ridiculously minimal syntax adds a kind of clarity, making it clear that things you thought were fundamental aspects of programming are really just language features. There is so little syntax to learn that virtually everything you learn is a lesson in program structure - because there's barely a "language" at all.
I was already familiar with Python when I started SICP, and the simple syntax caused a kind of fundamental shift in perspective. I had absolutely no idea how the Python parser worked. I couldn't model it in my head. I just knew that there were all these special things - methods, loops, iterators - and I could try and reason about how they'd work together, but I didn't really have a mental model of what was going on.
Scheme, in contrast, was so simple that they tell you more-or-less how the parser works in the very first chapter. I solved many of the first chapter's exercises on paper. I couldn't - and still can't - imagine running a Python program with paper and pencil. For the very first time in my life, I actually had a mental model of what exactly my code was doing.
And the super-minimal syntax made so many things I'd understood as totally distinct atomic concepts could actually be treated as related. The shift from f(x) to (f x) was a transposition of a single character - but it actually changed the way I was looking at the concept. f(x) was static - you specified a particular f, and applied your choice of x. (f x) - and suddenly f and x are objects of similar status. Expand and evaluate the element on the left. Expand and evaluate the element(s) on the right. Plug the stuff on the right into the stuff on the left. They follow the same rules! You can have (f (+ x y)) sure, but you could have the f as a compound procedure too! Or on the question of loops and recursion - loops had always been something I understood as a particular special construct, totally unrelated to recursion. Then - oh. Of course. They're both just ways of calling the same procedure multiple times. They're both recursion, just with different structures.
Basically, I think Scheme is serving two purposes here. The first - everyone learns assumptions from their first programming language. That's why you should always learn a second one, ideally a quite different one, just so you can see how there can be entirely different ways of thinking about and structuring the same concepts. So a language that's nobody uses is actually the perfect language to teach how to Structure and Interpret Computer Programs, because it helps you get past the pre-existing assumptions you'd unknowingly picked up about how to do that.
And secondly, because the syntax is so simple that it helps you really, clearly understand what your program is doing, what various ways of doing things mean. I hadn't even realized before picking up SICP that "learning to program" was a distinct skill from "learning how to code." They were the same thing - you learn the programming language, and then you just use the tools it gives you. Not knowing how to write something to solve a problem was mostly just an issue of not knowing the features of the language, or the available libraries, well enough.
In the first chapter, I was introduced to a simple subset of an already simple language. It was just parentheses, definitions, and conditionals, and a set of expansion and substitution rules basic enough I could work them out on paper. I didn't even have loops or lists. And it became suddenly clear that while I'd taught myself to code from reading language tutorials and the excellent Python documentation, I had never actually learned how to program.
So what I'm saying is, as an amateur programmer who was familiar with Python and not much else, I'm extremely glad that they chose to write it in Scheme instead of Python.
I see what you mean but I don't think it justifies "as such it's imperative Scheme is used". I'm by no means a fan of Python but its syntax not much more complex than that of a lisp and on top of that it supports infix notation which will probably be easier to write and read for beginners since it more closely matches the mathematical notation they're undoubtedly already familiar with. Even the function evaluation matches mathematics better: f(x) instead of (f x).
Rewriting SICP using Python instead of lisp does seem like a rather boring and thankless job but I'm not sure that reading through SICP in Python would be much worse than using Scheme.
> This is an obvious contradiction and clearly you meant it that way but what do you imply exactly?
If you take "not matter" literally, you could derive that the more a language "matters" (has real-world applications), the worse it would fit. It could be argued that Scheme does not matter for the real world, and as such should be the perfect fit.
More seriously, Scheme is very small. Everything is done by what technically could be described as implementing a Domain Specific Language (DSL). It could be argued that any program in any language is just a DSL for solving a particular problem. If the language doesn't matter, then any language will do, and Scheme with its natural DSL-like approach is very close to the ideal "any language".
> You claim that using an other language for SICP is "[missing] out on value" and "largely counter-productive" but you don't produce any evidence or argument to support that.
Every language, including all Lisps, at some level reflect the machine or model it runs on. This creates a bias of "how things are/work".
SICP goes through great lengths to undo that: "This is how you think X works. That's not how it works. It also doesn't matter how it works, because the concept we're discussing is valid either way. So stop thinking about these details."
The fewer preconceptions you have about what you think is "programming," the better it is for understanding what the lectures are about. If you go in knowing a Lisp, it's easy to miss what they're talking about because it invites you to , being already familiar with the syntax, assume it's about the language when it's not.
This contradicts a "SICP for Python programmers."
So "SICP for Python programmers" is really the normal "SICP", which in turn should be called "SICP for all programmers except Lispers" with them losing out because there's really no better language to express the ideas behind SICP in so they might as well use SICP and try to hold their bias in check.
>"The language doesn't really matter", as such it's imperative Scheme is used.
This is an obvious contradiction and clearly you meant it that way but what do you imply exactly?
>I strongly feel that if you've worked your way through SICP, and, once finished, you think "Neat. I'll rewrite this but with language X," you've really missed out on value of SICP.
>It's challenging enough to follow for people who know a Lisp going in, but using a language more mainstream and familiar to make it easier is largely counter-productive.
You claim that using an other language for SICP is "[missing] out on value" and "largely counter-productive" but you don't produce any evidence or argument to support that.
Going through SICP using a static and non-reflective language like C does seem very frustrating but using a very dynamic language like Python might indeed be a decent fit. At least I can't see what's so obviously wrong about it.