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

Why MIT switched from Scheme to Python

wisdomandwonder.com

Post reply on HN
Print view View original

101–110 of 140 posts

Re: Why MIT switched from Scheme to Python

#101

Post by abecedarius »

scott_s wrote: post #87
habibur wrote: post #70

Earlier quoted context omitted.

Why can't we keep the indents and drop the parens?

It would make data generation more difficult. When you emit any given data, you'd have to know its level of nesting to get the correct number of indents. Using begin and end tokens (whatever they are) makes that much easier. (I actually prefer Python's style of using indentation to indicate blocks, but I recognize generating such code is harder than code with tokens.)

You don't have to know the level of nesting; you can add indents afterward just as easily as you can wrap a subexpression in parentheses afterward.

def indent(code): return code.replace('\n', '\n ')

Re: Why MIT switched from Scheme to Python

#102

Post by scott_s »

abecedarius wrote: post #101
scott_s wrote: post #87

Earlier quoted context omitted.

It would make data generation more difficult. When you emit any given data, you'd have to know its level of nesting to get the correct number of indents. Using begin and end tokens (whatever they are) makes that much easier. (I actually prefer Python's style of using indentation to indicate blocks, but I recognize generating such code is harder than code with tokens.)

You don't have to know the level of nesting; you can add indents afterward just as easily as you can wrap a subexpression in parentheses afterward. def indent(code): return code.replace('\n', '\n ')

In my current project, I've implemented a source-to-source compiler. In the places where I emit C code, I usually don't have a handle to the scopes above me. I could get one, but it would take more work.

The code I generate has no indents and no newlines. Not having to keep track of these makes life simpler. To make my generated code more legible, I just run indent on it.

Re: Why MIT switched from Scheme to Python

#103

Post by mahmud »

NonEUCitizen wrote: post #55
tlb wrote: post #33

Earlier quoted context omitted.

People often say that Java has great libraries, but is it true? AWT is crufty and ugly. Maybe there are impressive XML parsers (Xerxes is 188,000 lines of Java!), but I don't want those. Numerical libraries seem bad. So what is the library that might convince me to use Java for something?

lucene

Which is a clone of a Common Lisp search engine ;-)

Re: Why MIT switched from Scheme to Python

#104

Post by herdrick »

tlb wrote: post #33
time_management wrote: post #9

I wonder, if the switch had been made now, it they would have switched to Clojure instead of Python. It's a lot closer to Scheme, and its connection to the JVM gives it a lot of practical power. Does anyone have any thoughts on this?

People often say that Java has great libraries, but is it true? AWT is crufty and ugly. Maybe there are impressive XML parsers (Xerxes is 188,000 lines of Java!), but I don't want those. Numerical libraries seem bad. So what is the library that might convince me to use Java for something?

No, they aren't very good. I think the problem is cultural. Programming Java gets you comfortable with extreme verbosity and tons of structure so its libraries end up like this: http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server... (In extreme cases.)

Lucene was mentioned earlier - it, at least, is very good.

I have the same impression about the numerical computation and machine learning libs too.

Re: Why MIT switched from Scheme to Python

#105

Post by jules »

scott_s wrote: post #88
jules wrote: post #83

Earlier quoted context omitted.

The problem is not that you can't do this in Python, but that this is out of place in a Python course (you don't use linked lists in Python, for example). SICP shows that you need only a very small number of primitives to get a full programming language. You don't get this elegance with Python. This may not be important if you teach programming to people who want use programming languages, but it is important for peo…

Keep in mind this is a freshmen level course. You don't have to - and shouldn't - cram every important CS concept into an intro course.

I agree. And this course probably is a lot better than the course I got (C++, ugh). That may be the reason I'm biased...

Re: Why MIT switched from Scheme to Python

#106

Post by Kaizyn »

jerf wrote: post #17
abstractbill wrote: post #16

Earlier quoted context omitted.

But the above examples are taken straight from SICP. Wasn't that the textbook for 6.001 before they switched to Python?

Which sort of wanders back around to begging the question; is that still the best way to start teaching, as Sussman talks about? I ask myself, "how would I teach my son to program?", and for all my copious academic and practical experience, "start with re-implementing car and cdr from lambda functions" isn't even remotely in the running. Sure, I'd introduce such things earlier than most people and SICP is still firml…

6.001 presumed the students had prior exposure to college physics and calculus mathematics. If your son has this level of foundational knowledge, then SICP probably would be the most efficient way to bring someone up to speed on programming. If they have not attained that level of education, then this isn't the best intro point to computer science. Predicate logic and set theory is probably a better starting point. Or if you're feeling particularly cruel, Java. :-)

Re: Why MIT switched from Scheme to Python

#107

Post by Kaizyn »

sharkbrainguy wrote: post #51
jules wrote: post #10

Earlier quoted context omitted.

> If you can convey 95% of the basic ideas in Python But you cannot. Some of the ideas in SICP can nearly be conveyed in Python (like lexical scoping, closures, data types, streams). You'll use built-in language features in Python (classes, generators) instead of implementing the functionality. I think that implementing these things is important if you want to really understand them. An example, cons, car and cdr fro…

def cons(a, b): return lambda f: f(a, b) def car(p): return p(lambda a,b: a) def cdr(p): return p(lambda a,b: b) As well as in theory you can do this in practice. It's about as elegant (hard for me to judge as I have a strong pro-lisp bias). Aside from lack of tail safety and performance issues with writing scheme-ish code I don't see why you couldn't implement those things in Python. The main difference is that typi…

Your definitions do not work.

  foo = (1,2,3)
  bar = (4,5,6)

  print cons(foo, bar)
  print car(foo)
console output:

   at 0x00B3F430>
  Traceback (most recent call last):
    File "./test.py", line 14, in 
      print car(foo)
    File "./test.py", line 5, in car
      return p(lambda a,b: a)
  TypeError: 'tuple' object is not callable

Re: Why MIT switched from Scheme to Python

#108

Post by danprager »

Kaizyn wrote: post #107
sharkbrainguy wrote: post #51

Earlier quoted context omitted.

def cons(a, b): return lambda f: f(a, b) def car(p): return p(lambda a,b: a) def cdr(p): return p(lambda a,b: b) As well as in theory you can do this in practice. It's about as elegant (hard for me to judge as I have a strong pro-lisp bias). Aside from lack of tail safety and performance issues with writing scheme-ish code I don't see why you couldn't implement those things in Python. The main difference is that typi…

Your definitions do not work. foo = (1,2,3) bar = (4,5,6) print cons(foo, bar) print car(foo) console output: at 0x00B3F430> Traceback (most recent call last): File "./test.py", line 14, in print car(foo) File "./test.py", line 5, in car return p(lambda a,b: a) TypeError: 'tuple' object is not callable

They do work; they just don't integrate with the built-in types: Why should they?

Try instead:

  car(cons(1,2)) 
    -> 1

  cdr(cons(1,2)) 
    -> 2

  car(cons('a', cons(2, 3))) 
    -> 'a'

Re: Why MIT switched from Scheme to Python

#109

Post by abecedarius »

scott_s wrote: post #102
abecedarius wrote: post #101

Earlier quoted context omitted.

You don't have to know the level of nesting; you can add indents afterward just as easily as you can wrap a subexpression in parentheses afterward. def indent(code): return code.replace('\n', '\n ')

In my current project, I've implemented a source-to-source compiler. In the places where I emit C code, I usually don't have a handle to the scopes above me. I could get one, but it would take more work. The code I generate has no indents and no newlines. Not having to keep track of these makes life simpler. To make my generated code more legible, I just run indent on it.

I've written C code emitters too. FWIW, I've found nicely-indented output templates help to keep the source code of the emitter clear (and with no need to get at the enclosing scopes). But the question you raised was whether indentation-only was harder to generate, and I'd say no, because code.replace('\n', '\n ') is as simple as '{' + code + '}', if slightly slower.

Re: Why MIT switched from Scheme to Python

#110

Post by danbmil99 »

palish wrote: post #44
tlb wrote: post #41

Earlier quoted context omitted.

My point was there's no single 'gl.Vertex3' call that takes native Lisp numbers. Thinking about double/float/int/short should be abstracted out below the Lisp level. We use OpenGL to show real-time renderings of the robot, derived from the gyros and joint angle sensors. We have an analysis tool that shows, either in real time or post-run analysis, renderings synchronized with high-speed video of the robot and scrolli…

Ah. Very cool. Are you computing center of mass / moment of inertia yourself, or using a 3rd party library to do it? PhysX is free, and I believe it can do those calculations for you fairly automatically. (In PhysX, a 'scene' is composed of 'actors', and each actor is described by a set of shape descriptors. A shape descriptor can represent a box, a sphere, a capsule, a convex hull, etc. So a laptop actor could crude…

"You also might have better luck running dynamics simulations with PhysX than with ODE." I worked on the simulator at Anybots, and I'm pretty much convinced a different physics engine isn't going to magically make things better (in terms of using simulations to predict real robot behavior). The problem is more about getting every little physical detail of the actual robot -- and its interactions with the environment -- into the model. The particulars of how collision, joint constraints, and dynamics are numerically computed isn't what makes the problem really hard.
Post reply on HN