Lambda the Ultimate

I presume the idea with taking a focus on robotics is to expose students right from the beginning to ideas like concurrency, distribution and real-time response. That sounds like a good idea to me. Using Python, not so much, though.

While programmers are still trying to get basic concepts like looping and subprograms down, we're trying to shove seriously tricky concepts like concurrency, distribution, and real-time response at them. Because, dammit, learning to program is simply not difficult enough!

This isn't to say those aren't important concepts, and should be taught- just that they shouldn't be taught first.

While programmers are still trying to get basic concepts like looping and subprograms down

Presumably, if you've made it into MIT, you shouldn't have too much of a problem figuring out looping and subprograms. Many freshmen would have long since passed that stage at high school or on their own.

Here's another quote from the article which hints at what they're aiming for:

Faculty from both courses stress that neither will just be a survey course. They will “be in the Course VI tradition of ‘barely-doable,’”

It's not as though there's a shortage of schools that cater to less capable students.

Many freshmen would have long since passed that stage at high school or on their own.

Yes, but many wouldn't. MIT prides itself on being able to cater to smart but totally inexperienced freshmen.

One of the nice things about the use of Scheme was that it was a great leveller. Sure, there were 1 or 2 students each year who had seen it before, but for the most part using Scheme put everybody into the same boat of learning a new language.

A new language can be useful for the "more prepared" students, as well. I had been programming in various languages for over ten years by the time I took 6.001, and if it had been a review of, say, Pascal, I probably wouldn't have paid as close attention. Scheme sure frustrated me at times, but it made me think about programming in brand new ways, which was one of the points of the course.

Also, don't believe the article when it talks about how this whole thing is just "an experiment." A not-so-great MIT tradition is for the administration to decide on a change, and win buy-in by announcing that it's only "a multi-year experiment." Well, in 3 years there's been huge turnover among the students and no one really remembers that the whole thing was only a trial run.

My point in the grandparent comment was not to defend the choice of Python, but rather to defend the tackling of a problem such as mobile robots at that level. Even for MIT students that haven't previously been exposed to programming, loops and "subprograms" should not be a problem.

I don't know enough about what's going on at MIT to critique the choice of Python in the context of a course like C1. I once did a course project which involved writing a program in HP Basic to control a microscope to scan a rock sample. The choice of language was hardly relevant in that case (and besides, in many ways, Python is the new Basic). The C1 situation sounds somewhat similar, and supposedly it isn't intended as a direct replacement for 6.001.

I guess it makes some sense to me. Anyone using computers for anything is well-served by knowing at least one scripting language (pace, terminology warriors), so it's not bad to put one in the curriculum at some point. I see Perl and Python in this niche, with Ruby also entering as the various shell languages leave. O'Caml and Bigloo Scheme are close, but I've tried to use them for this sort of thing before and always given up. Given these 2-3 choices, Python is probably the cleanest. We're using it in a PL course here (along with ML and Prolog), and the students seem to pick it up quickly.

Python learned some things from Lisp, like first-class functions and other nieceties I wouldn't want to miss out. It also suports multiple paradigms to some extent and has a rather huge user base.

I've added SICP chapter #1 in Python to the list of other languages. Since you seem to be a python advocate, perhaps you can explain exercise 1.1 (if can not be used as an expression) and section 1.3.2 (the lack of let bindings). :-)

Python 2.5 (the current version) does has an if expression form:

def abs(x): 
    return -x if (x<0) else x

A fairly Pythonic (as we say) way to translate the let construct is to use default argument values:

x = 2
def plambda(x=3,y=x+2):
    return x*y
print plambda()

or, in this case, simply

print (lambda x=3,y=x+2: x*y)()

But it's certainly true that the statement/expression distinction and the absence of anonymous functions do make some functional programming constructs more unwieldy.

Downloaded the latest version and made changes to the python code to reflect the two suggestions you made.

Good idea to add this translation, I've got only some minor objections: Wouldn't it be better to adjust the code more to the coding style thet most pythoneers use, the PEP8? I do see the point of keeping the code short to be more comparable with the original Scheme code but it should be thought of.

Apart from the other comment on indentation style, in 1.1.7 the use of float(x) in the definitions of average and improve looks to be too limiting. I have not read the book, but if writing Python code i would use plain x instead of float(x) in those functions.
Scanning a little further ahead, it seems there may be other places where float is used too often (although its use in the definition of sqrt may be what is wanted). - Paddy.

The value is divided (/) by a float (2.0) so the coercion is automatic. But I consider the problem of the overloaded division operator to be an open PL problem. Should it follow a set of rules for automatic casting (int/int=>int int/float=>float;) like Python, Ruby, JavaScript? Or should int/float be a type error like in ML and Oz? Or should the result of divide always be a floating point number like Haskell?

Anyhow, I usually get a little carried away with the forced coercion whenever I deal with languages that follow the first path. It effectively intersperses some type control. Not always necessary to be explicit, but sometimes I dislike having to play compiler in my head.

Note that in a future version of Python this will also be the case, on the rational that 1/3 = 0 is highly surprising to non-programmers..

Using the statement

from __future__ import division

on top of a script one can import the behaviour you describe right now. The current default behaviour is reproduced by floor division with the doubleslash operator // assigned to it. So one has:

1/3  -> 0.3333333333
1//3 -> 0

To clarify, Python does have anonymous functions - the lambda you just used - but thanks to its indentation-only code layout the lambda form is restricted to only having one expression as its body

The whitespace policy does not suffice to explain why lambdas just contain one expression.

Simple statements like print, raise, assert, assignment, exec and import are statements just like colon separated sequences of expressions or sequences of these simple statements. No one of them does contain a code block and is therefore affected by any whitespace policy. Secondly the whitespace policy doesn't also affect logical line continuations. So you can create arbitrarily large and unwieldy expressions without taking care for any indendation. Whitespace does affect only nested code blocks consisting of many statements not separated by colons.

lambda is really considered as a design wart in Python and its use is not encouraged. It is a somewhat accidental language construct that is a reminder to FP but has only little to do with the motivational base of describing scope and variable bindings using anonymous functions. That lambda is going to stay in Py3K is ought to group pressure by people who like "tiny little functions" as callbacks everywhere.

Translated chapter #1 of SICP to Ruby as well. Seems to trade off one form of weirdness for even more weirdness. No doubt that Ruby has a more capable lambda (though it has its own set of problems with scoping). But at least Python treats named and anonymous functions the same.

Of course, neither language is really centered on the FP domain, so it's probably not a deciding factor one way or the other.

Chris, You had better nix the 'lambda's -- Guido is a lambda hater. ;-)

It's there, it's still used... And it's terrible. Don't get me wrong, it's far better than having something like C for the same set of tasks, but it's like a little joke Lisp in most senses; it was a reduced version of an already minimalist language (XLisp) for early 80's home PCs and the central language has not changed.

Emacs Lisp is both a better demonstration of mainstream Lisp use and dynamic scoping.

I can't say a lot about the central issue. Persecution Complex on my left shoulder says that, probably, sponsors of MIT demanded OO indoctrination and the higher-ups at MIT took minimal damage by choosing Python. There's nothing on my right shoulder, so I'm not really sure how to balance that out.

Except that 6.001 teaches OOP by actually implementing an object oriented system in terms of closures with side effect, teaching the student how C++, Java, smalltalk, etc implement OOP, and rather trivially at that. The student then walks away with a deep understanding of OO because the [rather simple] details have not yet been abstracted away until the student chooses to abstract them away.

6.170, the accompaning lab course, tasks the student with implementing complex OO systems in Java, applying the techniques of OOP *after* they have properly learned what OOP is. So, the OO indoctinisation is still there, but introduced properly.

Scheme is the perfect language for this because it's core forms give enough power to easily implement and abstract away all the breeds of OO (single/multiple inheritence, privatisation of functions and data, interfaces, etc..) without tying the language to a subset of these breeds. The idea is that presumably, after having completed 6.001 (Computer program structure, ie. Basic theory) and 6.170 (Comp Engr. Lab, ie. applied theory) the student will be fully versed in the state of the art to understand all mainstream languages. By using Python, a language where some of the basic concepts taught in 6.001 are abstracted away, the student may not be fully versed in the basic foundational concepts, having skipped a couple steps along the way.

My personal opinion is that, if they want to teach python and applied robotics as an alternative, it should be an alternative to 6.004 (Computation Structure).. the last course in their CS Core. Otherwise, they threaten to leave the student ill prepared for future advances in CS theory.

Disclaimer: I know nothing about MIT's curriculum (except I've read SICP).

Scheme is the perfect language for this because it's core forms give enough power to easily implement and abstract away all the breeds of OO[...]

I would like to agree with this, but I can't.

Starting with FP and adding state and then objects is a great approach, and Scheme is great for that kind of course--a Euclid-style building-up. But when you're done, somehow you've built something that's generally unpleasant to use. It would be nice to end up with something at least as pleasant as, say, Python. Otherwise, the student may have learned some metaprogramming, but she certainly won't have learned OOP.

I like the Euclid approach. But given Scheme as it is, I think learning multiple languages is better than building them all out of any one base language. I wish it were otherwise.

Scheme is still an excellent place to start.

SICP's OO system isn't "easy to use" but it is pretty comprehensive and given a background in SICP, you should be able to feel at home with the OO concepts of any language, by having an understanding of what's going on under the covers... hence why I feel it's a great introduction. Concievably, if you were to use SICP's OO system in a real life scheme program, you would abstract away the ugliness with macros, but introducing that in SICP would probably do more to cloud the concepts and focus the introductory course too much on lisp-isms. IIRC, macros aren't covered at all in SICP or 6.001.

And no, the student would not have learned Object Oriented design and higher OOP concepts from SICP. I think that's outside the scope of the class, and the class covers so much as it is there isn't room to add more. But it is a great background to get the user ready to learn any flavor of OOP.

As for learning multiple languages rather than building everything out of one language, I agree. But not in an introductory course on basic CS. I favor the Euclidean approach to educate the student on all the basic concepts of every language, then the student can move onto more specialized languages to learn mastery of specific paradigms. I can't see any way to squeeze as much information into a single class as SICP is able to do if the student also must learn new syntactic ideas on top of the underlying concepts. It is also no small point that by building everything in a Euclidean approach, the relationships between different concepts is readily apparent, which wouldn't be the case in a multi-language course.

Hence, the course, as it is, is as close to perfection in my mind as you are going to get, as an introductory course. There is no end of debate for the proper course of action for follow up courses. The proposed courses sound to me like they would be an excellent alternative core to be taught with SICP as a prerequisite.

I both used SICP and implemented OOP in Scheme (and then later Prolog in SML) in college. (Not at MIT so I dunno what they do with it.) My own experience is that doing so actually did de-mystify OO along the lines of "oh, virtual function pointer tables make sense" when you look under the covers of C++.

However, IIRC it did not get into the issues of how to architect and design properly with OO as your tool e.g. prefer has-a to is-a to a fault, how functional approaches can be better, etc.

[Implementing Prolog, on the other hand, turned out to be one step beyond the mind-bending-ness most of us in the class could handle in those couple of weeks. I recall the instructor having to throw up his hands and basically give us all the answer to the final homework assignment.]

Given that I've seen textbooks by both professionals (mcconnell, code complete) and professors (reek, pointers on C) that still get tail recursion wrong, I'd say this is wishful thinking at best.

Given that tail recursion is such a small part of what needs to be known to be an effective software engineer (i.e. to design robust software to solve real problems, like controlling our robot overlords), this doesn't seem like much of an objection. Students can do fine without for awhile, and pick it up at their leisure.

Perhaps he's trying to put some pressure onto the R6RS team to get it completed faster?...

Doubtful. The subset of Scheme taught in SICP has not really changed over the last 20 years.

I like Scheme, but am just stating the facts. hopefuly, i'm just doing a "Chicken Little"...

I don't know about that. If anything, the more "obscure" languages like Lisp and Scheme have enjoyed a revival in the last few years due to the widespread appearance of web apps. As pointed out repeatedly by PG in his talks and essays, when you're working on server-based applications like web apps your effective choice of languages is much greater than when you have to deliver apps to the desktop.

R6RS is mostly an attempt to formalize how pure scheme can portably use libraries and such (and clean up a couple trival points along the way). Since 6.001 teaches foundational concepts without libraries, R6RS is inconsequential to the course.

Scheme does not have to be "cool" for 6.001 to do it's job. It could be a completely defunct language and still be ideal for the course. The course deals with recursion vs. iteration, OOP, mutation vs. functional, eager vs. lazy evaluation, and implementation on register machines... many concepts which would be obscured by replacing scheme with a language that abstracts away such things. The point of the course is not to teach "functional programming", but rather to teach "What is functional programming vs. imperative?" Teaching Haskell/OCaml in place of scheme would IMO be just as bad a move as those languages also abstract away too much.

The bit about solving engineering problems, maybe?

(Sorry, but if you serve up a straight line like that, you have to expect someone to take a swing at it...)

Interesting that you brought this up. I have been teaching SICP in Scala at EPFL for 5 years now. I think the course works overall quite OK, and that Scala is well-suited for the subject material. Compared to the original SICP, the course puts somewhat more emphasis on program structuring and modularity. For instance, the famous digital event simulator is factorized into a general simulation class, a digital simulation subclass, user code which inherits from both. Here are the
slides for the course (alas in French).

Some of the course material is also found in the Scala by Example report.

It's great to hear about this. I think that's a really superb idea. I'll take a look at the slides (I hope that my mediocre French and Scala will work well together).

While we are on the subject, it'd be interesting to hear more about your experiences with this course. My feeling about CS1 courses is that teaching software engineering constructs (specifically OOP) in them often misses the point. Students who don't have experience programming rarely understand the point of mechanisms aimed at helping with the software lifecycle in general, and fail to appreciate program readability in particular. They do as they are told, but don't really internalize the ideas they are being taught. I have my ideas about how this situation can be improved, of course, but I am interested to hear what you think.

I teach the SICP in Scala course at EPFL in 2nd year, so I can't comment
first-hand on how beginners would cope with it. Our students had an introduction to programming in Java before, followed by a course on systems programming in C. I don't mind the Java intro, but the prior exposure to C makes it hard for some of the students to go to a higher level of abstraction afterwards. I try to explain recursive data types and they think in pointers and updates ...

How can you not mind the Java?! ;-)

My experience was the opposite, by the way: C is a problem but Java is a curse... Java is a strange mix of high level (e.g., GC) and low level (e.g., references, pervasive state), making it problematic for teaching introductory programming concepts, I think.

I hope you're not counting me amongst the Python bashers. For building real-world applications, and even more for crufting them up in a hurry, Python is one of the best languages out there and bears some advantages over pert-near any Lisp dialect.

But for elucidating the cool deep concepts of computer science that need to be elucidated, you really can't beat Scheme with a bat.

Oh, wait, I'm forgetting about Ruby...

I'm strongly tempted to flame this...

The goal of a first computer science course is to teach algorithmic thinking. As such, whatever language is used should get out of the way as much as possible, producing the clearest and fewest "stupid compiler errors." Whether regular syntax is better than familiar syntax for this purpose or vice versa is an open question.

Why do we start teaching physics with simple, frictionless Newtonian mechanics when it's all just the wave equation? Why do we start teaching math with univariate calculus and simple algebra instead of group theory or something? We do so to teach students the basic habits of physical and mathematical thought. In almost any field, we teach starting from the familiar rather than the "fundamental." Why should computer science be any different?

You obviously get some pleasure from "LISP and the lambda calculus" (though modern Lisp bears little more resemblance to the lambda calculus than a host of other languages), but your predilection is far from universal.

Why do we start teaching math with univariate calculus and simple algebra instead of group theory or something?

The reasons we do that seem similar to me to the reasons to start teaching computation using something similar to the lambda calculus. The symbolic substitution mechanism used in simple algebra is essentially the same one used in lambda calculus -- anyone who's learned simple algebra can quite easily learn the basics of lambda calculus reduction (and IMO, they should).

This seems to support at least part of the grandparent's point. I'd agree that Lisp in the sense of e.g. CL isn't a good concrete language to use to teach this, but either Scheme or one of the more sugary LC-based languages would work. The TeachScheme! project, which is used at high schools as well as colleges, provides some evidence that this approach can succeed.

If "similar" means "side-effect free so that it can be reasoned about by substitution," then I think we more or less agree

The similarities go beyond that. In HtDP, see e.g. Local Definitions and Lexical Scope (which includes Lexical Scope and Block Structure), and Functions are Values. A great deal of other relevant material is embedded throughout the book.

The language used up until section VI of HtDP is a pure CBV lambda calculus enriched in a few standard ways. Although the term "lambda calculus" isn't used, an important part of what students are being taught are the features of a language which has a general approach to lexical scope (i.e. nesting isn't arbitrarily limited) and a general approach to abstraction and values (i.e. even procedures are values). IOW, the features provided by the language are very general, without arbitrary restrictions, and the underlying theory is far simpler than most alternative languages one might choose.

When learning, starting with a simple yet general framework is good, because it allows students to absorb and integrate new concepts without having to throw out what they've already learned. For the features which lambda calculus directly addresses, corresponding core features in other programming languages can mostly be understood as either equivalent to, or more often restrictions on, the general features of the lambda calculus.

But I don't see what's gained in an intro programming course by calling it "based on the lambda calculus" rather than "just like the substitution you used to solve algebra problems."

I don't care what it's called, I'm talking about the features being taught, which go a bit beyond simple algebraic substitution. I was just saying that the similarities to algebraic substitution argue for using a similarly simple yet general approach when teaching programming.

If I had to choose a teaching language in this vein, I might use a restricted Haskell with less-inscrutable type errors.

You mean Helium?

Yes! Thanks for the reminder.

Dan Weinreb's take is also covered in an LtU story. =)