Live data from Hacker News

Why MIT switched from Scheme to Python (2009)

wisdomandwonder.com

201–210 of 249 posts

Re: Why MIT switched from Scheme to Python (2009)

#201

Earlier quoted context omitted.

I think the solution is to have, as is the case in math/physics, an honors intro CS sequence compared to the regular intro CS class. The latter would be the recommendation for all non-CS majors, and the former would be for CS majors. I've always thought that those who are focusing on more vocational training should not be in what is called the CS program, maybe there are other majors called "software development" or…

Similarly for math. I had to take a linear algebra class as a math major that was mostly populated by engineering majors and it was painful (given that they were allergic to proofs).

I could never understand the proof allergy. To be honest I find it was easier for me to perform well in proof based classes rather than “here’s an algorithm, apply it” type. The main reason was that it was harder for me to make mistakes while constructing a proof in comparison to applying an algorithm and making calculations by hand.

I acknowledge high schools are notorious in omitting the introduction to proof techniques but it’s a one time hurdle and you end up with a good stuff in your toolbox.

Re: Why MIT switched from Scheme to Python (2009)

#202

When I read this I just feel like Sussman is getting out of touch and maybe a little disillusioned. From the wording he seems annoyed about the change, isn't even sure why it was made "probably because there's some library for robots", has gone from someone who would have a complete understanding of complex systems to someone who sounds more like a frustrated beginner. "Doing basic science on libraries to see how the…

Can you not see that there is a philosophical difference between these two approaches and why someone might have a preference for one or the other?

There isn't a philosophical difference. Both are problem solving strategies. You would choose one or the other depending on goals and constraints. There isn't a 'philosophical' reason to choose one or the other.

In the end the choice wasn't made for philosophical reasons. It was made because the robot library was in Python, or so he thinks. I think this actually shows there was a strong reason to never use Scheme: it's a failed language family. Outside of academic life support and very niche uses (which are usually directly caused by the academic uses, such as Emacs lisp) scheme just doesn't exist out in the world, despite a dozen very competent and complete implementations that are still supported. This is not an invitation for lisp fan boys to stomp their feet, TIOBE doesn't have any (()())()(()) language in the top 20. Debate rankings all you want, but lisp type languages are extremely rarely used because people don't find them productive when given a choice.

Re: Why MIT switched from Scheme to Python (2009)

#203
post #144
post #99

Earlier quoted context omitted.

This comment so obviously belongs on https://news.ycombinator.com/highlights that it's maybe a good occasion to mention that https://news.ycombinator.com/highlights exists. Thanks! (and sorry for offtopicness)

Neat. Is there any way to search the highlights? ("What are the most noteworthy things that have been said on HN about ...?" "I remember reading an excellent comment that had something to do with ..., but all I can remember is that it used the word ..." "Do I have any comments in the highlights?")

Not yet, sorry.

Re: Why MIT switched from Scheme to Python (2009)

#204
post #176
post #99

Earlier quoted context omitted.

This comment so obviously belongs on https://news.ycombinator.com/highlights that it's maybe a good occasion to mention that https://news.ycombinator.com/highlights exists. Thanks! (and sorry for offtopicness)

Would love an RSS feed.

That would require ordering them by time highlighted, not by the original time posted. Worth doing, but not done yet!

Re: Why MIT switched from Scheme to Python (2009)

#205
post #167

Earlier quoted context omitted.

> But your comment is completely off-base. I think it is rather your reply that is off-base; or else I have not made myself sufficiently clear. My point was simply that the words used to describe the other courses are better fits for what SICP teaches than "procedural", which is a poor fit for describing Lisp-family languages and would make more sense applied to other contemporary languages like COBOL and FORTRAN (an…

Your comments are clear enough; they're just mistaken. Lisp dialects generally do not support mathematical functions, despite supporting the functional-programming idiom, which is inspired by mathematical functions. Rather, they support procedures, which in most Lisps are called "functions". In Scheme, however, the Lisp they chose for the course, they are called "procedures", an intentional choice to avoid creating p…

> The five chapters of SICP (I recommend http://sarabander.github.io/sicp/html/index.xhtml) are:

> - 1 Building Abstractions with Procedures

Where Abelson, Sussman & Sussman use the word "procedures" here, they mean what we would typically call "functions" today. Today, "procedural programming" basically means "imperative programming", and that is not the idiom they are teaching. (Where the exact term "procedure" is used nowadays — though it's less common now — it generally refers specifically to a function which does not return a usable value, which is called specifically for its side effects. SICP instead generally describes what we would now call "functional programming".)

> That is, you were explicitly asserting that the core material of SICP was concerned with "structure", "architecture", and "functions" in the sense of the core material of those courses

By "SICP" I clearly meant 6.001 and only 6.001, since that's the course titled as such ("SICP" stands for "Structure and Interpretation of Computer Programs").

I was not asserting that SICP was concerned with any term in the sense of the core material of any other course, which is why I didn't mention the other courses in that sentence. I was asserting that SICP was concerned with those concepts as they are commonly understood.

I wrote the comment knowing nothing of the content of the other courses, because nothing about the content of the other courses was relevant to the point I was making.

Please do not try to tell me what I meant by my own words.

Re: Why MIT switched from Scheme to Python (2009)

#207

Earlier quoted context omitted.

That should be the beginning of the formative experience for that kid rather than the end. Yes, you can. How often do you? What are you missing by not thinking about problems in that way more often? What idioms could be unlocked that way? (How many Python programmers out there are aping wholly unnecessary "design patterns" created for C++ or Java? Or rather: shouldn't a design pattern be about the design rather than…

Don’t worry, aforementioned kid is doing just fine, machine learning PhD IIRC. There is a lot of other remarkable stuff in modern computing.

Oh, I don't doubt that. Smart kids usually land on their feet just fine (and even when they don't, they cope and mask their problems better). But when I get the opportunity to teach things, I strive to allow smart students to rise to their own level.

Re: Why MIT switched from Scheme to Python (2009)

#208

Earlier quoted context omitted.

> There were four 15-unit courses, each about one of these "languages": The description you offer is strange to me. The Lisp family of languages are multi-paradigm (arguably paradigm-independent) and can hardly be called "procedural". The core material of SICP revolves around considering the "means of combination" and "means of abstraction" offered by a programming language — concepts that sound to me like they have…

I'm a bit disappointed by some of the responses you received and that you were apparently downvoted. Here's some text from Chapter 1 of the book that might make this clearer: > Procedures, as introduced above, are much like ordinary mathematical functions. They specify a value that is determined by one or more parameters. But there is an important difference between mathematical functions and computer procedures. Proc…

I appreciate it. The observation was really intended to be about the semantic drift, and the odd coincidence of language.

Re: Why MIT switched from Scheme to Python (2009)

#209

Earlier quoted context omitted.

> But your comment is completely off-base. I think it is rather your reply that is off-base; or else I have not made myself sufficiently clear. My point was simply that the words used to describe the other courses are better fits for what SICP teaches than "procedural", which is a poor fit for describing Lisp-family languages and would make more sense applied to other contemporary languages like COBOL and FORTRAN (an…

You may want to take your issue with the use of the word "procedural" up with the authors of SICP: > Underlying our approach to this subject is our conviction that “computer science” is not a science and that its significance has little to do with computers. The computer revolution is a revolution in the way we think and in the way we express what we think. The essence of this change is the emergence of what might be…

That does explain the use of the term. They are reasoning about the systems in terms of what will happen (its procedure), but still describing systems as compositions of parts (as nodes in an AST, effectively) rather than as lists of instructions. And they teach how to analyze problems in order to design systems that way. And, of course, writing the program is inherently a self-directed imperative; you can't simply learn how to write programs and have programs exist as a result — you have to take that initiative.

Re: Why MIT switched from Scheme to Python (2009)

#210
post #152

Earlier quoted context omitted.

> Whereas Python is excellent for teaching applied computer engineering, because it's essentially executable pseudocode for imperative languages It's not that simple, Python is a fiddly, complex, high-level language that has accreted features in a very ad-hoc way. This makes it very hard to teach and learn in a way that's expected to pay even the most cursory attention to actual rigor. You could probably define a Bab…

Python was invented as a language for newbies. It's come a long way! https://en.wikipedia.org/wiki/History_of_Python#Version_1 > During Van Rossum's stay at CNRI, he launched the Computer Programming for Everybody (CP4E) initiative, intending to make programming more accessible to more people, with a basic "literacy" in programming languages, similar to the basic English literacy and mathematics skills required by mo…

> "Python was invented as a language for newbies."

Yeah, but so was BASIC. If Edsger Dijkstra were alive today to write an updated edition of his infamous "How Do We Tell Truths That Might Hurt?" essay, he'd probably just just reuse his quip for BASIC for Python.

Post reply on HN