sightreading.training VS third

https://sightreading.training/ uses your midi keyboard. excellent for sight reading practice

That can be very productive and clever, but be - and stay - aware that such polyglot solutions tend to be maintenance headaches in the longer run.

There is a really nice open source project out there that allows you to train your hearing and your sightreading, but it's written in the authors own language which in turn compiles to JavaScript and the headache to set up their toolchain is such that I haven't bothered fixing any of the bugs that I'm aware of (and there are plenty).

https://sightreading.training/

https://github.com/leafo/sightreading.training

It's written in a language called 'Moonscript':

https://github.com/leafo/moonscript

Which compiles to Lua. Which compiles to JS.

Madness. Nice madness, but still, it stopped me from being a contributor.

My first programming languages were x86 assembly and Forth. My Dad was into Forth, and I learned programming from him. I wrote several x86 Forth systems for DOS as a teenager, culminating in a somewhat-polished ANS compatible one I called "Third": https://github.com/benhoyt/third -- it's kind of amazing being able to have a fully bootstrapped Forth compiler (including an assembler) in a couple thousand lines of code.

Just the other day I transcribed an old article I had co-written for the Forth Dimensions magazine. I still like the ideas in Forth, but the stack manipulation quickly gets tedious and is very hard to read. Just look at the code examples in https://benhoyt.com/writings/forth-lookup-tables/ -- especially Search-Table. Yikes! Yes, naming things is hard, but apparently not naming them is even harder.

I just finished transcribing this from the scanned PDF, and thought it might be interesting to others. It certainly took me back! I was really into Forth as a teenager, and wrote several of my own Forth compilers [1]. It's a unique and interesting language, though most Forthers spend too much time writing their own compilers and being language zealots instead of getting things done. It's hard to believe anyone could think the Search-Table code in "Figure Five" is sane. There's more stack-effect tracking than code!

[1] For example, "Third", a 16-bit self-hosting Forth compiler for DOS: https://github.com/benhoyt/third

My dad, who was a minister by day and Forth hacker by night, got me into programming when I was a teenager, and Forth and x86 assembly were my first languages. I wrote a small self-hosting Forth compiler for 8086 DOS (https://github.com/benhoyt/third), a tiny 32-bit Forth operating system for the 386 (I guess you'd call it "bare metal" today). Incidentally, my brother used my Third compiler at his work for a few years to write test scripts for embedded systems.

I still love the simplicity of Forth, and the fact that you can get a full Forth system going in a few KB on a new microcontroller. I learned the basics of assemblers, bootstrapped compilers (though not parsers, because Forth doesn't need a "real" parser), recursion, how to implement control structures, various kinds of bytecode (called "threaded code" in the Forth world), linked lists, hash tables, and so on. I also dislike 3rd party dependencies to this day (Forth has a pretty extreme not-invented here culture).

I was really intrigued by Factor when it came out (https://factorcode.org/), as a modern incarnation of Forth, but I never really used it. By that point I had a "real" programming job and was doing absurd things like writing CGI scripts in C, until I discovered Python in the early 2000's. I stuck with Python for many years and really liked it, though more recently I've moved to Go.

I learned a lot by playing with Forth as a teenager, and I'm really grateful for the language. It was an amazing way to start programming.