The obvious solution: rewrite SICP to use Python rather than Scheme. It is CC attribution and non-commercial, so I don't see any legal barrier to outsider revision.
The beauty of Scheme is that it makes the underlying language mechanics transparent. The mental models I acquired from SICP for the process of computation have served me well across a dozen languages since.
No, I definitely agree with this. Scheme is a valuable pedagogical tool.
But that probably doesn't matter. So it's better, on the whole, to preserve what you can out of the current book by adapting it to Python than losing it completely.
Things will get lost in translation and substantive changes will have to be made. That's why writing textbooks is a creative endeavor rather than just updating the English used in older texts.
SCIP winds up making sure that you understand what is going on by writing Scheme interpreter in Scheme. How would your translation handle that material?
Writing a Scheme interpreter in Python would force people to learn all of that Scheme anyways, and it wouldn't feel like such a revelation that you understand what the interpreter is actually doing.
Writing a Python interpreter in Python would force people to learn a lot more about parsing techniques. That would add a lot more material, and the code would be substantially more complex, thereby obscuring the pedagogical point.
Why not write a python(subset) interpreter in scheme?
The point is once you scan,tokenize and parse you get an AST. You already got a language that works on AST. I don't think python's AST is gonna differ a lot from scheme's.
I think that the point was that the AST for a Scheme program isn't that different from the AST for a Python program, even though the code looks different.
Unfortunately that point is false as well. The AST for a Python program will generally involve a lot of message dispatches that won't exist in the AST for a similar Scheme program.
To get a sense of the difference, in Python if you yield, your code actually gets turned into a class with certain methods that get called repeatedly, and restart your method at the correct place with the correct state. By contrast equivalent code in Scheme will somewhere under the hood have call-with-current-continuation, which works by very different mechanics.
That is not possible or desirable. Scheme-specific constructions are woven throughout the text -- tail calls, closures, and more.
And the main value of SICP, at least for its fans, is the pedagogic value of the language. It starts off with pure functional programming and then introduces assignment much later, and discusses its tradeoffs.
How are tail calls and closures in any way Scheme-specific?
The "main value" cited also assumes "pure functional programming" is worthwhile. That is not an uncontroversial opinion, and does little to make the case for SICP to people not already convinced.
Scheme works great in SICP because it doesn't get in the way. After the first few pages, it doesn't feel like you're reading a programming language so much as reading the direct expression of concepts discussed in the text. The programming language learning hurdle is almost nonexistent.
That fact reduces cognitive load on the reader, freeing up mental resources that can be applied to the concepts presented.
Well, the question was about Python, which definitely doesn't have those things. If you want to me to justify Scheme, how about code-as-data, which is the entirety of chapter 4?
> That is not an uncontroversial opinion, and does little to make the case for SICP to people not already convinced.
That was not an unconsidered viewpoint, if you read what I wrote. I said "for its fans". I am not attempting to make the case for SICP; that book doesn't need my help.
CPython doesn't have built-in tail call optimization, but that's not a fundamental property of the language, just a limit of that particular implementation. One that can even be hacked around in Python with a decorator. A decorator, by the way, is a Python feature that depends on closures, which are themselves quite commonly used in Python.
You have some very strange ideas about Python that appear to have little relation to reality.
Python has things they call closures but they aren't what Scheme (or Lisp, or Perl, or Ruby, or Smalltalk, or JavaScript, or C#...) would call a closure. I think it's fair to say that Python is the odd language out here. The scoping rules are different unless you use the relatively recent "nonlocal" keyword.
Anyway, why are you getting offended? Python is a great language.
Some people just think Scheme teaches certain aspects of programming better for various reasons. For instance, in Scheme, the program listing is a representation of the parse tree. Python will construct a similar tree, but this is not revealed to the programmer as much. So if you learn Scheme you can imagine how what Python is really doing (and writing parsers is much simpler because you have an intuitive sense of how they work).
And the ability to manipulate code as data is exclusive to s-expression based languages. This enables (for instance) truly hygienic macros. You don't get that in Python.
On the other hand, object-oriented programming in Scheme is pretty terrible. The part in SICP where they try to simulate it in Scheme is a travesty. Although it is somewhat illustrative of what's "really" going on, without the syntactic support it just looks ridiculous. So that's a win for Python.
Similarly, whipping up a complex data structure takes far fewer keystrokes, and is more transparent, in Pythonic syntax. Just as Scheme benefits from having built-in lists, Python wins even bigger for having lists and dictionaries everywhere. And overall Python is objectively more practical, with its vast array of libraries and ease of use.
I honestly don't know if you're trolling or are just being partisan. Not all languages are the same and there isn't any one "winner" language.
Unusual scoping rules that are easily worked around do not make Python's closures not closures. And I'm not sure why you're bringing up lambda -- I don't know anyone who uses it much, and I consider it an obfuscation mechanism rather than a useful tool.
As for your personal attacks on me... I dispute statements you made that I consider to be utterly wrong, and you say I'm "getting offended" and "trolling"? Now I'm offended.
I look up and down the comments on here and I see all sorts of people making blanket statements about how great Scheme is, yet when I argue a couple specific points you brought up about Python, I'm being the partisan troll? WTF?
My impression is that a lot of the Python in such a book would be highly non-idiomatic and/or too clever to be considered "good Python practice", which is not a very good idea in a pedagogical setting
