yep:(
Programming by poking: why MIT stopped teaching SICP
171–180 of 245 posts
Re: Programming by poking: why MIT stopped teaching SICP
#172Reading 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…
Re: Programming by poking: why MIT stopped teaching SICP
#173Earlier quoted context omitted.
> no one has time to learn everything Nonsense. The fundamentals don't take a long time to learn. And once you know them, everything else becomes much easier to learn. That's the reason that learning the fundamentals matters: it's a huge lever. Here's a single, small, very accessible book that takes you all the way from switches to CPUs: http://www.amazon.com/Code-Language-Computer-Hardware-Softwa... SICP gets you fr…
Yes, learning the fundamentals is a huge lever. I absolutely agree. But I still stand by the assertion that "no one has time to learn everything" - especially at the beginning of their career. As the old saying goes "if I had 3 days to cut down a tree, I'd spend the first 2.5 days sharpening my axe". Sure, but at some point you have to actually start chopping. By analogy, at some point you have to quit worrying about…
right. No one has time to learn endless js frameworks, injections and reinventions of the wheel. So (1) read the fucking SICP book, (2) learn about the business problem you are trying to solve, put 1 and 2 together and "get stuff done".
Re: Programming by poking: why MIT stopped teaching SICP
#174Eh. Many students will have the rest of their lives to perfect the art of poking at a library. Getting the chance to play with the more sublime CS stuff is much harder outside of university.
Students also have the rest of their lives to learn the sublime CS stuff. Getting as many students motivated to learn CS, with Python, is a perfectly reasonable goal for a college.
Re: Programming by poking: why MIT stopped teaching SICP
#175Earlier quoted context omitted.
But that's exactly the point... these days, even 4 whole years isn't enough to learn "all the fundamentals", at least not while balancing things so that you learn enough practical skills to also do something useful. So what do we do, have people do a 4 year degree, and then go spend 8 weeks, or 16 weeks, or a year, learning to actually build systems? I don't know, maybe that is the answer. But I suspect the MIT guys…
> But that's exactly the point... these days, even 4 whole years isn't enough to learn "all the fundamentals", at least not while balancing things so that you learn enough practical skills to also do something useful A minor point to make here, college isn't about learning practical skills; that's what trade schools and on the job training do. College is about learning the fundamentals, however, computer science is n…
Yes, on paper that is true. And I alluded to that point in my answer above (or at least I meant to). But from a more pragmatic and real world point of view, colleges are at least partially about teaching practical skills. I don't know the exact percentage, but I'm pretty sure a large percentage of college students go in expecting to learn something that will pointedly enable them to get a job. Of course one can argue whether that's a good idea or not, and I don't really have a position on that. But I don't think we can ignore the phenomenon.
Re: Programming by poking: why MIT stopped teaching SICP
#176Earlier quoted context omitted.
That's because at some point the industry lost the plot. The fundamentals are fundamental. They don't change very fast. Applications change all the time. So do frameworks. But there's very little genuinely new in most frameworks, or in most languages for that matter. They're mostly repackagings of the same few ideas. Which is why it's a lot easier to pick up applications and do a good job with them if you know the fu…
I wonder how much of this is due to the idea: 1) non-technical users need to be able to use our software. How much code today is about preventing users from doing something they should know better? 2) we're less and less able to say "no, that goes way beyond the project's scope" to our bosses. Our bosses will quickly reply "yeah well Google's ______ does it, so why can't we?".
Re: Programming by poking: why MIT stopped teaching SICP
#177There's a quote I love from the book "The Idea Factory: Learning to Think at MIT": Freshman double E's take six double oh one (a.k.a. six double no fun) to learn to program in LISP... This is also where they begin to leave the rest of the world behind them in their ability solve problems and make things work. He goes on to describe how the course instills the virtues and limits of abstraction.
Re: Programming by poking: why MIT stopped teaching SICP
#178Earlier quoted context omitted.
Students also have the rest of their lives to learn the sublime CS stuff. Getting as many students motivated to learn CS, with Python, is a perfectly reasonable goal for a college.
That's a perfectly reasonable goal for a high school or someone performing self study. The whole point of a university is to impart knowledge of subtle things.
Re: Programming by poking: why MIT stopped teaching SICP
#179Eh. Many students will have the rest of their lives to perfect the art of poking at a library. Getting the chance to play with the more sublime CS stuff is much harder outside of university.
Students also have the rest of their lives to learn the sublime CS stuff. Getting as many students motivated to learn CS, with Python, is a perfectly reasonable goal for a college.
Re: Programming by poking: why MIT stopped teaching SICP
#180Reading 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…
I feel miserable doing the kind of programming I do nowadays! I wish I could go back to simpler times, where I actually had to reason about algorithms, data structures, hardware, etc... I don't subscribe to the school of thought that values engineers lower on the stack more than those higher up, especially since there seem to be a lot more new jobs of the latter sort and we all need to make a living, and there are pl…
I don't subscribe to the school of thought that
values engineers lower on the stack more than
those higher up
Meaning developers who understand low-level details vs. developers who just wire up high level libraries?I've done the full range, from entire games written in assembly language and embedded C code, through high level full stack development with NodeJS, Python, and other languages.
The low-level coding is far more skilled work than the high level coding. Instead of most of the work being "how do these plug in to each other?", it's how exactly does my code function with respect to all of the potential events additional threads, and how all of the edge cases interact, and what is causing this obscure bug?
While that may not seem intrinsically harder, none of these are typically something you can Google or search StackOverflow for the answers on. So you're really just on your own. And developers who have grown up on "Google all the answers!" often hit a wall when they need to apply real problem solving skills.
Luckily I can find enjoyment in many levels, since a lot of the jobs I've found recently have been more of the "full stack" or "mobile development' category. It's easy and fun work.
I also have little problem piercing the magic and understanding how things fit together, but that means that I end up with opinions on many topics divergent with the crowd. For instance, I avoid writing Android/Java or iOS/Swift, and instead use cross-platform development stacks exclusively. Yes it means an entire extra layer of complexity, but it also means I write the app once for all target platforms. Far too big of a win to ignore.