Live data from Hacker News

Programming by poking: why MIT stopped teaching SICP

posteriorscience.net

121–130 of 245 posts

Re: Programming by poking: why MIT stopped teaching SICP

#121
post #79

Earlier quoted context omitted.

> even 4 whole years isn't enough to learn "all the fundamentals" No. You are missing the point. The fundamentals are very simple and easy to learn. That's what makes them "fundamental." It's all the random shit invented by people who didn't understand the fundamentals (or chose not to apply them) that takes a long time to learn.

I disagree. The field has exploded. It's becoming more and more difficult to take vertical slices of every sub-field. What should we consider fundamental? Programming languages, automata theory, set theory, compilers, assembly language programming, microprocessors and system architecture, algorithms, graph theory, category theory, artificial intelligence, machine learning, operating system, parallel and distributed p…

There is the actual complexity, and then there is the accidental complexity lamented by the poster to whom you responded to. I would claim both are a thing. Especially in projects where the true complexity is not that great and the theoretical basis of the solution is not that well documented people have a tendency to create these onion layered monstrosities (the mudball effect).

If we look just traditional CRUD-kin (i.e. database, view, domain logic) programs these seem to be the most in danger of becoming a mudballs. Which is really strange, given that they are the oldest types of programs out there and closely mimic the second use computers came used for (accounting) just after military applications.

Re: Programming by poking: why MIT stopped teaching SICP

#122
post #99
post #47

Earlier quoted context omitted.

Which class/university was it? Any chance the materials are online? I'm actually writing my own shell now; I'd be interested to compare :) The fork/exec/pipe/dup calls are definitely an unusual and powerful paradigm. I think too many programmers don't know this because we were brainwashed to make "portable" programs, and that's the least portable part of Unix.

CS61 at Harvard covers that stuff, building your own shell (and memory management, etc) in C and it's an introductory class. There is a lot of hand holding of course but I really loved that class.

Thanks! Found it: http://cs61.seas.harvard.edu/wiki/2015/Shell

This looks pretty comprehensive for an undergrad project actually... they have a grammar and everything, with pipes and redirects, which are definitely the most Unix-y concepts. And they talk about interrupts, although no user-defined signal handlers or anything.

FWIW I ported the POSIX shell grammar to ANTLR, though I'm writing it in C++ (and prototyping the architecture in Python). ANTLR is actually incapable of expressing the lexer AFAICT...

http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3...

Re: Programming by poking: why MIT stopped teaching SICP

#123
post #75

Did SICP at Berkeley. Really awesome course. Thanks MIT for not teaching it anymore. Makes me a better programmer than your new grads now. Hah!

It doesn't, is the point that the folks who came up with SICP are trying to make.

My point is that it DOES. My single statement assertion was making that implicit assertion...

Re: Programming by poking: why MIT stopped teaching SICP

#124
post #75

Earlier quoted context omitted.

It doesn't, is the point that the folks who came up with SICP are trying to make.

My point is that it DOES. My single statement assertion was making that implicit assertion...

Why do you think you know more than they do about this?

Re: Programming by poking: why MIT stopped teaching SICP

#125
post #108
post #97

Earlier quoted context omitted.

It may have been that it just took 7 years to actually get a new course in place, but it wasn't until fall 2007 that MIT officially got rid of 6.001 as required course, well after the dot com crash. There were a TON of changes that happened with the MIT EECS curriculum at that time, so perhaps it was a holistic response to the dot com crash that was beyond just 6.001.

I think "panicked spasm" is more accurate than "holistic response", at least in connotation, but as I recall the only real changes were in what was required, terminating the use of Scheme in the entire required curriculum with extreme prejudice, and adding, what, 6.005? Where they claimed to teach most of what was in 6.001/SICP, but using Java, a language which is "not even wrong" for that purpose. Yeah, MIT has beco…

> And just when the failure of Dennard scaling was making functional programming a lot more important.

Yep, there's the real irony. Having functional programming skills and experience is a real asset in today's job market, I've found.

Re: Programming by poking: why MIT stopped teaching SICP

#126
post #115
post #75

Earlier quoted context omitted.

It doesn't, is the point that the folks who came up with SICP are trying to make.

Well the real issue is defining what's better. And the worry some of us have is this new trend of grappling with increased complexity seems short-sighted; we don't like the direction it's going. As much as Sussman shows understanding of the current situation, what he's saying is also a criticism--doing this sort of ad hoc "science by poking but not really science" is the heart of the issue. And what's interesting is…

It's hard to argue with productive results, however. If this "poking" results in valuable engineering more than SICP does, then "poking" needs to at least be seriously looked at and understood, if not outright taught to the next generation of software engineers.

The real problem, I think we can all agree, is the lack of widespread specialization of degree programs. Computer Science is still the blanket degree everyone gets, when in reality, some kind of trade program is likely sufficient to train many of today's "developers" (the "pokers").

Re: Programming by poking: why MIT stopped teaching SICP

#127
post #79

Earlier quoted context omitted.

> even 4 whole years isn't enough to learn "all the fundamentals" No. You are missing the point. The fundamentals are very simple and easy to learn. That's what makes them "fundamental." It's all the random shit invented by people who didn't understand the fundamentals (or chose not to apply them) that takes a long time to learn.

I disagree. The field has exploded. It's becoming more and more difficult to take vertical slices of every sub-field. What should we consider fundamental? Programming languages, automata theory, set theory, compilers, assembly language programming, microprocessors and system architecture, algorithms, graph theory, category theory, artificial intelligence, machine learning, operating system, parallel and distributed p…

> What should we consider fundamental?

A fair question, and a full answer would be too long for a comment (though it would fit in a blog post, which I'll go ahead and write now since this seems to be an issue). But I'll take a whack at the TL;DR version here.

AI, ML, and NLP and web design are application areas, not fundamentals. (You didn't list computer graphics, computer vision, robotics, embedded systems -- all applications, not fundamentals.)

You can cover all the set theory and graph theory you need in a day. Most people get this in high school. The stuff you need is just not that complicated. You can safely skip category theory.

What you do need is some amount of time spent on the idea that computer programs are mathematical objects which can be reasoned about mathematically. This is the part that the vast majority of people are missing nowadays, and it can be a little tricky to wrap your brain around at first. You need to understand what a fixed point is and why it matters.

You need automata theory, but again, the basics are really not that complicated. You need to know about Turing-completeness, and that in addition to Turing machines there are PDAs and FSAs. You need to know that TMs can do things that PDAs can't (like parse context-sensitive grammars), and that PDAs can to things that FSAs can't (like parse context-free grammars) and that FSAs can parse regular expressions, and that's all they can do.

You need some programming language theory. You need to know what a binding is, and that there are two types of bindings that matter: lexical and dynamic. You need to know what an environment is (a mapping between names and bindings) and how environments are chained. You need to know how evaluation and compilation are related, and the role that environments play in both processes. You need to know the difference between static and dynamic typing. You need to know how to compile a high-level language down to an RTL.

For operating systems, you need to know what a process is, what a thread is, some of the ways in which parallel processes lead to problems, and some of the mechanisms for dealing with those problems, including the fact that some of those mechanisms require hardware support (e.g. atomic test-and-set instructions).

You need a few basic data structures. Mainly what you need is to understand that what data structures are really all about is making associative maps that are more efficient for certain operations under certain circumstances.

You need a little bit of database knowledge. Again, what you really need to know is that what databases are really all about is dealing with the architectural differences between RAM and non-volatile storage, and that a lot of these are going away now that these architectural differences are starting to disappear.

That's really about it.

Re: Programming by poking: why MIT stopped teaching SICP

#128

I really wish SICP had been a 2nd year course (with a requisite increase in difficulty) instead of my very first course in the EECS department. Not having had a ton of background in programming beforehand, I feel that a lot of what SICP has to offer was lost on me to some degree due my not appreciating it at the time. I suppose the same could probably be said for any intro course or just college in general...

When 6.001 was introduced, a surprisingly large number, perhaps a majority, of MIT students arrived without having leaned how to program. SCIP was their first exposure to programming.

That's inconceivable to me now.

Re: Programming by poking: why MIT stopped teaching SICP

#129
post #114

Some day we will recognize that some areas of "programming" are very different and require different skill sets, and eventually different titles. We tend to call everything "software engineering" so that everybody can feel proud of such a title ("I'm an engineer"), but engineering is certainly not about figuring out how to vertically center divs with CSS (and it's also not about proving algebra theorems either -- eve…

Software Engineering is more about methodically solving software problems than it is about which problems are being solved. A web developer who writes rigorous formal tests for a new page is engineering just as hard as an embedded developer writing rigorous acceptance tests for a board-support package. The engineering comes from the rigor and the fact that there is a controlled process for how software features get i…

I agree with that. The engineering process can be applied on every type of problem.

Yet, for that specific web dev problem, I haven't seen any way of formally testing the rendering web pages, which would make it consistent on every browsers. The testing process (almost) always leave that up to the developers themselves, and refreshing pages is the norm.

Re: Programming by poking: why MIT stopped teaching SICP

#130

Reading this made me so so sad, I do agree with the reasoning. I learned to program on a course that follows SICP, I spent all my college years learning how to program from first principles, building all the pieces from scratch. Building compilers, soft threads implementations, graph parsing algorithms... and I was happy with that way of programming! Today I'm an iOS developer, I spend most of my day 'poking' at the…

And why exactly you're wasting your skills on something as pitiful as this? There is a lot of work out there for people who can build complex solutions from the first principles.

Even piecing together systems out of existing components significantly benefits from knowledge of first principles.
Post reply on HN