Earlier quoted context omitted.
Every higher abstraction could be described as an attempt to pretend that the lower abstraction is less complicated and error-prone than it actually is.
I know - I'm being facetious, but really, if you want to really understand how most modern computers actually work, there's probably no better way than to learn C. It's high level enough and provides enough structure so that you don't need to actually blurt out a bunch of assembly instructions, but low-level enough so that your code mostly more or less corresponds to what the underlying Von Neumann hardware is actual…
Why MIT Switched from Scheme to Python (2009)
71–80 of 102 posts
Re: Why MIT Switched from Scheme to Python (2009)
#72Earlier quoted context omitted.
Every higher abstraction could be described as an attempt to pretend that the lower abstraction is less complicated and error-prone than it actually is.
I know - I'm being facetious, but really, if you want to really understand how most modern computers actually work, there's probably no better way than to learn C. It's high level enough and provides enough structure so that you don't need to actually blurt out a bunch of assembly instructions, but low-level enough so that your code mostly more or less corresponds to what the underlying Von Neumann hardware is actual…
I have found advice like this to be a good sign that the speaker has a very limited understanding of how modern computers actually work.
Re: Why MIT Switched from Scheme to Python (2009)
#73One of the key things about SICP in Scheme was that the language used so few intrinsic keywords and structures (I think it was something like 7 intrinsic keywords that could be used for just about everything you needed to do) that you could move on from learning about the language really quickly. It kept the focus on the underlying principles (every programming language is a set of primitives, a means of combination…
> 50 years there won't be that many application developers left either. I like your comment, but the crystal ball statement in the last sentence is a bit too much.
Re: Why MIT Switched from Scheme to Python (2009)
#74https://www.joelonsoftware.com/2005/12/29/the-perils-of-java...
Re: Why MIT Switched from Scheme to Python (2009)
#75I took 6.001 in 1999 (I think). Hal Abelson taught it along with a professor who took off his sweatshirt to reveal a Microsoft tee at his final lecture (he went to Microsoft). What was great about Scheme (Lisp) is that most programs are basically words from your vocabulary, parentheses, and cars and cdrs. With procedural languages, there is always a sense that the language provides all the tools, and the magic happen…
My favorite thing having finally taken a dive into lisp and SICP, is not that it is very friendly to functional. It is that it is very friendly to showing how it all works. My favorite section is where they go over making a constraint based system that will either calculate degrees F or degrees C. Or validate that the two given values are accurate. All depending on what you have entered. And this is done from the gro…
I wish that there was a camera pointing to the crowd when he said the more controversial things.
I didn't know that Sussman hired Stallman. Their work changed our lives.
Re: Why MIT Switched from Scheme to Python (2009)
#76Earlier quoted context omitted.
I know - I'm being facetious, but really, if you want to really understand how most modern computers actually work, there's probably no better way than to learn C. It's high level enough and provides enough structure so that you don't need to actually blurt out a bunch of assembly instructions, but low-level enough so that your code mostly more or less corresponds to what the underlying Von Neumann hardware is actual…
You take a course in computer architecture to learn how computers work. If you follow up with assembly, you'll be able to do things you can't express in C without breaking its common model. What the underlying hardware is doing also varies considerably across implementations: x86 CISC; RISC's; embedded; SIMD/MIMD; multicore; HLL or safe/secure CPU's; DSP's; GPU's. I know C doesn't map to a lot of that because there w…
I mean, just write a simple C program that reads in argv[1] and then loops from 1 to atoi(argv[1]) doing fizzbuzz. Then compile the program (without optimization) and look at the generated assembly. I just did that on an x86_64 using gcc, and the generated assembly is pretty straightforward and maps pretty well to the actual C code.
The only part that doesn't neatly map to the C code is the boilerplate call-stack stuff, (subq instructions on the rsp register, etc.). But everything else maps rather neatly. The library calls to printf, etc. are mapped to a simple call instruction. It demonstrates how closely C code maps to the actual assembly for these sort of simple programs, which is what actually matters in a pedagogical environment.
This compared to similar Python code, where the actual op codes being executed would be vastly more complicated and less obviously related to the actual "business logic" of the program - you'd have constant incref/decref'ing of objects (assuming CPython), byte code execution in the main ceval loop, hash table lookups for globals, etc. etc. The point is C code maps much better to what the hardware is actually doing. Your arguments to the contrary (talking about vectorized instructions and GPU) are really just being nitpicky. That stuff can be covered later in more advanced courses.
Re: Why MIT Switched from Scheme to Python (2009)
#77For example, here is SICP with examples using the JavaScript shovel: https://www.comp.nus.edu.sg/~cs1101s/sicp/
BTW, since this site isn't super mobile-friendly, I made a modible friendly version a while back: http://ivanistheone.github.io/SICPapp/ (only first two chapters)
Re: Why MIT Switched from Scheme to Python (2009)
#78Earlier quoted context omitted.
You take a course in computer architecture to learn how computers work. If you follow up with assembly, you'll be able to do things you can't express in C without breaking its common model. What the underlying hardware is doing also varies considerably across implementations: x86 CISC; RISC's; embedded; SIMD/MIMD; multicore; HLL or safe/secure CPU's; DSP's; GPU's. I know C doesn't map to a lot of that because there w…
Of course C doesn't map to all that. Neither do most of the MIPS emulators they actually use to teach MIPS assembly in universities. But it does map pretty well to basic loops/conditionals and other intro-to-programming stuff. I mean, just write a simple C program that reads in argv[1] and then loops from 1 to atoi(argv[1]) doing fizzbuzz. Then compile the program (without optimization) and look at the generated asse…
Re: Why MIT Switched from Scheme to Python (2009)
#79Earlier quoted context omitted.
My favorite thing having finally taken a dive into lisp and SICP, is not that it is very friendly to functional. It is that it is very friendly to showing how it all works. My favorite section is where they go over making a constraint based system that will either calculate degrees F or degrees C. Or validate that the two given values are accurate. All depending on what you have entered. And this is done from the gro…
Thank you so much for linking this video. I had no idea it existed. Watching that lecture was so much fun. I wish that there was a camera pointing to the crowd when he said the more controversial things. I didn't know that Sussman hired Stallman. Their work changed our lives.
Re: Why MIT Switched from Scheme to Python (2009)
#80I think there's a tension between two imperatives in teaching new programmers: 1) Learning must be applied learning. Give people problems to solve and they will come to you for data structures and algorithms, O notation, etc. If they don't, they should do something else 2) A lot of what's out there in programming languages are cargo cults, and newbies need to be prepared for this. For instance, virtual function inher…
My problem with this sort of bottom-up approach to learning how to program is that what seems "fundamental" from one point of view always turns out to be an abstraction built on an even lower-level foundation. So, virtual functions aren't real because they're just vtables implemented in C. But C isn't real because it's just fancy assembly language. But assembly language isn't real because it's just fancy machine lang…
I took a couple classes in college that were designed to teach what is going on underneath the 1s and 0s of instruction sets. I didn't take the classes about how circuits work, but they existed, I had friends who took them, and I really wish I had as well.
Maybe this isn't required knowledge to do software engineering, but it's definitely useful knowledge. Why wouldn't we want to learn these things?