Learn the WebAssembly Text Format
by fixing a bunch of small programs!
This project is incomplete and in active development.
Feel free to help out by filing issues and creating PRs!
Clone the repository and install dependencies with:
git clone firstname.lastname@example.org:EmNudge/watlings.git cd watlings npm install
Test your answer to an exercise with the
npm start 001_hello
If you'd like to view the solution to an exercise, use the
npm run solve 001_hello
For syntax highlighting and up-to-date builds, you can optionally use the official WebAssembly Binary Toolkit which will provide you with a
wat2wasm CLI tool.
If it is found on your path as
wat2wasm, it will be used instead of NPM WABT.
While it is strictly optional, it can help with debugging.
This should provide syntax highlighting, intellisense, and other helpful features as you work through the exercises.
I've found just diving in to be the best way to build experience with programming.
WebAssembly (and by extension WAT) has a more sparse educational landscape than most and I was hoping to fill some of the gaps by building a project with the same sort of structure.
Outlined here are some thoughts on what makes a good teaching experience.
The goal is to learn by doing. Comments on each file outline a task and some background. However, a lot about a language can be gleaned by its syntax alone. We should be adding as little explanation as possible.
Occasional gaps in knowledge can be filled by consistent exposure to the syntax within different contexts. Certain things can therefore be learned without any mention.
Introduction text is superfluous. Words add visual noise, so we should be careful with our count. Coding itself should supplement ambiguities in the text.
If you find a text confusing or too verbose, please create a discussion post!
Studies have shown that one cannot learn effectively without effort. This applies to practically every domain of knowledge. These projects should be educational, not easy.
This does not mean we should make the education itself elusive. We should not make learning more difficult, but instead more intentional.
When introducing a lot of new syntax, keep the problem scope small, but force the user to read a bit. If the syntax is not new, increase the problem scope. Maybe many variations of the same task.