Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

cemerick.com

Post reply on HN
Print view View original

111–120 of 141 posts

Re: Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

#111

Post by piyush_soni »

bjoli wrote: post #107
piyush_soni wrote: post #102

Earlier quoted context omitted.

I have working knowledge of C, C++, Scheme, and a little bit of Python, but I really don't think Scheme is true to all its hype. I'm not even sure if everyone praising it here is using it in real life projects or not or only academically. We do, and man, the tough life is with it. The only debugging we have here is numerous "format (print)" statements, it is terribly slow, and may be not everyone's using it as intend…

Which scheme are you using? Chez, chicken, guile and gambit all have pretty good debugging facilities, and a macro like chez's trace-lambda is a lot better than misusing print-debugging in most cases. Nobody ever said most list operations is anything else than o(n), and if you are using lists you are probably using the wrong data structure. Vectors or hash tables would probably be a better choice (which are provided…

Ours is probably some 20 years old initial MIT Scheme implementation added with homegrown features like "Object Oriented Scheme" etc., but a debugger was never implemented for the same. Talks have been going on to move to an implementation that has a debugger, but at such a scale changing that would be difficult.

Re: Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

#112

Post by qwerty456127 »

> Then, what generaly happened was a programmer would think for a really long time, and then write just a little bit of code, and in practical terms, programming involved assembling many very small pieces

Oh how I bloody want to do jut this today. I want my program to be split into as small parts as possible, every part (i.e. every function) being defined in a separate file. But Python encourages the direct opposite - writing long files of code to avoid introducing too many "modules" and this is a debilitating headache.

> At some point along the way (he may have referred to the 1990’s specifically), the systems that were being built and the libraries and components that one had available to build systems were so large, that it was impossible for any one programmer to be aware of all of the individual pieces, never mind understand them.

Thanks to my ADHD it is very hard to me to fit anything that doesn't fit in half a screen into my mind. The longer a module growth the lower my productivity falls.

Re: Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

#114

Post by jasonpeacock »

qwerty456127 wrote: post #112

> Then, what generaly happened was a programmer would think for a really long time, and then write just a little bit of code, and in practical terms, programming involved assembling many very small pieces Oh how I bloody want to do jut this today. I want my program to be split into as small parts as possible, every part (i.e. every function) being defined in a separate file. But Python encourages the direct opposite…

> But Python encourages the direct opposite - writing long files of code to avoid introducing too many "modules" and this is a debilitating headache.

How does Python encourage mega-files? AFAIK there's nothing that prevents nor discourages proper organization of code into files.

I frequently use multiple files to organize my library implementations.

Re: Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

#115

Post by stutonk »

piyush_soni wrote: post #111
bjoli wrote: post #107

Earlier quoted context omitted.

Which scheme are you using? Chez, chicken, guile and gambit all have pretty good debugging facilities, and a macro like chez's trace-lambda is a lot better than misusing print-debugging in most cases. Nobody ever said most list operations is anything else than o(n), and if you are using lists you are probably using the wrong data structure. Vectors or hash tables would probably be a better choice (which are provided…

Ours is probably some 20 years old initial MIT Scheme implementation added with homegrown features like "Object Oriented Scheme" etc., but a debugger was never implemented for the same. Talks have been going on to move to an implementation that has a debugger, but at such a scale changing that would be difficult.

By MIT scheme, do you mean MIT/GNU scheme? A few schemes implement their debuggers in terms of call/cc (or delimited counterparts) and exceptional conditions like errors or breaks hand control to a new 'depth' of REPL where anything in the environment can be inspected (or redefined) in-context before possibly trying to continue or doing any unwinding. If your scheme has no debugging apparatus, it shouldn't be too hard to implement something a little more useful than sprinkling in print statements. Even without wading into continuations, implementing a macro that does tracing should be possible.

Re: Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

#116

Post by peatmoss »

piyush_soni wrote: post #102
southerndrift wrote: post #43

Earlier quoted context omitted.

Compared to C, Python is the better choice. However, it seems like you haven't learned a Lisp dialect. I would love to know if you would still prefer Python once you know Scheme.

I have working knowledge of C, C++, Scheme, and a little bit of Python, but I really don't think Scheme is true to all its hype. I'm not even sure if everyone praising it here is using it in real life projects or not or only academically. We do, and man, the tough life is with it. The only debugging we have here is numerous "format (print)" statements, it is terribly slow, and may be not everyone's using it as intend…

> deluge of useless parenthesis that it is, it hurts my eyes to read that code.

Oh, how I wish I could share the joy I experience using Paredit with those parentheses. Paredit turns parentheses from an inconvenience into a turbo button for modifying code at an entirely new level of abstraction.

When you started coding, you probably used an editor that worked on units that were single characters. Think Notepad. Then maybe you learned a programmers editor like Emacs, Vim, or Atom or Sublime. There you learned to cut, copy, fold, spindle, and mutilate code in lines or paragraphs.

But Paredit... oh Paredit... now you have the tools to work with your code not in characters, lines, or paragraphs, but in code forms—the same stuff your code is made from.

And the best part is that Paredit doesn’t have to have a deep knowledge of your code, groping imperfectly like Intellisense. Paredit is deterministic and easy to implement.

If I could have an S-expression based version of every other language simply for paredit, I'd take it.

Now a story for a different day is how much I hate typing commas in non-lisps.

Re: Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

#117

Post by qwerty456127 »

jasonpeacock wrote: post #114
qwerty456127 wrote: post #112

> Then, what generaly happened was a programmer would think for a really long time, and then write just a little bit of code, and in practical terms, programming involved assembling many very small pieces Oh how I bloody want to do jut this today. I want my program to be split into as small parts as possible, every part (i.e. every function) being defined in a separate file. But Python encourages the direct opposite…

> But Python encourages the direct opposite - writing long files of code to avoid introducing too many "modules" and this is a debilitating headache. How does Python encourage mega-files? AFAIK there's nothing that prevents nor discourages proper organization of code into files. I frequently use multiple files to organize my library implementations.

Just some clues: A class definition can not be split in many files (e.g. in C# you can do this easily with "partial class" declaration and that's amazing, needless to say you can and almost always do split one module (a namespace) into many flies there). Whatever you put in a separate file you will have to import manually everywhere you use it and you have to care about circular imports. You have to invent names all the time, a package, a module and a function having the same name smells a headache. The C# namespaces definition system could be made even better than it is already (i.e. by allowing class-free functions directly inside namespaces) but it already feels just so much better than Python "module = file" model.

Re: Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

#118

Post by peatmoss »

mroche wrote: post #14
ng12 wrote: post #2

> However, he did say that starting off with python makes an undergraduate’s initial experiences maximally productive in the current environment. I read this as "the parents paying tuition wanted their kids to learn practical skills so they can make money". I learned Scheme as a first language and I will be forever grateful for it.

Python was my first, but the computer science course at my university uses Scheme for one of its primary required courses. Really kicked my ass with man-handling recursion and lambdas to no end. Implementing trees (usually binary) gave me a hell of a time. I got so sick of opening DrRacket by the end of the semester. That being said, I did respect the course and the language. I didn’t understand the science part of c…

I learned Python long before touching anything like a lisp, and the closest thing to functional programming that I’d done before touching a lisp was R. All self-taught, usually in the service of something else I wanted to do. I have no formal training in CS.

And so my use of Racket is simply as a dilettante. And I LOVE it. I have a lot of imposter syndrome and not really grokking data structures the way CS people can tell you the tradeoffs and implementation details of a B-tree. But, I LOVE coding in Racket when I get the chance.

For me, it’s a language where I can jank-hack things together like Python, but having more fun. Wonder if that’s because I never had the fun of Racket sullied by also having to learn data structures and CS fundamentals at the same time?

Re: Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

#119

Post by kazinator »

jcelerier wrote: post #93
southerndrift wrote: post #43

Earlier quoted context omitted.

Compared to C, Python is the better choice. However, it seems like you haven't learned a Lisp dialect. I would love to know if you would still prefer Python once you know Scheme.

> Compared to C, Python is the better choice. However, it seems like you haven't learned a Lisp dialect. I would love to know if you would still prefer Python once you know Scheme. the school I went used to teach C, Python and Scheme in the first year (nowadays it's C, Python and Racket). I don't think I remember more than one or two people actually liking the LISP experience, how bad it was when comparing to other l…

The language known as Scheme has done a lot of damage to Lisp's image. When undergrads are exposed to Scheme, they tend to forever carry a negative image of Lisp by association.

A lot of the time when you meet someone who had a bad experience with Lisp, if you interview them a bit, you soon discover it was actually Scheme.

Scheme twenty years ago, R5RS was even worse than now. It had nothing practical in the spec. No way to write a program consisting of multiple files. No error handling. R5RS talks about situations that trigger an "error", but nothing about how such a thing can be handled and recovered. Or how an error can be generated on purpose and then caught.

Anyone who studied R5RS in school was learning an utter piece of academic garbage; a serious regression from real Lisp.

Re: Why MIT uses Python instead of Scheme for its undergraduate CS program (2009)

#120

Post by jcelerier »

jimhefferon wrote: post #97
jcelerier wrote: post #93

Earlier quoted context omitted.

> Compared to C, Python is the better choice. However, it seems like you haven't learned a Lisp dialect. I would love to know if you would still prefer Python once you know Scheme. the school I went used to teach C, Python and Scheme in the first year (nowadays it's C, Python and Racket). I don't think I remember more than one or two people actually liking the LISP experience, how bad it was when comparing to other l…

I'd be interested in what aspects strike people as bad. (Honest question. If you reply, I promise not to come back with "But, but, but ...")

I will answer your question through its dual : the people who love LISP and functional programming are in my experience people who love maths - as in, algebra, etc. . You can easily recognize them, because they say weird things such as "this demonstration is so elegant !".

Functional programming of course maps (heh) very cleanly to this line of thought.

But most people hate maths and this way of thinking. In contrast, you get first year students "re-discovering" OOP ever year - for instance a common trick to make them learn design patterns is just to put a problem that calls for it in front of them, and three times out of four in my experience they will even come up with a pattern name close to the original ones.

Post reply on HN