3 ms·

I agree. At the very least, teach assembly in the first term, at the same time as students are learning a high level language. If you know assembly, you can u

I agree. At the very least, teach assembly in the first term, at the same time as students are learning a high level language. If you know assembly, you can understand why arrays exist in C ( because CPUs have base-and-offset addressing), why records exist (same reason), what pointers are (assembly is pretty much about pointers), why ints are different from floats (ADD vs FADD) and so on, how functions are called (system stack). Absolutely. My first year of programming we took both Fortran and IBM assembly. It all made a lot more sense, and still does.

nsonha 5y ago
We have dedicated classes in computer architecture to learn all the things you mention, it's not the job of a programming language to teach them to you When I first learn C in highschool the asign statement was what bugged me the most because I had already has a math background at that point so statements such as x = x + 1 made no sense, and even in natural science general, the idea that you can "asign" new intrinsic property to a thing is very unintuitive. 20 years later mutablity is the exact idea that I have to unlearn everyday. My point is all these languages and learning hierarchy were made up by people like us, and in an era when frankly, they had no idea where this field was headed. We should not just blindly think because they're written in a book and sound important, that students should be condescendingly reminded about them in programming languages while they're trying to learn to solve real-world problems.
- AnimalMuppet 5y ago
  Well, I had a similar experience in algebra. Here's an equation; it's the problem we're trying to solve. And we do this operation to both sides, and we get a simpler problem. OK, I understand that. And we do another thing to both sides, and we get an even simpler problem. Great. And we keep doing it, and we get... the answer??? Not a simpler problem, but the answer? How did that happen? Blew my mind. I eventually decided that what we actually got was a very simple problem, so simple that the answer was trivially obvious. In contrast, it was trivially obvious to me what "x = x + 1" was doing, even on day 1. Maybe I'm unique. But I suspect that different people trip on different things. Some trip on "x = x + 1", but that doesn't mean that it's a bad syntax. "x := x + 1" is going to make you type an extra character in every assignment over the next 40 years, in order to prevent confusion in a high school or college class. That may not be a good trade off. It especially may not be a good trade off when not everybody trips on it. (I didn't ask them to change the way they did algebra problems.)
  - nsonha 5y ago
    my quibble is not really about the equality symbol, more about assignments as a fundamental building concept of code. (Re)assignments exist in social interaction so I guess it's intuitive to people that way, but if you look at code from a perspective of modeling reality that's just not a thing that exists in nature. Maybe it's just me.
    - AnimalMuppet 5y ago
      I suspect that your mental model doesn't line up with what's happening in an assignment. (I suspect that a similar thing was going on with me and algebra...)

nsonha 5y ago

We have dedicated classes in computer architecture to learn all the things you mention, it's not the job of a programming language to teach them to you When I first learn C in highschool the asign statement was what bugged me the most because I had already has a math background at that point so statements such as x = x + 1 made no sense, and even in natural science general, the idea that you can "asign" new intrinsic property to a thing is very unintuitive. 20 years later mutablity is the exact idea that I have to unlearn everyday. My point is all these languages and learning hierarchy were made up by people like us, and in an era when frankly, they had no idea where this field was headed. We should not just blindly think because they're written in a book and sound important, that students should be condescendingly reminded about them in programming languages while they're trying to learn to solve real-world problems.

AnimalMuppet 5y ago
Well, I had a similar experience in algebra. Here's an equation; it's the problem we're trying to solve. And we do this operation to both sides, and we get a simpler problem. OK, I understand that. And we do another thing to both sides, and we get an even simpler problem. Great. And we keep doing it, and we get... the answer??? Not a simpler problem, but the answer? How did that happen? Blew my mind. I eventually decided that what we actually got was a very simple problem, so simple that the answer was trivially obvious. In contrast, it was trivially obvious to me what "x = x + 1" was doing, even on day 1. Maybe I'm unique. But I suspect that different people trip on different things. Some trip on "x = x + 1", but that doesn't mean that it's a bad syntax. "x := x + 1" is going to make you type an extra character in every assignment over the next 40 years, in order to prevent confusion in a high school or college class. That may not be a good trade off. It especially may not be a good trade off when not everybody trips on it. (I didn't ask them to change the way they did algebra problems.)
- nsonha 5y ago
  my quibble is not really about the equality symbol, more about assignments as a fundamental building concept of code. (Re)assignments exist in social interaction so I guess it's intuitive to people that way, but if you look at code from a perspective of modeling reality that's just not a thing that exists in nature. Maybe it's just me.
  - AnimalMuppet 5y ago
    I suspect that your mental model doesn't line up with what's happening in an assignment. (I suspect that a similar thing was going on with me and algebra...)