[News] Handmade Educational Roadmap

Sounds like a great lineup, looking forward to them. Props to the authors.

Nothing to add to insofaras's comment. I'm looking forward to them.

Hi Abner , I’m very excited about the < Building an 8-bit breadboard computer> annotations and threads , summaries project.

You’re thinking exactly what I was thinking.I had done the annotations and summaries already, but all in Chinese mandarin in a Word document, by the way ,I’m a Chinese ,lol.

I had kept the annotations myself , the reason is :1.For English native speaker , there is very little chance that he knows Chinese. 2. For Chinese , Youtube is blocked in China.Even if they can access Youtube ,the majority of Chinese,even college student with a CET6 can’t understand spoken English very well. So the value of my annotations and summaries about the course is very limited.
Any ideas on how we can working together ? I’m always looking for some chance to contributing to the handmadedev community.

Boleban,

Thanks; I'm quite glad you want to help out the community. Indeed, encouraging people to build their own very simple but fully-working machine will build a lot of confidence and overall understanding, because programming is ultimately about controlling these electronic chips.

Send me an e-mail ([email protected]) and as soon as I get the chance I'll reply to you with different ways of helping out.

Boleban, you could upload your annotations for all the Chinese immigrants and people who came to the US from China to study. This is not a small audience, and they know English at some level. Also, most of them would benefit from an opportunity to practice English, even if it's just watching tutorials on YouTube, and your annotations would make these tutorials more accessible for them.

Hi is jeroen creating a platform layer for raspberrypi.(the one you can directly boot without the os ) .
And when is (or will there be) the post or video about making of handmade network website will be available. (Just curious on how "undjango looks").
Anyways the tutorial line up looks great looking forward to it.

Thanks for getting this together Abner.
I am very much looking forward to the Introduction to Numerical Computation lessons.

Thanks. I just started watching - how to build an 8bit cpu! It's really good!

So how much longer for world domination!?

I can not wait get my grubby paws (pun intended) on those great materials. I will beat down those pesky puppies in my neighbourhood for sure when I build my evil robot pirate cat minions mwaahhaha nyaaaaaan.

Super! Very excited

Authors began writing thelessons a week or so ago, with another meeting this Sunday. It'll be a while, but I'll provide progress reports on the news. Also if anyone wants to volunteer as a peer reviewer let me know.

I'm not sure if Jeroen will be working with the raspberry pi, but he'll reply if that's the case.

Hi guys,

Been working on this recently: http://byte.school github (the version on github is more up-to-date)

It's a beginner/intermediate course covering a bunch of stuff. The structure divides everything into "lessons" and "practicals". The lessons are a sequence of purely expository material; the practicals are a sequence of tutorials/demos/exercises. Each practical has a prereq of reading up to some point in the lessons. A really patient student could read through all the lessons before touching the practicals, but most students will probably prefer jumping back and forth.

At some point, I'll make video walkthroughs of the practical material, but for now I'm just sticking to text.

The core progression focuses around Go:

• bit representation of data
• hardware and OS basics
• assembly (for a fictional processor; kept very basic)
• my pedagogical intro high-level language, called Pigeon
• Go
• basic algorithms and data structures
• image formats and basic processing
• networking
• HTML/CSS
• SQL (with sqlite and postgres)
• Bash
• Git

So far, I have drafts of everything up through Go. Should take a few more weeks to draft the rest.

After the core progression, there will be more units which students can do in any order:

• C
• Javascript
• x86 assembly
• Java

I have rough, complete drafts for C, Javascript, and Java, but there's a lot of work to do. (I wasn't going to cover Java at all, but I'll be teaching a 12-week Java course soon, so I threw it in.)

This is my fifth or sixth try over the years to make an intro course. I've tried starting with C, Javascript, Python, Java, Clojure, and MIPS assembly, but this time I'm finally happy with the progression. By starting with a fake assembly and a fake high-level language, I can start things out very simple but still convey the core ideas of low- and high-level programming. Go turns out to be pretty ideal as a first language:

• Javascript is simple enough (or at least was up to a few years ago), but it requires explaining the distracting ugliness of the browser or the distracting weirdness of Node. With Go, we can write "real", natively-compiled programs.
• x86 assembly and even MIPS assembly are weighed down by too many instructions and quirks.
• Java, even aside from its merits for day-to-day use, makes some very basic things unnecessarily difficult to learn (just consider the rules for how names get resolved).
• Python starts out well, but its more advanced features are weird and hard to explain; also, the transition from Python 2 to 3 presents many annoying distractions.

But why not start with C? Strictly speaking, C is a smaller language than Go: C doesn't have Go's slices, maps, methods, interfaces, packages, embedded structs, panics, nested functions, closures, goroutines, or channels. Aside from unions, pointer arithmetic, and the preprocessor, there's basically nothing in C that doesn't have a close analog in Go. However:

• Most of those things which Go has but C doesn't are very useful, especially to new programmers. Having slices (effectively dynamically-sized arrays) and maps out of the box gives Go a dynamic-language feel in a static language. C's lack of namespacing is archaic. Goroutines and channels, though perhaps not the end all solution to multi-threading, are the easiest introduction to multi-threading I know of.
• C's implicit casts potentially confuse learners about the whole concept of types and static typing. All Go casts are explicit (except when using implementing types of an interface), and Go doesn't have type aliases (aside from a few built-in ones, like 'rune' for 'int32').
• C naming conventions are ugly. The C standard libs (as well as Unix and Windows platform API's) use gross names.
• C's use of * [] and () as type modifiers on declared names is the WORST SYNTAX CHOICE EVER. Go types are way easier to learn to read (even just putting names before types is a win).
• C's concept of declarations vs. definitions is confusing in itself, and the notation makes it 10x more confusing.
• The preprocessor is a language on top of a language, and the moment you start doing real C programming, real API's use macros in weird and scary ways.
• With Go, there's just one real choice of compiler, and its use on the command line is very straightforward. Compiling C very quickly drags in a bunch of distracting Windows and Unix shell syntax, build scripts, etc.
• Go has full-featured but mostly straightforward standard libs. Compared to other full-featured standard libs, the Go libs have a very flat organization. It's super easy to get lost browsing through the standard classes of Java, Python, Ruby, C#, and other OO languages.
• Go has fewer undefined behaviors and generally has better error messages. Runtime checks catch some very basic errors, like out-of-bounds indexing.
• Despite being garbage collected, Go at least has the programmer thinking in terms of bytes. Unlike with other GC languages, a user of Go knows exactly what every piece of data looks like in memory (bar padding and maps).

After learning Go, learning C (at least the language itself) is very straightforward. The student can focus on all those distracting ugly bits about C because they'll already understand most everything about the semantic core. The only major new semantic concepts coming from Go are manual memory management and pointer arithmetic.

There's often a concern that students need to start without garbage collection lest they never learn to cope without it. I don't really believe students get infected by learning one thing that makes them incapable of learning other things. What *can* happen, though, is that students get distracted and preoccupied to the point that they never learn things they should. Also, students can develop *confused* ideas that hinder learning new things: if, say, a student learns a GC language but develops an incorrect mental model of how it all works, that could hinder learning memory management. I think Go taught properly avoids that issue. Better that students learn the basics first, and then they can focus on memory management without distractions.

If there is one big down side to starting with Go, it's the terrible debugging story. JetBrains is putting out Gogland with a visual debugger, but it will soon be non-free, and I can't verify its quality. Alternatively, setting up a visual debugger requires editor plugins (and thus configuration headaches), and I've had mixed experiences.

Anyway, once these topics are all complete, I'd like to expand out to more topics, like say OpenGL, audio, data compression, encryption, GUI programming, FP, possibly some math topics, etc. Not all of this I'm qualified to cover myself, so hopefully I can rope in some other authors. For now, though, it's important to establish all this baseline material. If you see factual mistakes in the current version, let me know on github. At some point I'll take structural suggestions/patches, but for now I'd like to focus on filling in the missing pieces.

If someone wants to write the x86 material, that would be great. I also need help completing my fictional assembly: the idea is that our imaginary system has just one device, a terminal, but I can't decide what exactly the set of memory-mapped registers should be and how they should be handled. I want something as simple as possible but still representative of a real system (or at least a system that, in principle, *could* exist). I also haven't yet written any example code, and there's probably some essential instructions I've forgotten to include. Once that all gets sorted, it would be super cool to have a simulator for students to use, so that's another thing I'd love for someone to contribute.

Come to think of it, I also need to work a bit on the markdown conversion I'm using and fix the syntax highlighting (currently done in JS in the browser). Currently, neither of these things let me format things exactly how I want.

I don't know where any of this fits into HMD's plans, but at the very least it should be complementary!

On the topic of education, have any of you seen the Crash Course series for Computer Science yet. I think it has been really good so far.
https://www.youtube.com/playlist?...L8dPuuaLjXtNlUrzyH5r6jN9ulIgZBpdo