The ground up approach is something like SICP, with fundamentals in lambda calculus or Turing machines. Students learn rules such as how a Lisp evaluates an expression and write programs which apply the rules. It's not necessary that this be taught using Lisp, but it seems to be popular, because it greatly reduces distractions when understanding and writing actual programs. In any case, the ground-up approach generally teaches first a system of rules, and only once the rules are understood does it move on to programs.

The top-down approach, on the other hand, starts with programs. Often the students are given a partially written program and are asked to improve it. The curriculum doesn't focus on rules because they all have exceptions. It's much more like engineering and less like mathematics. As the article says, nowadays "a real engineer is given a big software library, with a 300-page manual that’s full of errors. He’s also given a robot, whose exact behavior is extremely hard to characterize...."

What's better? Some schools (such as my alma mater, Brown) have two intro classes, one for each method of teaching. I chose the rules-based bottom-up approach when I was an undergrad, and it was very good, and I was convinced it was the better way to go.

But I'm losing my conviction, partially because MIT is changing it and they must know what they're doing (heh), and partially because I'm coming to the understanding that everybody uses libraries and this is not going to change. The top-down approach doesn't really provide any sense that there should be libraries, that code should be organized, that you can write to an interface and document your code. People can learn these sorts of things later, though.

This results in: 6.005 ("software engineering") in Java 6.006 (intro to algorithms) in Python 6.034 (intro to AI) in Python 6.035 (compilers) in Java

(6.005 was 6.170 which used Java and 6.035 has always used Java afaik so this list isn't all the new curriculum's fault... but it does give a good overview of MIT's undergrad CS decline)

Frankly, this is unacceptable. I'm not sure I would hire an MIT CS grad that did the new curriculum. It is absolutely absurd that MIT (which purports to have one of the best CS programs in the world) is teaching Java and Python in their undergrad CS curriculum even in places where Java and Python are not the best suited (compilers!? algorithms!? AI!?). For instance, one 6.005 pset is to build a Sudoku solver... in Java. Every MIT undergrad should have the ability to learn a new programming language. 6-3 students (CS majors) should especially be able to do this. MIT is getting watered down.

Students don't learn other programming paradigms and they learn to accept the bloat and poor design decisions of the required languages. Where once students would build a text adventure and a metacircular evaluator in Scheme for 6.001, they now build what amount to Lego Mindstorms kits. Seriously?

Naturally some people were very upset about this, but it definitely made for a better program all in all.

Upper level courses would then expect students to pick up Verilog/VHDL, regular C, assembly, lex/yacc, Scheme/Lisp, Java and Perl/Python as needed.

Of course, if they had been languages in a different paradigm, (e.g., Scheme, Prolog) it may have taken me a bit more time to get going. Still, no reason to not use these languages.

Any computer science student should be able to learn a new language quickly to get a project done. It's an important practical skill for their careers anyway.

While I understand the fondness many people feel for Scheme, building an entire CS curriculum around it strikes me as particularly problematic. Scheme and Scheme's approach to programming can, I'm sure, be useful as one part of a larger curriculum, but more often it feels as if I'm talking to someone who, say, learned how to take a derivative via limits, and then decided that it would be all right never to learn anything more about calculus in the course of a mathematics degree. By analogy, building a REPL given only a small set of atomic language bits to start with simply is not the totality of either theoretical or applied computer science, and should not be pushed as such.

Perhaps we have misunderstood each other. I'm not pushing Scheme or the metacircular evaluator as the totality of theoretical or applied computer science. My interest is entirely in the educational value of building a REPL versus, say, a robotic control system. MIT has a lot of robotics opportunities from clubs to IAP (winter term) competitions to UROPs (undergrad research). MIT doesn't have a lot of REPL building opportunities.

In fact, I believe it is possible with the new curriculum to graduate from MIT with a degree in CS and have never built a REPL or a compiler. That seems a little... misguided.

I don't rail against this change because I mourn Scheme or hate Python. I rail against this change because I feel it fundamentally weakens the quality of an MIT CS education.

This simply is not a useful approach. And, honestly, as a working programmer there are lots of things that aren't compilers or REPLs that I can think of, all of which would be at least as useful for students to have experience with, and none of which are, so far as I know, part of MIT's or anyone else's curriculum.

But I manage to live with that, rather than demanding that MIT build a curriculum around what I happen to think is important.

(and, honestly? I still feel like Scheme is the derivatives-by-limits approach to programming -- yeah, you can do it that way your whole life, but that doesn't mean you should)

Hasn't this been the case since at least 1999?

It seems a much more grown up and civilized approach to me. Maybe this is because it is graduate level and not undergrad? I remember CMU undergrad classes requiring C, Scheme, Prolog, and Pascal, but that was over 20 years ago.

There are constant opportunities within the MIT curriculum to learn other languages, and while I had the pleasure of taking 6.001, frankly - if an undergrad doesn't take advantage of any of those opportunities and leaves college only having used Python and Java, that's their flaw - not the Institute's.

Finally - to play devil's advocate in response to the REPL / compiler argument, of all of the assignments in 6.001, writing the metacircular evaluator gave me the least accurate representation of the power of computer programming as a whole. While it was an interesting exercise, if I had been interested in language design, I could have taken an elective more focused on the topic - as is still an option at the Institute.

I think your claims about the tragic decline of the quality of an MIT CS education are a bit dramatic - few MIT students seriously considering a career in computer science graduate as lopsided as you seem to believe. Your efforts may be better spent railing against why 40% of all undergrads graduate to take jobs in finance and consulting, despite the vast majority of students graduating with engineering degrees. (Source: http://web.mit.edu/career/www/infostats/graduation.html)

ubernostrum - a point of clarification, the "entire CS curriculum" was never built around Scheme. 6.034 was the only class that used Scheme after 6.001. I believe a graduate class existed in the recent past that also focused on Scheme and its interesting properties as a language.

I want to know where Lisp, ML, Prolog, and Smalltalk are. I'm particularly concerned about Lisp and ML (incl. Haskell and ML derivs). Does MIT just not care about FP any more?

If you're a CS student and you haven't seriously worked with functional languages by the time you graduate, something is wrong. There is nothing to prevent this now. Many students will not seek out these languages on their own but it is decidedly in their best interest to acquire experience with them and MIT, to produce 'well-rounded' computer science graduates, should require/encourage it.

I was going to make a snide comment wondering why Scheme was necessary for training future investment bankers and lawyers, but I just had anecdotal experience and didn't want to spread false information. Thanks for the numbers.

(Through chance I was a TA at MIT at the turn of the millennium. Pretty much everyone I taught had plans of working on wall street or going to law school.)

I want to know what line of work you are in where being an MIT grad is considered a drawback.

My own feeling is something like this. Before Newton there was Kepler. Now Kepler was no dummy and he used the exacting measurements of Tycho Brahe to arrive at a very accurate model of planetary motion. He found that planets traveled in ellipses not circles, and he knew that they swept out equal areas in equal times (among other things). In short, he had a very firm "top-down" grasp on what planets did.

Then along came Newton, a "bottom-up" thinker if there ever was one (calculus was invented in what was perhaps the most supreme feat of yak shaving ever http://catb.org/jargon/html/Y/yak-shaving.html ). He found that there was an underlying and unifying idea, gravity, that explained why the planets behave as they do.

So to cap off my analogy, I've found that if I've worked in a sufficiently bottom-up way on something then sometimes what seems complex or intricate collapses down into some small and elegant solution that I wouldn't have seen if I were coming from the other direction (or at least it would be much more difficult).

I have observed that for great hackers, it doesn't matter what method they are taught -- they'll learn both and apply them appropriately. This was probably true for Newton. It's certainly true for one of my best friends, an excellent hacker, who is as much a bottom-up thinker as anyone could ask for and yet he took the top-down class. He was going to learn how to think about problems in the optimal way no matter how, or what, anyone taught him.

I'm not sure what this means for how the intro course should be taught. Certainly it seems to suggest you won't be ruining anyone with great potential by teaching them the wrong stuff. So maybe MIT has realized that it doesn't matter for the best students, and they've been doing the same thing for 30 years and it's time for a change. What the hell. See how it works, and then maybe change back or learn something new. They're going to have to run this experiment for a long time, though, in order to figure out whether it's actually better. I'm quite interested to watch.

Luckily, I took all old-curriculum classes. If I were a student entering college for CS now, I would not choose MIT. I don't know other schools' curricula in depth but some place has got to be more rigorous (Berkeley? Stanford? CMU?).

The argument is that computer scientists rely more on existing libraries and systems that often require fundamental research for an individual to comprehend. They have changed the course to reflect this using robotics and a library to control the robots. That library happens to be written in Python. They didn't start with "Let's change to using Python" and develop the course around that.

The validity of this argument is debatable. But I don't think your reasons address it at all.

Python's a great language, don't get me wrong but you're being misled if you think that popularity and marketability were not factors in selecting Python for the new course 6 curriculum.

As for the argument that "computer science has fundamentally changed", I agree. Unfortunately, what is really meant is that software engineering has changed. You can learn computer science concepts just as well with Scheme or Python or Smalltalk or OCaml...

Additionally, while library use may be more prevalent in industry now, that's no pedagogical argument for teaching "library use" (whatever that is).

Library use is relatively easy. Reading docs is hard for a lot of people but learning to read docs can be done with systems or languages instead of libraries.

It all boils down to what will serve the students best and what will let MIT deliver the most value. Students can learn python and library use on their own relatively easily. Fundamentally understanding recursion, abstraction, complexity, scoping, FP, OO, and other more abstract topics is considerably harder working alone. 6.01 claims to still cover these topics. 6.01 claims to integrate them with EE and robots to make the class fun.

From the conversations I've had with 6.001 students and 6.01 students, 6.001 does a much better job with these topics. 6.01 can and will improve, of course. Unfortunately, I don't think teaching about robots in Python will give students as solid a grounding as SICP.

MIT's new course 6 curriculum falls along similar lines as the 8.01/8.02 (intro mechanics and e&m) move to TEAL (a bastardized blend of game show and "hands-on" computer work that feels like high school). See http://tech.mit.edu/search.html?cx=000823599697007823270%3Aq... for how TEAL has been doing.

Would Caltech do this? No. So why is MIT?

Reading SICP on my own time helped me understand these topics better, and helped me understand some things about Java better (like how anonymous inner classes are a half-assed, broken attempt at implementing closures). SICP makes sense of these topics in a way that I doubt is even possible in a class taught in Java. You can probably cover a lot of this material with Python, but still run into more limitations and inconsistencies than with Scheme.

6.006 does Python, but it's new and 6.046 had no practical edge to it at all. As a student who had a little bit of difficulty with the theoretical steps in 046, I can understand why they added the "test this and prove to yourself that this makes sense" exercises in Python.

As lame as it sounds, look into 6.00 - it's an "intro intro" programming class mostly required for Course 20 (Biological Engineering) students, but it's surprisingly robust as an introductory class - covering a lot of the topics you just listed, and well.

I've helped a number of people with their 6.00 work and read quite a bit of the course material and I have to respectfully disagree. Students in 6.00 don't learn anywhere near what was taught in 6.001.

Note that I said, with added emphasis, "the practice of computer science has fundamentally changed." This idea rings true for me, as a systems researcher. I have to do as they describe to do my own research. "Library use is relatively easy" greatly underestimates the difficulty of accomplishing non-trivial tasks with new hardware, even in the presence of published specs and available library.

Also, answering your own rhetorical question even though you don't actually know the answer is not support for your argument.

"Library use is relatively easy" is not true for all cases; you are correct. 6.01 uses libraries which are well-built and relatively friendly. This is the first 6 class students take, after all. Classes later in the curriculum will have students using libraries of their own selection or writing compilers or operating systems for modern processors (should the student choose to take those courses). Between teaching fundamental concepts and teaching how to use a library, concepts should win out in introductory courses. Whatever skill it takes to use a library or documented system will be learned in time.

I don't absolutely know the answer to whether Caltech would do something similar but I would wager a great deal that they wouldn't. Have you looked at Caltech's required courses? Talked to Caltech students? Looked at MIT's required courses? Talked to MIT students? If you do, you will notice a very clear trend. Although MIT and Caltech are ostensibly peer institutions, the last two decades have seen a marked (relative) decline in the intensity and rigor of MIT's undergraduate programs.

I did my undergrad at Georgetown, where nearly every class used C++ (or C, for classes in things like OS and security).

6.945 (Large-scale Symbolic Systems) is an excellent class. Afaik, it's still taught in Scheme by Sussman.

All these classes cover quite a bit of material in not-very-much time. They don't get bogged down by whatever language they use (if any) and they straightforwardly teach fundamental concepts in some depth. They have high throughput.

A lot of the charm of academia, to me, is that it gives you some breathing room to step back from the mess, and look for unifying principles. There might be a bit of a shock when the student first graduates, but in the long term they're often better off with the kind of knowledge that they couldn't easily pick up through osmosis.

The strengths of the old curriculum were the concepts you learned through 6.001 and using Scheme, not the Scheme skills themselves. Do I think 6.034 would be significantly different if I had to use Python versus Scheme? Not at all - and frankly using Scheme added nothing to my experience in that class.

I had a different experience in 6.034 than you did, I suppose. I think Scheme suited the class well and offered a nice way to express searches, minimizations, and decision systems. I'm sure you can do everything you can do in Scheme in Python but you could also do it in Java. Functional languages are particularly well-suited to these tasks. I wouldn't necessarily pick Scheme, though. Why not use the most appropriate tool for the job? If students have to learn a new language, OK. If you really do think Python is the best tool, OK.

At the end of the day, the department won't make the student great. To a degree, a driven and talented student can succeed anywhere, regardless of how many ooh's and aah's a name-dropping of their school will produce.

Also, Python is a much more practical choice than Scheme, and has technical merits which are at least as attractive as Scheme, and arguably more so. Scheme is elegant. But Python is also elegant, yet more practical. From that angle, looks like a net change for the better.

MIT also strikes me as a school oriented more towards producing engineers rather than programmers. And if you're going to school at MIT just to get into a career in programming, that sounds like a terrible waste of money. Robotics or electrical engineering? Probably a good choice. But programming? Come on.

Then there's the whole argument of why anybody needs to go to MIT, or even get a college education in CS. We live in a world with the Internet and scads of free books in libraries and documentation online. Follow that line of thinking and the whole controversy over this tweak in some random school's class content seems silly. It is as if nobody can learn anything outside of a class, so if it is not taught in that particular class at MIT, it will never be learned, and the world will end. Hilarious. :)

Also the comments on this story are always of the type "Well when I was in school things were taught right. The day I graduated it all started going downhill and now I wouldn't hire someone graduating from that school."

http://mitpress.mit.edu/catalog/browse/browse.asp?btype=2

These are the latest releases from MIT press. Among them you will find nothing remotely like SICP, but plenty of postmodernist/related pablum.

"You have to do basic science on your libraries to see how they work, trying out different inputs and seeing how the code reacts." Is this not an atrocity, to be fought to the last bullet? Is this not an argument for declaring all existing software obsolete and starting from scratch? Why are we - even luminaries like Sussman - so willing to give up on the future without a fight?

As argued in some of PG's essays, in order for creativity to bear fruit it is not enough for a given individual to possess a creative mind. The culture has to be hospitable to creativity. And there are processes which come close to stamping out creativity without any overt or deliberate suppression involved. Specifically, a transition to a medium where one cannot get reliable, understandable "small parts" having predictable behavior.

Take note: http://xkcd.com/298/

Programmers have indeed created a universe where "science doesn't work." Learning where the permanent bugs and workarounds are inside a phonebook-length API teaches you nothing. It is anti-knowledge. Where your mind could have instead held something lastingly useful or truly beautiful, there is now garbage.

There is no longer a "what you see is all there is" Commodore 64 for kids to play with:

http://www.loper-os.org/?p=16

No one is working on, or sees the need for a replacement. This is just as well, considering as one would have to start from bare silicon - and avoid the use of design tools built on the decaying crud of the past. Only a raving lunatic would dare contemplate it... Outside of programming: Linus Pauling developed an interest in chemistry by experimenting incessantly throughout his childhood. Today, he would have been imprisoned:

http://memepunks.blogspot.com/2006/06/americas-war-on-scienc....

The new generation will have no Linus Pauling, unless the Third World - where one might still purchase a beaker without a license - supplies us with one. Likewise, we will see very few truly creative programmers. What creativity can there be when your medium is shit mixed with sawdust?

There is a strong religious backing to Scheme being the only way to teach core CS fundamentals at MIT. I think that is an emotional almost fanboy reaction at times probably filled with heavy bias.

Python is a great balance of showing many sides of programming, it can be as eye opening as Lisp. Python is functional and object-oriented. Python is a simplifying tool and culture. All platforms used here should be simplifying.

Python can get you building market ready desktop applications, web applications, building robotics, scientific computing, game development, algorithms and AI and nearly anything out there Python is at the tip of the spear. Python is rapid iterations and prototype friendly. The frameworks of Python are more capable to wrap nearly anything, that is what software engineering is about now. It is the same evolution software process has taken from the CMM, to CMMI (supporting modular and libraries), to Agile and a more natural iterative process rather than top down design everything from the bottom up approach. You can still do that, it is just not the majority of software engineering today, and it will continue to simplify.

Are Scheme and Lisp programmers who are biased because they had that more hardcore bottom up technique really thinking this degrades the experience or is this more of a bias that is being attacked. Or has software engineering fundamentally changed?

Scheme will not go away. This does not mean that people will stop making compilers or REPL. It simply means the starting place is different. It might even drive some better compilers and multi-platform tools because of the quirkiness of many compiler systems out there will drive good engineeers to simplify that process.

That is what we do, we simplify problems.

I would argue Python makes for more marketable and capable graduates to be successful almost immediately after school, but I don't think it harms the fundamentals much. Good developers and engineers still take time to get better. No one is the best programmer in college, it takes time and experiences after the academics to be highly skilled. Python fits closely with computer science and is very capable of taking the torch.

I do think that there is a benefit to learning from a more difficult and core understanding because it is more downhill from there but Python is hardly the worst case scenario here.

I think that Python is perfect for teaching CS because of the flexibility, libraries, open source but support by Google (they are big on CS and like Python) and many other reasons.

What can you make in Scheme that you can't make in Python, very little.

Would you rather it be Java or C# they are teaching?

Because we know what it is like to work in a medium that can be understood, behaves correctly, isn't peppered with inconsistencies, and does not force you to clutter your brain with pointless trivia. Call that bias if you will.

> the quirkiness of many compiler systems out there will drive good engineeers to simplify that process

There is no evidence that this is happening or will ever happen. Almost everyone shuts up, bends over, and spreads wide to accept whatever level of pointless complexity the system they are forced to work with has. Programming systems are continuously growing more Byzantine and idiotically laden with accidental complexity as feature is piled on top of feature. This is how we got Python, C++, Java, C#, et al.

So, when teaching, you always need to bring the simple and perfect theory.

Practice is what your students will make out of your 'perfect' theory -- slumming down quite a bit -- but if you start with bringing a 'practical' theory to begin with, your students will never learn to fly high (bringing in some really fresh new ideas).