SICP in Python
31–40 of 136 posts
Re: SICP in Python
#32Re: SICP in Python
#33Up next: Sicp JAVASCRIPT
Announcement on Reddit: https://www.reddit.com/r/scheme/comments/ea1f8w/sicp_js_goin...
Re: SICP in Python
#34It made me so sad when I found out CS61A was being taught in Python. I love Python, but I also know that I would have missed out on so much wonderful information if I hadn't learned Scheme. It was truly mind blowing when they had us implement a Scheme interpreter in Scheme, and then add infix operators. I think the original SICP was perfect for an intro course. It was also the great leveler, because even if you enter…
Thank you for explaining why you think Scheme is a better langauge for SICP than Python. As a fan of Python, my reaction to seeing this course was: "oh cool, a course on interesting things in a language I'm comfortable with". I was then somewhat discombobulated to see the Python bashing in the comments.
Scheme is a good language for SICP because it's simple. You can build a Scheme interpreter as a class project. You can analyze it formally. Etc.
Python is a good language because it's readable and writeable. But it doesn't work for SICP since it's too complex for that. Python also intentionally omits things critical to SICP (like tail recursion).
Calling this book "SICP in Python" would be like taking your favorite poem, releasing it into a different language, and finding that the translators wrote a completely different book, with a different theme, to make it rhyme and the rhythm hold. Just something different with the same name.
Re: SICP in Python
#35"Do not seek to follow in the footsteps of the wise; seek what they sought." - Basho One of the reasons that the wizards stopped teaching SICP was the fact that the world changed. Back in the 80s, most programming was done from first principles, since the middle of the 90s it switched to programming against an API. While learning to program from first principles is still amazingly useful, it is not what beginners nee…
I’m not so sure. SICP gives a deep understanding of programming principles like abstraction. I agree that gluing APIs is essentially what modern programming has become, but it is helpful to have that extra understanding, especially in the long term. We don’t know how programming will look in 2050, but abstraction will remain abstraction, and I wouldn’t bet against Lisp being more popular then than it is now.
Somewhere at the bottom, fundamental code is always present.
Re: SICP in Python
#36Earlier quoted context omitted.
Thank you for explaining why you think Scheme is a better langauge for SICP than Python. As a fan of Python, my reaction to seeing this course was: "oh cool, a course on interesting things in a language I'm comfortable with". I was then somewhat discombobulated to see the Python bashing in the comments.
SICP is about deeply understanding computation. Scheme is a good language for SICP because it's simple. You can build a Scheme interpreter as a class project. You can analyze it formally. Etc. Python is a good language because it's readable and writeable. But it doesn't work for SICP since it's too complex for that. Python also intentionally omits things critical to SICP (like tail recursion). Calling this book "SICP…
Re: SICP in Python
#37Earlier quoted context omitted.
Thank you for explaining why you think Scheme is a better langauge for SICP than Python. As a fan of Python, my reaction to seeing this course was: "oh cool, a course on interesting things in a language I'm comfortable with". I was then somewhat discombobulated to see the Python bashing in the comments.
If you're looking to learn cool stuff, I highly recommending finding a copy of the original SICP in Scheme and working through it. It will expand your mind to new ideas.
The web version appears to work though: http://sarabander.github.io/sicp/html/index.xhtml
Re: SICP in Python
#38"Do not seek to follow in the footsteps of the wise; seek what they sought." - Basho One of the reasons that the wizards stopped teaching SICP was the fact that the world changed. Back in the 80s, most programming was done from first principles, since the middle of the 90s it switched to programming against an API. While learning to program from first principles is still amazingly useful, it is not what beginners nee…
That's one of the secret revelations in SICP. If you go in with some knowledge of assembly or C, you can quickly feel it's really high-level and not all that fundamental.
That is, until it addresses your precious "fundamental" bits and bytes, and you suddenly realise the model it is showing you is a model you can build computational platforms with, including your up-to-then understanding of registers and ALUs, and it illustrates that computing essentially has nothing to do with any specific hardware: all you need is pencil and paper and the command of a natural language, but with some parenthesis, you can optionally instruct a machine to do it for you as a bonus.
> it is not what beginners need because most of them will never end up programming like that.
which makes any "SICP in X" effort so useless: "let's make SICP understandable for people who do not want to understand it."
Re: SICP in Python
#39Earlier quoted context omitted.
The vast ecosystem of python libraries is an incredibly powerful argument for using it. One major library could dramatically cut the development time of your project. You’ve not spelt out actual reasons why Python is so bad, could you give your top three?
One thing I have felt is that python doesn't embrace the functional way of thinking, even to the extent that JavaScript does. I personally find that once I have been exposed to a modern functional approach like in Clojure, etc, I find python lacking. Not just syntactically, but conceptually. For example, IIRC, many list methods in python modify the list they are working on, instead of returning a new list.
Consider:
getNumbers() .map(x => x×2) .filter(x => x % 6 == 0) .map(x => x^2)
get numbers. double them. filter for divisibility by 6. square them.
versus
[x^2 for x in x×2 for x in getNumbers() if x % 6 == 0]
get the square of the doubles version of getNumbers values, but only if those doubles are dividable by 6. But wait are the doubles dividable by 6 or the squares?
Maybe some people are fine with looking at what operations are being performed on the data before even knowing what the data itself is, but that for me seems incredibly backwards. Plus it also gives rise to order of operations ambiguities. Nobody could mistake the ordering in JS, but I honestly have no clue how that python would evaluate.
(using carats because hn cant format code)
Edit- This came to mind because of a flattening list comprehension I encountered earlier today:
#flatten the lists
flattened_list = [y for x in list_of_lists for y in x]
I've spent quite some time staring at this and I still have no clue what it's actually doing. I've never had that with JS operator chains.
Re: SICP in Python
#40"Do not seek to follow in the footsteps of the wise; seek what they sought." - Basho One of the reasons that the wizards stopped teaching SICP was the fact that the world changed. Back in the 80s, most programming was done from first principles, since the middle of the 90s it switched to programming against an API. While learning to program from first principles is still amazingly useful, it is not what beginners nee…