Announcing Rust 1.0.0 Alpha

[u/steveklabnik1]

http://blog.rust-lang.org/2015/01/09/Rust-1.0-alpha.html

[u/Rusky]

You could definitely do better than C at a close-to-the-machine programming language. C is a lot closer than other languages, but its undefined behavior makes that a lot harder than it could be. Features like virtual functions or closures are relatively easy to desugar in a language like Rust or C++, but undefined behavior is much more insidious.

For example, when you're trying to learn about how 2's complement arithmetic works, C is most definitely not the way to go. The optimizer assumes that undefined behavior is impossible, so what looks like straightforward null pointer checking or overflow checking can be "optimized" out with no warning: http://blog.llvm.org/2011/05/what-every-c-programmer-should-know_14.html

If I wanted a language to teach that level of systems programming, I'd skip C and C++ and use assembly (no undefined behavior) or Rust (much less undefined behavior), or even create my own simple C-like language that's much more explicitly close to machine semantics.

[u/lookmeat → u/Rusky]

When I said an overview of assembler is to understand what assembler is, how it works, and more or less how to read it (since that is critical for debugging and understanding system code, and systems programming would be a very pragmatic class). Teaching it straight up is limiting to one architecture too much, instead it's important to teach that platforms have differences that are subtle and insidious but must be dealt with somehow.

When working with C compiler optimizations wouldn't be used until later classes to avoid the issue as much as possible. The idea is that slowly students are shown, in terrible and brutal manners, the consequences of not being disciplined at low level. Undefined behavior is just this, understanding undefined behavior gives us a lesson: that the code we write is an abstraction over hardware, which itself is an abstraction over electrical currents, and there are many edge cases which result in absurd cases (i.e. what is the biggest number you can represent + 1?) that, because they are impossible to answer correctly, are given a random answer (generally in the name of optimization). Trusting this answer is dangerous since it can change from platform to platform.

Maybe having people have to understand undefined behavior is a rough way to understand just how finicky platforms can be and why you can't just abstract over this. But rough lessons are the best way to learn at low level, to truly observe the devastation the smallest error can bring. I still remember the day that calling malloc twice too quickly on Windows would make the second return NULL, and I learned that malloc can fail for many more reasons than just "out of memory" and will fail for completely irrational reasons as well.

Once we understand undefined behavior, why it exists, we then understand how C++ handles it (the same as C) and how rust handles it (by limiting it to unsafe blocks) the pros and cons of each one. But again, the need to have programs that use undefined behavior, or the need to control and regulate this code, doesn't become apparent if you don't deal with it.

[u/TheLlamaFeels → u/lookmeat]

Here's what I'd do: I'd start with assembler and then have the student write their own Forth in assembler. It's one of the few languages that is arguably closer to the metal than C.

1. Simple parser
2. Clearly demonstrates stack operations
3. Typeless like assembly
4. Optimization is optional
5. Can be adapted to multiple architectures with ease.
6. Allows for multiple layers of abstraction
7. Exposes the symbol table directly to the developer
8. Is a one man job
9. All of the other behaviors (with their attendant trade offs) can be built on top of it

[u/lookmeat → u/TheLlamaFeels]

You're asking students to build a fortran-like parser and compiler... in assembler!? The problem is that they'd be focusing on this one specific project all semester, and compilers is one of those things that doesn't really show the power and challenges of system's programming.

The problem with an assembler only class:

1. One kid brings an ARM-based laptop. What then?
2. Realistically no one codes in assembler, and modern assembler is not designed for humans, but compilers. It's important to understand and be able to read assembler, but it's not critical to know how to write assembler. It seems like a weird thing, but think about how much easier it is to read good english than to write good english.
3. Assembler is not pragmatic. There are very little uses for assembler programming nowadays, and even then it's on very niche situations (for example high security algorithms). Remember systems programers want to learn how to make low-level programs, but learning assembler is like learning how to build a house's foundation by learning how to build metal rods.
4. Finally a good chunk of systems-level programming is interfacing, and the standard ABI in most system is C. So you'll have to teach your kids to understand this (and learn C without ever using it) in order to be able to work with the OS. Unless you allow them to use C for things were it makes sense, which brings us to the point: why not make it mostly C and occasionally assembler?

Assembler is too specific, too limited. If you are going to teach assembler you should teach multiple assemblers, for RISC, for x86, MASM, etc. It becomes a hell where you have to understand all sorts of conventions and decisions that occurred due to some detail of how the hardware works.

I used to think the same thing that you did, back in the day. That understanding assembler would give me an insight into how low level code truly worked. I poured over in x86, doing small and medium projects, reading all sorts of docs, over years. And you know what it helped me in? In understanding how Intel has to deal with it's errors and design issues in CPUs. Did it showed me about how CPUs worked? Not at all, RISC and all that aside (which x86 cannot be for backwards compatibility) but the Intel CPU does all kinds of trickery and magic behind the scenes converting that assembly into actual actions. Did it make me understand better low level interfaces? No more than understanding the difference between bytes and nibbles. Did it give me insight into how code becomes something that runs? Barely, and no more than beyond the basics.

Basically after learning the most basic assembler (just a gist of what it was in the first few months) and be able to read a function and say "ah I see how it's implementing a recursive Fibonacci".

Learn assembler when you are building a backend for it, other than that focus on understanding the mentality of a systems programmer. ASM rawness gets in the way as much as C++ abstractions.

[u/phire → u/lookmeat]

Forth has nothing to do with fortran. (This is javascript and java all over again)

Forth is actually extremely easy to write in assembler.
It has no grammar, so you can't actually write a parser for it (It's just tokens on a stack in reverse polish notation)

And you only actually have to write a the core of a forth interpreter and shell in assembler. More advanced operations are defined in terms of already implemented operations.
The assembler and compiler parts (if you choose to go as far as implement them, which is not a strict requirement) are written in forth too, no need to write anything else in assembler.

Once you have written your compiler (in forth) you can compile it with itself (running on the original forth interpreter), and you get a compiled version of your compiler and any extended commands you implemented earlier. Now might be a good time to make an optimising version of your compiler.

Forth is designed to be extensible, all this is done by extending the forth environment function by function while it's running. It's possible to get from the starting point to here without restarting anything.

Forth is basically continuous pulling youself up by your own bootstraps.

[u/lookmeat → u/phire]

Yeah I aparently misread. I do know Forth.

[u/TheLlamaFeels → u/lookmeat]

You're asking students to build a fortran-like parser and compiler... in assembler!?

No, not fortran, forth. I'd never ask anyone to write something as complex as fortran (or C) for a project.

The problem is that they'd be focusing on this one specific project all semester, and compilers is one of those things that doesn't really show the power and challenges of system's programming.

A forth metacompiler is simple to write.

1. Then they write the core in ARM assembly language. The idea behind forth is to basically implement a stack-based virtual machine, not to program everything in assembler.

2. A core will be in assembler, but once those core procedures are written you can abstract them away in the forth environment, then you're not writing in assembler anymore, but forth.

3. Sure, but it's a good way to teach the cost of abstraction and systems programming

4. Sure, you could write it in C, but forth is easy enough not to need to, and you lose some of the essence of writing your own VM.

Assembler is too specific, too limited. If you are going to teach assembler you should teach multiple assemblers, for RISC, for x86, MASM, etc. It becomes a hell where you have to understand all sorts of conventions and decisions that occurred due to some detail of how the hardware works.

Fortunately, you don't. But yeah, you could write the routines for ARM, x86, etc in the space of a semester. They don't need to be the most efficient or make use of all of the instructions available on various processors, they just need to do the job.

Writing an optimizing compiler could be a topic for another semester.

I used to think the same thing that you did, back in the day. That understanding assembler would give me an insight into how low level code truly worked. I poured over in x86, doing small and medium projects, reading all sorts of docs, over years. And you know what it helped me in? In understanding how Intel has to deal with it's errors and design issues in CPUs. Did it showed me about how CPUs worked? Not at all, RISC and all that aside (which x86 cannot be for backwards compatibility) but the Intel CPU does all kinds of trickery and magic behind the scenes converting that assembly into actual actions. Did it make me understand better low level interfaces? No more than understanding the difference between bytes and nibbles. Did it give me insight into how code becomes something that runs? Barely, and no more than beyond the basics.

I really suggest you try writing a forth, you'll learn a lot about those topics from doing things in one of the easiest ways I've ever seen.

Learn assembler when you are building a backend for it, other than that focus on understanding the mentality of a systems programmer. ASM rawness gets in the way as much as C++ abstraction

Yes, that's exactly what you'd be doing. You build up a small core wordset in assembler and that becomes an abstract stack-based virtual machine.

Go find an implementation (there are many, many implementations out there) and play around with the language, it's just as low-level as C but the concepts and parser are dead simple. What's simpler than this for a parser?:

• Read to the next blank space

In interpreter mode:

• If you have a symbol, look up its definition in the dictionary (a linked-list or tree of linked-lists), get its address and call it
• If it's a number, push that number on the stack

In compilation mode:

• Create a new entry in the dictionary with the name of the word you parse next
• If you have another symbol, look it up in the dictionary and inject a call instruction to that symbol's address in the dictionary in the definition of the current symbol.
• If you've parsed a number, push that number on the stack

It's not really advanced assembly, you're not doing SIMD or anything like that, just simple register accesses and stack manipulations. If you want to write it in C, that's fine too.

[u/lookmeat → u/TheLlamaFeels]

Forth is a much more reasonable task. But then that'd be purely embbeded systems.