7 ms·

I have tried to convince people that ASM is reasonable as a first stage teaching language. The reputation as a nearly mystical art practiced by a few doesn't h

by Lerc 1y ago

I have tried to convince people that ASM is reasonable as a first stage teaching language. The reputation as a nearly mystical art practiced by a few doesn't help. The thing is, instructions are simple. Getting them to do things is not hard, the difficulty comes from tasks exceeding a scale where you can think about things at their most basic level. It quickly becomes tedious to do large programs, not really hard, just unmanagable, which is precisely it should be taught as a first language. You learn how do do simple things and you learn why programming languages are used. You teach the problem that is being solved before teaching more advanced programming concepts that solve the problem.

flohofwoe 1y ago
IMO It depends a lot on the assembly flavour. The best ISA for learning is probably the Motorola 68000, followed by some 8-bit CPUs (6502, 6809, Z80), also probably ARM1, although I never had to deal with it. I always thought that x86 assembly is ugly (no matter if Intel or AT&T). > It quickly becomes tedious to do large programs IME with modern tooling, assembly coding can be surprisingly productive. For instance I wrote a VSCode extension for 8-bit home computers [1], and dog-fooded a little demo with it [2], and that felt a lot more productive than back in the day with an on-device assembler (or even typing in machine code by numbers). [1] https://marketplace.visualstudio.com/items?itemName=floooh.vscode-kcide https://marketplace.visualstudio.com/items?itemName=floooh.v... [2] https://floooh.github.io/kcide-sample/kc854.html?file=demo.kcc https://floooh.github.io/kcide-sample/kc854.html?file=demo.k...
- whobre 1y ago
  I agree that M68k is nice, as are the 8-bit ones you mention. I just find it strange that you like Z80 and dislike x86 - they are fundamentally not that different and both are descended from 8080.
  - flohofwoe 1y ago
    Yeah the Z80 instruction set is quite messy (mainly because it had to fill gaps of the 8080 instruction set for backward compatibility). But as an evolution of the 8080 instruction set, the Z80 is still cleaner than x86 (IMHO!). Also, the Z8000 looks quite interesting and like the better 16-bit alternative to the x86, but it never took off: https://en.wikipedia.org/wiki/Zilog_Z8000 https://en.wikipedia.org/wiki/Zilog_Z8000
- tsimionescu 1y ago
  Sure, but learning an old ISA can leave you with a very very wrong idea about how modern processors work. Even x86 assembly paints a very misleading image of how modern processors actually work. For example, someone learning x86-64 assembly will likely believe all of the following: - assembly instructions are executed in the order they appear in in the source code - an x86 processor only has a handful of registers - writing to a register is an instruction like any other and will take roughly the same time - the largest registers on an x86 processor are 64-bit
  - t-3 1y ago
    They will be disabused of any of those notions simply by reading the relevant portions of the architecture handbook. In a pedagogical environment that's very simple to arrange.
    - tsimionescu 1y ago
      Someone who is just learning to program will not be well served by reading a modern CPU architecture handbook. It is far too complex for someone who doesn't even know yet what a graph is, for example.
      - t-3 1y ago
        They don't have to read the whole thing. Excerpts or specific pages/sections, presented under the guidance of an experienced teacher or mentor, are perfectly digestible. The instruction description pages are the best documentation for looking up how to use instructions as well.
  - flohofwoe 1y ago
    Peeking under the hood is a later step after getting comfortable with assembly coding. E.g. none of those details are really relevant when starting out, instead it makes a lot of sense to do a speed run through computing history in order to really understand why modern CPUs (and computers as a whole) work like they do.
  - ThrowawayR2 1y ago
- Lerc 1y ago
  Oh nice, I was talking just yesterday how I liked chips as a programming paradigm. I agree about tooling, I made a pacman game in a dcpu16 emulator in a couple of days. https://fingswotidun.com/dcpu16/pac.html I experimented with a fantasy console idea using an in-browser assembler as well. https://k8.fingswotidun.com/static/ide/ https://k8.fingswotidun.com/static/ide/ I think you can build environments that give immediate feedback and the ability to do real things quickly in ASM. I would still recommend moving swiftly on to something higher level as soon as it started to feel like a grind.
criddell 1y ago
If you have a good macro assembler, it is only a little more difficult than C. There's just more to learn up front (things like calling conventions, register usage, etc...). I wouldn't teach it first, but after a person knows the basics in another language, seeing how it all actually works can be fun.
tsimionescu 1y ago
The biggest problem with using ASM as a first language to teach beginners is that it is extremely tedious, error prone, and sensitive to details. It is also unstructured, it uses entirely different control flow primitives than any language they will learn in the future, meaning they will not be well prepared for learning a real language that does scale to programs more complex than a few additions and calling an OS output routine. So why teach someone a language that doesn't have if, while, (local) variables, scopes, types, nor even real function calls? It's a very nice exercise for understanding how a computer functions, and it has a clear role in education - I'm not arguing people shouldn't learn it at all. But I think it's a terrible first language to learn.
- yetihehe 1y ago
  > So why teach someone a language that doesn't have if, while, (local) variables, scopes, types, nor even real function calls? You can teach them how to implement function calls, variables and loops using assembly, to show them how they work under the hood and how they should be thankful for having simple if in their high level languages like C.
  - tsimionescu 1y ago
    That often leaves people with very bad mental models of how programs actually compile in modern optimizing compilers and in modern operating systems (e.g. people end up believing that variables always live on the stack, that function parameters are passed on the stack, that loops are executed in the same way regardless of how you write them, etc).
    - dmwilcox 1y ago
      Think about how far they've come if you get them to have these "misconceived" ideas! They would understand code and data are in the same place, that all flow control effectively boils down to a jump, and they have a _more_ accurate picture of the inside of a machine than anyone starting out with Python or JavaScript could hope for. Having spent 25 years to get to assembler, I wish I'd started it sooner. It's truly a lovely way to look at the machine. I'll definitely be teaching my kids how to program in assembly first (probably x86-16 using DOS as a program launcher)
UltraSane 1y ago
x86 ASM absolutely is NOT a good first language due to it being a complete mess.
- rep_lodsb 1y ago
  16 bit x86 isn't that complicated and (IMO) still helpful in learning some of the more modern stuff. But I'd recommend starting with either 6502, or the 8080, which is like the 8 bit "grandparent" of x86. Avoid: - Z80: at least as a first language. Extended 8080 with completely different syntax, even more messy and unorthogonal than x86! LD A,(HL) ;load A from address in HL register pair LD A,(DE) ;load A from address in DE LD B,(HL) ;load B from address in HL LD B,(DE) ;invalid! JP (HL) ;load program counter with contents of HL (*not* memory) ADD A,B ;add B to A ADC A,B ;add B to A with carry SBC A,B ;subtract B from A with borrow SUB B ;subtract B from A OR B ;logical-or B into A etc. - RISC-V: an architecture designed by C programmers, pretty much exclusively as a target for compiling C to & omitting anything not necessary for that goal
XorNot 1y ago
This almost feels like an argument that we should teach computer science via bare metal bootstrapping. Start out at "here's your machine code. Let's understand how x86_64 gets started" and work your way up to "now you have the automation to compile Linux and a modern compiler". Which would certainly have stops most of the way up for things we usually include.
- bitwize 1y ago
  So... NAND to Tetris?
aaronbaugher 1y ago
I started with Z-80 assembly, then BASIC, then 6502 assembly, then higher-level languages like C and perl, and I think the assembly gave me a useful foundation for what was going on under the hood. I'm not sure I'd even call assembly a "language" in the sense of the others. It has instructions, not statements, and there's really no syntax. If I were teaching a general-interest programming course, I'd probably start with just a bit of BASIC to introduce a few broad concepts like variables and looping, then a little assembly to say, "And this is what's going on when you do those things," and then move up the chain. Then when they get to something like C and go to look at the assembly it produces for debugging, they'll at least be familiar with concepts like registers and branching. So not quite the order I happened to do it in, but similar.
vbezhenar 1y ago
Beginners should have immediate positive feedback. It's not possible with assembly language.
- cbm-vic-20 1y ago
  You can with a decent monitor that shows the values of registers, can look up values in memory, etc.
- myrmidon 1y ago
  Shenzhen I/O begs to disagree :P https://www.zachtronics.com/shenzhen-io/ https://www.zachtronics.com/shenzhen-io/
- t-3 1y ago
  It's just as straightforward as in higher level languages, just not quite as interactive as interpreted languages, but I've never seen an "intro to programming" that started in a REPL even when using an interpreted language. Hello world is even shorter and simpler than most languages (in a modern OS environment).
  - rep_lodsb 1y ago
    The old D86 debugger[1][2] comes close to being a REPL for assembly language, helped me a lot with learning it when I found it on a shareware collection CD as a kid. Load registers, call DOS or BIOS with 'int', etc. all interactively and with a nice full screen display of registers, flags and memory. Of course entering single instructions to run immediately only gets you so far, but you can also enter short programs into memory and single step through them. It's too bad nothing like this seems to exist for modern systems! With the CPU virtualization features now available, you could even experiment with ring 0 code without fear of crashing your machine. [1] http://eji.com/a86 http://eji.com/a86 [2] to run it under DOSBox, you may need to add the '+b4' command line switch in order to bypass some machine detection code
- skydhash 1y ago
  You start with a simulator like this one: https://edsim51.com/about-the-simulator/ https://edsim51.com/about-the-simulator/ Very immediate and positive feedback.
lo_zamoyski 1y ago
> I have tried to convince people that ASM is reasonable as a first stage teaching language. Unless you're teaching people preparing for engineering hardware perhaps, I think ASM is absolutely the wrong language for this. The first reason is that programming is about problem solving, not fiddling with the details of some particular architecture, and ASM is pretty bad at clearly expressing solutions in the language of the problem domain. Instead of programming in the language of the domain, you're busy flipping bits which are an implementation detail. It is really a language for interfacing with and configuring hardware. The more insidious result is that teaching ASM will make an idol out of hardware by reinforcing the notion that computer science or programming are about computing devices. It is not. The computing device is totally auxiliary wrt subject matter. It is utterly indispensable practically, yes, but it is not what programming is concerned with per se. It is good for an astronomer to be able to operate his telescope well, but he isn't studying telescopes. Telescope engineers do that.
- cvoss 1y ago
  Ooh, very much disagree with a lot of these assertions. The problem I always encounter when trying to teach programming is that students completely lack an understanding of how to imagine and model the state of the computational system in their heads. This leads to writing code that looks kinda like it should do what the student wants, but betrays the fact that they really don't understand what the code actually means. In order to successfully program a solution to a problem, it is necessary to understand the system you are working with. A machine-level programming language cuts through the squishiness of that and presents a discrete and concrete system whose state can be fully explained and understood without difficulty. The part where it's all implementation details is the benefit here.
  - lo_zamoyski 1y ago
    I suspect your background is dominated by imperative languages, because these often bleed low-level, machine concepts into the domain of discourse, causing a conceptual muddle. From a functional perspective, you see things properly as a matter of language. When you describe to someone some solution in English, do you worry about a "computational system"? When writing proofs or solving mathematical problems using some formal notation, are you thinking of registers? Of course not. You are using the language of the domain with its own rules. Computer science is firmly rooted in the formal language tradition, but for historical reasons, the machine has assumed a central role it does not rightly possess. The reason students are confused is because they're still beholden to the machine going into the course, causing a compulsion to refer to the machine to know "what's really going on" at the machine level. Instead of thinking of the problem, they are worrying about distracting nonsense. The reason why your students might feel comforted after you explain the machine model is because they already tacitly expect the machine to play a conceptual role in what they're doing. They stare and think "Okay, but what does this have to do with computers?". The problem is caused by the prior idolization of the machine in the first place. But machine code and a machine model are not the "really real", with so-called "high-level languages" hovering above them like some illusory phantom that's just a bit of theater put on by 1s and 0s. The language exists in our heads; machines are just instruments for simulating them. And assembly language itself is just another language. It's domain just is, loosely, the machine architecture. So my view is that introductory classes should beat the machine out of students' heads. There is no computer, no machine. The first few classes in programming should omit the computer and begin with paper and pencil and a small toy language (a pure, lispy language tends to be very good here). They should gain facility in this small language first. The aim should be to make it clear that the language is about talking about the domain, and that it stands on its own, as it were; the computer is to programming as the calculator is to mathematical calculation. Only once this have been achieved are computers permitted, because large programs are impractical to deal with using pen and paper. This intuition is the foundation difference between a bona fide compute science curriculum and dilettante tinkering.
cameldrv 1y ago
Personally way back when, I first learned BASIC, then tried to learn C, but didn't get pointers, then learned ASM, and then pointers became obvious, and went back to C. If you're going to be using C or doing anything with hardware, learning ASM IMO is very useful just to understand how the machine really works.
zahlman 1y ago
> Getting them to do things is not hard, the difficulty comes from tasks exceeding a scale where you can think about things at their most basic level. Indeed - you don't actually need to work on difficult tasks to get the intellectual benefit. Once you've properly understood what a computer is, you can absorb the ideas of SICP.
shortrounddev2 1y ago
assembly is a good first language if you have a simple instruction set or machine. When I saw new people learn java, easily the hardest initial bump to get over was "what the hell is public static void main(String[] args) ?" or "eclipse didn't build it for some reason" Python is much easier to introduce someone to because there's no boilerplate and the tooling is very simple. Assembly on x86 machines is a royal PITA to set up, and you also need some kind of debugger to actively inspect the program counter and registers. When I took Computer Organization & Architecture, they had us play around with MARIE[1] which really made assembly make sense to me. After that, I wrote an 8080 emulator and it made even MORE sense to me. --- [1] https://marie.js.org/ https://marie.js.org/
ferguess_k 1y ago
I think in most CS programs, students do learn assembly early on, perhaps not as the first language, but definitely as a second language, as required by most Arch courses.
jcranmer 1y ago
I was a TA for an intro to assembly language course, which means I got my office hours full of all of the students who struggled with assembly language and had to work with them one-on-one to get them over their roadblocks to pass the class. Assembly language is not a reasonable first programming language. There's just so many things about it that make it a poor choice for programming instruction. Chiefly, assembly lacks structure. There's no such thing as variables. There's no such thing as functions. You can fake some of this stuff with convention, but if you make mistakes--and students in intro-to-programming will make mistakes--there is nothing that's going to poke you that you did something wrong, you just get the wrong result.

by Lerc 1y ago

flohofwoe 1y ago

IMO It depends a lot on the assembly flavour. The best ISA for learning is probably the Motorola 68000, followed by some 8-bit CPUs (6502, 6809, Z80), also probably ARM1, although I never had to deal with it. I always thought that x86 assembly is ugly (no matter if Intel or AT&T). > It quickly becomes tedious to do large programs IME with modern tooling, assembly coding can be surprisingly productive. For instance I wrote a VSCode extension for 8-bit home computers [1], and dog-fooded a little demo with it [2], and that felt a lot more productive than back in the day with an on-device assembler (or even typing in machine code by numbers). [1] https://marketplace.visualstudio.com/items?itemName=floooh.vscode-kcide https://marketplace.visualstudio.com/items?itemName=floooh.v... [2] https://floooh.github.io/kcide-sample/kc854.html?file=demo.kcc https://floooh.github.io/kcide-sample/kc854.html?file=demo.k...

whobre 1y ago
I agree that M68k is nice, as are the 8-bit ones you mention. I just find it strange that you like Z80 and dislike x86 - they are fundamentally not that different and both are descended from 8080.
- flohofwoe 1y ago
  Yeah the Z80 instruction set is quite messy (mainly because it had to fill gaps of the 8080 instruction set for backward compatibility). But as an evolution of the 8080 instruction set, the Z80 is still cleaner than x86 (IMHO!). Also, the Z8000 looks quite interesting and like the better 16-bit alternative to the x86, but it never took off: https://en.wikipedia.org/wiki/Zilog_Z8000 https://en.wikipedia.org/wiki/Zilog_Z8000
tsimionescu 1y ago
Sure, but learning an old ISA can leave you with a very very wrong idea about how modern processors work. Even x86 assembly paints a very misleading image of how modern processors actually work. For example, someone learning x86-64 assembly will likely believe all of the following: - assembly instructions are executed in the order they appear in in the source code - an x86 processor only has a handful of registers - writing to a register is an instruction like any other and will take roughly the same time - the largest registers on an x86 processor are 64-bit
- t-3 1y ago
  They will be disabused of any of those notions simply by reading the relevant portions of the architecture handbook. In a pedagogical environment that's very simple to arrange.
  - tsimionescu 1y ago
    Someone who is just learning to program will not be well served by reading a modern CPU architecture handbook. It is far too complex for someone who doesn't even know yet what a graph is, for example.
    - t-3 1y ago
      They don't have to read the whole thing. Excerpts or specific pages/sections, presented under the guidance of an experienced teacher or mentor, are perfectly digestible. The instruction description pages are the best documentation for looking up how to use instructions as well.
- flohofwoe 1y ago
  Peeking under the hood is a later step after getting comfortable with assembly coding. E.g. none of those details are really relevant when starting out, instead it makes a lot of sense to do a speed run through computing history in order to really understand why modern CPUs (and computers as a whole) work like they do.
- ThrowawayR2 1y ago
Lerc 1y ago
Oh nice, I was talking just yesterday how I liked chips as a programming paradigm. I agree about tooling, I made a pacman game in a dcpu16 emulator in a couple of days. https://fingswotidun.com/dcpu16/pac.html I experimented with a fantasy console idea using an in-browser assembler as well. https://k8.fingswotidun.com/static/ide/ https://k8.fingswotidun.com/static/ide/ I think you can build environments that give immediate feedback and the ability to do real things quickly in ASM. I would still recommend moving swiftly on to something higher level as soon as it started to feel like a grind.

criddell 1y ago

If you have a good macro assembler, it is only a little more difficult than C. There's just more to learn up front (things like calling conventions, register usage, etc...). I wouldn't teach it first, but after a person knows the basics in another language, seeing how it all actually works can be fun.

tsimionescu 1y ago

The biggest problem with using ASM as a first language to teach beginners is that it is extremely tedious, error prone, and sensitive to details. It is also unstructured, it uses entirely different control flow primitives than any language they will learn in the future, meaning they will not be well prepared for learning a real language that does scale to programs more complex than a few additions and calling an OS output routine. So why teach someone a language that doesn't have if, while, (local) variables, scopes, types, nor even real function calls? It's a very nice exercise for understanding how a computer functions, and it has a clear role in education - I'm not arguing people shouldn't learn it at all. But I think it's a terrible first language to learn.

yetihehe 1y ago
> So why teach someone a language that doesn't have if, while, (local) variables, scopes, types, nor even real function calls? You can teach them how to implement function calls, variables and loops using assembly, to show them how they work under the hood and how they should be thankful for having simple if in their high level languages like C.
- tsimionescu 1y ago
  That often leaves people with very bad mental models of how programs actually compile in modern optimizing compilers and in modern operating systems (e.g. people end up believing that variables always live on the stack, that function parameters are passed on the stack, that loops are executed in the same way regardless of how you write them, etc).
  - dmwilcox 1y ago
    Think about how far they've come if you get them to have these "misconceived" ideas! They would understand code and data are in the same place, that all flow control effectively boils down to a jump, and they have a _more_ accurate picture of the inside of a machine than anyone starting out with Python or JavaScript could hope for. Having spent 25 years to get to assembler, I wish I'd started it sooner. It's truly a lovely way to look at the machine. I'll definitely be teaching my kids how to program in assembly first (probably x86-16 using DOS as a program launcher)

UltraSane 1y ago

x86 ASM absolutely is NOT a good first language due to it being a complete mess.

rep_lodsb 1y ago
16 bit x86 isn't that complicated and (IMO) still helpful in learning some of the more modern stuff. But I'd recommend starting with either 6502, or the 8080, which is like the 8 bit "grandparent" of x86. Avoid: - Z80: at least as a first language. Extended 8080 with completely different syntax, even more messy and unorthogonal than x86! LD A,(HL) ;load A from address in HL register pair LD A,(DE) ;load A from address in DE LD B,(HL) ;load B from address in HL LD B,(DE) ;invalid! JP (HL) ;load program counter with contents of HL (*not* memory) ADD A,B ;add B to A ADC A,B ;add B to A with carry SBC A,B ;subtract B from A with borrow SUB B ;subtract B from A OR B ;logical-or B into A etc. - RISC-V: an architecture designed by C programmers, pretty much exclusively as a target for compiling C to & omitting anything not necessary for that goal

XorNot 1y ago

This almost feels like an argument that we should teach computer science via bare metal bootstrapping. Start out at "here's your machine code. Let's understand how x86_64 gets started" and work your way up to "now you have the automation to compile Linux and a modern compiler". Which would certainly have stops most of the way up for things we usually include.

bitwize 1y ago
So... NAND to Tetris?

aaronbaugher 1y ago

I started with Z-80 assembly, then BASIC, then 6502 assembly, then higher-level languages like C and perl, and I think the assembly gave me a useful foundation for what was going on under the hood. I'm not sure I'd even call assembly a "language" in the sense of the others. It has instructions, not statements, and there's really no syntax. If I were teaching a general-interest programming course, I'd probably start with just a bit of BASIC to introduce a few broad concepts like variables and looping, then a little assembly to say, "And this is what's going on when you do those things," and then move up the chain. Then when they get to something like C and go to look at the assembly it produces for debugging, they'll at least be familiar with concepts like registers and branching. So not quite the order I happened to do it in, but similar.

vbezhenar 1y ago

Beginners should have immediate positive feedback. It's not possible with assembly language.

cbm-vic-20 1y ago
You can with a decent monitor that shows the values of registers, can look up values in memory, etc.
myrmidon 1y ago
Shenzhen I/O begs to disagree :P https://www.zachtronics.com/shenzhen-io/ https://www.zachtronics.com/shenzhen-io/
t-3 1y ago
It's just as straightforward as in higher level languages, just not quite as interactive as interpreted languages, but I've never seen an "intro to programming" that started in a REPL even when using an interpreted language. Hello world is even shorter and simpler than most languages (in a modern OS environment).
- rep_lodsb 1y ago
  The old D86 debugger[1][2] comes close to being a REPL for assembly language, helped me a lot with learning it when I found it on a shareware collection CD as a kid. Load registers, call DOS or BIOS with 'int', etc. all interactively and with a nice full screen display of registers, flags and memory. Of course entering single instructions to run immediately only gets you so far, but you can also enter short programs into memory and single step through them. It's too bad nothing like this seems to exist for modern systems! With the CPU virtualization features now available, you could even experiment with ring 0 code without fear of crashing your machine. [1] http://eji.com/a86 http://eji.com/a86 [2] to run it under DOSBox, you may need to add the '+b4' command line switch in order to bypass some machine detection code
skydhash 1y ago
You start with a simulator like this one: https://edsim51.com/about-the-simulator/ https://edsim51.com/about-the-simulator/ Very immediate and positive feedback.

lo_zamoyski 1y ago

> I have tried to convince people that ASM is reasonable as a first stage teaching language. Unless you're teaching people preparing for engineering hardware perhaps, I think ASM is absolutely the wrong language for this. The first reason is that programming is about problem solving, not fiddling with the details of some particular architecture, and ASM is pretty bad at clearly expressing solutions in the language of the problem domain. Instead of programming in the language of the domain, you're busy flipping bits which are an implementation detail. It is really a language for interfacing with and configuring hardware. The more insidious result is that teaching ASM will make an idol out of hardware by reinforcing the notion that computer science or programming are about computing devices. It is not. The computing device is totally auxiliary wrt subject matter. It is utterly indispensable practically, yes, but it is not what programming is concerned with per se. It is good for an astronomer to be able to operate his telescope well, but he isn't studying telescopes. Telescope engineers do that.

cvoss 1y ago
Ooh, very much disagree with a lot of these assertions. The problem I always encounter when trying to teach programming is that students completely lack an understanding of how to imagine and model the state of the computational system in their heads. This leads to writing code that looks kinda like it should do what the student wants, but betrays the fact that they really don't understand what the code actually means. In order to successfully program a solution to a problem, it is necessary to understand the system you are working with. A machine-level programming language cuts through the squishiness of that and presents a discrete and concrete system whose state can be fully explained and understood without difficulty. The part where it's all implementation details is the benefit here.
- lo_zamoyski 1y ago
  I suspect your background is dominated by imperative languages, because these often bleed low-level, machine concepts into the domain of discourse, causing a conceptual muddle. From a functional perspective, you see things properly as a matter of language. When you describe to someone some solution in English, do you worry about a "computational system"? When writing proofs or solving mathematical problems using some formal notation, are you thinking of registers? Of course not. You are using the language of the domain with its own rules. Computer science is firmly rooted in the formal language tradition, but for historical reasons, the machine has assumed a central role it does not rightly possess. The reason students are confused is because they're still beholden to the machine going into the course, causing a compulsion to refer to the machine to know "what's really going on" at the machine level. Instead of thinking of the problem, they are worrying about distracting nonsense. The reason why your students might feel comforted after you explain the machine model is because they already tacitly expect the machine to play a conceptual role in what they're doing. They stare and think "Okay, but what does this have to do with computers?". The problem is caused by the prior idolization of the machine in the first place. But machine code and a machine model are not the "really real", with so-called "high-level languages" hovering above them like some illusory phantom that's just a bit of theater put on by 1s and 0s. The language exists in our heads; machines are just instruments for simulating them. And assembly language itself is just another language. It's domain just is, loosely, the machine architecture. So my view is that introductory classes should beat the machine out of students' heads. There is no computer, no machine. The first few classes in programming should omit the computer and begin with paper and pencil and a small toy language (a pure, lispy language tends to be very good here). They should gain facility in this small language first. The aim should be to make it clear that the language is about talking about the domain, and that it stands on its own, as it were; the computer is to programming as the calculator is to mathematical calculation. Only once this have been achieved are computers permitted, because large programs are impractical to deal with using pen and paper. This intuition is the foundation difference between a bona fide compute science curriculum and dilettante tinkering.

cameldrv 1y ago

Personally way back when, I first learned BASIC, then tried to learn C, but didn't get pointers, then learned ASM, and then pointers became obvious, and went back to C. If you're going to be using C or doing anything with hardware, learning ASM IMO is very useful just to understand how the machine really works.

zahlman 1y ago

> Getting them to do things is not hard, the difficulty comes from tasks exceeding a scale where you can think about things at their most basic level. Indeed - you don't actually need to work on difficult tasks to get the intellectual benefit. Once you've properly understood what a computer is, you can absorb the ideas of SICP.

shortrounddev2 1y ago

assembly is a good first language if you have a simple instruction set or machine. When I saw new people learn java, easily the hardest initial bump to get over was "what the hell is public static void main(String[] args) ?" or "eclipse didn't build it for some reason" Python is much easier to introduce someone to because there's no boilerplate and the tooling is very simple. Assembly on x86 machines is a royal PITA to set up, and you also need some kind of debugger to actively inspect the program counter and registers. When I took Computer Organization & Architecture, they had us play around with MARIE[1] which really made assembly make sense to me. After that, I wrote an 8080 emulator and it made even MORE sense to me. --- [1] https://marie.js.org/ https://marie.js.org/

ferguess_k 1y ago

I think in most CS programs, students do learn assembly early on, perhaps not as the first language, but definitely as a second language, as required by most Arch courses.

jcranmer 1y ago

I was a TA for an intro to assembly language course, which means I got my office hours full of all of the students who struggled with assembly language and had to work with them one-on-one to get them over their roadblocks to pass the class. Assembly language is not a reasonable first programming language. There's just so many things about it that make it a poor choice for programming instruction. Chiefly, assembly lacks structure. There's no such thing as variables. There's no such thing as functions. You can fake some of this stuff with convention, but if you make mistakes--and students in intro-to-programming will make mistakes--there is nothing that's going to poke you that you did something wrong, you just get the wrong result.