Have had a lot of fun with TIS-100. It's a very weird architecture, but it does teach the fundamentals of low-level coding, like using a single working register, manipulating data in a simple way and using goto statements and branches for loops.
A lot of the problems are problems due to the architecture though, not necessarily hard to implement in more conventional architectures.
The article quickly goes over it, but for those who still wanna know more about the architecture, the TIS-100 is composed of nodes that can store a small number of lines of instruction code, have a working register, and have 4 I/O ports, UP, DOWN, LEFT and RIGHT. If asking for input, they will block until input is received from the specified adjacent node, and if passing output, they will block until the specified adjacent node asks for input. There are also memory nodes, introduced later in the game, to store more data.
These nodes are on a grid. Some of them are disabled, and the memory nodes' placement differs from program/puzzle to program/puzzle. Thus, careful selection of nodes and I/O ports is required for completion. I don't know if anything similar exists in actual hardware.
There's also a built-in "debugger" which simply allows you to run the program step by step and view all values, blocked nodes, and current instructions, which really helps, and possibly teaches players how to generally debug actual machine code. The programs run on a set of unit tests, and you can see which ones fail and why.
In classic Zachtronics fashion, there's graphs explaining your performance in the end, in terms of time, and space. Users not familiar with actual hardware architecture principles won't probably be able to figure out themselves how to get the best time, because most problems require use of pipeline-like instructions, due to the blocking nature of the nodes. So while it teaches tricks and fundamentals, I don't think it teaches more advanced and important stuff. And that's not a bad thing, it's a great game.
> I don't know if anything similar exists in actual hardware.
GreenArrays GA144 has a few similarities. It's an array of tiny Forth-optimized cores, with some of them having specialized (mostly I/O) hardware. Apart from a few cores that are hardwired to boot from I/O pins, most need to be initialized via a neighbor. I don't remember where I saw this, but I remember reading that a rite of passage in GA144 programming is to write a "crawler" that loads itself into all of the cores.
> Nodes numbered in green have one or two GPIO pins. Those in blue have analog I/O. Those in orange have digital I/O with specialized purposes: 001 and 701 have high speed SERDES; 705 has four pins which may be used for an SPI bus; 217, 517 and 715 have a GPIO pin whose read line is connected to one or more analog nodes for sample synchronization; and nodes 007, 8, and 9 together control two 18-bit parallel buses and four GPIO pins that may be used to control external memory chips. These and the SPI bus are of course available for other uses if desired. All nodes are suspended after reset, prepared to execute instructions coming from any neighbor node via a comm port. Six of these are also waiting for incoming signals on their pin(s) which will be interpreted as boot frames. 001 and 701 SERDES will execute instructions received; 200 listens for high speed 1-wire protocol, 300 for 2-wire synch, 708 for RS232 framed async, and 705 can boot from an SPI flash memory device.
GA144 gets mentioned occasionally, but has anyone actually played with those chips? Apparently they are available in a hobbyist-friendly form bundled with a break-out board, which is nice. It might be neat idea to try to build a homebrew computer around the chip.
Has GreenArrays scored any major sales (publicly), do we know if they have any future? It would be bit shame to see them go under.
iWarp is just one of the more recent systolic arrays. But they go back to atleast 1943 with the https://en.wikipedia.org/wiki/Colossus_computer, and there is a lot of variety and topologies...but they all work by piping data around between modules.
Yeah, in both TIS-100 and Shenzhen I/O the limits on number of instructions on a processor is probably the main thing keeping it from getting boring with straightforward implementations.
It also gets interesting when you start optimizing for time as you can get some parallel processing going and it's just a matter of syncing them for the output.
Or if you optimize for number of cells use, you need to figure out how to do multiple things in 10 instructions.
For you parents out there...what has been your experience with/advice for teaching your kids a programming language? It's definitely something I want my kids to get comfortable/familiar with early but I get concerned about over-exposing them to too much "screen time" at a young age and the deleterious effects that might have (even ones we don't know about yet).
Don't have kids right now, or any on the way, but that's something on the horizon for me so I've been thinking about it.
The guy who taught his son programming langs from early days and that son was largely responsible for the Clojure Instaparse project. The duo discussed it on the Cognicast. That topic is the bulk of the interview.
Very interesting, thank you! The father (Mark Engelberg) also designed a mass-market programming board game/puzzle, Code Master [1], which seems neat. I just grabbed a copy at Target.
I've been exposed to the question a bit by teaching a few students now (http://akkartik.name/post/mu and a couple of other posts). I'd say any screen time on a simple text-mode terminal is fine.
Though one other consideration is eye strain. I'm still undecided on that one..
I use a 43" TV @ 1.7m plugged into my x230. Bigger the better. 1080p is fine but 4k is probably a bit nicer. It's great, I can work all day, eye strain due to focussing stress is not longer a problem. I really wonder why I don't see more people using this kind of setup, especially if you are under 28 or so, using a laptop all day can contribute to myopia.
Personally I equate eye strain with too much 'close work,' which must surely also be the major impetus behind the growing prevalence of myopia in children and young adults. I read a little about it a while back. I think giving young children glasses is probably a bad idea, as they could perhaps outgrow it otherwise. Under communism (Eastern Europe) there was a different approach, would be interesting to find out more. I suppose this discussion is really for another thread.
This one, the 43", about 1.7m. So I a 50" would be about 2m away, but even more cumbersome to transport. This would give the same working area as a 25" @ 1m. The difference between focusing at 1m vs 2m is significant, it's the difference between 1 diopter and 0.5 diopter of accomodation for your eye (vs about 2 diopter working at 50cm on a laptop, or probably 3 on phone). I don't know how that relates to muscle tension or eye fluid pressure. Working all day on the 43" my eyes get a little 'cramped', but it's a world better still. I also experimented with projectors, doable, but they can have other issues, some make lots of heat or noise, or others have a soft image.
It's pretty great to learn about basic security concepts and putting them to use.
Though the registration seems like it's done by a human, manually approving registration requests, so don't be surprised if it takes forever to get an account!
I always wonder why there is no 0x10c'ish game yet (it was a game prototype set on a space ship where you could program the computer), as there was a lot of hype around it and the idea seemed really nice (https://en.wikipedia.org/wiki/0x10c).
There are some games that explore that direction (e.g. space engineers has some kind of programmable block), but no successful ones in the spirit of the original 0x10c vision (which was pretty vague and maybe the hype and high expectations killed it). I still think that one could build a great game around the main idea, but probably it is hard to balance the game mechanics between "real" programming and actual game play without alienating users that want to get into programming and actual programmers that want to play a game.
Notch cancelled it. https://notch.tumblr.com/post/58707926941/so-thats-what-im-g... is the cancellation post. He wanted to work on smaller games that could fail rather than massively hyped games where every off hand design decision comment becomes a major news cycle item in the gaming world. The attempt for a community driven game appears to have stalled out ( https://www.reddit.com/r/trillek/ ).
Yeah, I knew that he canceled it (it's also in the wiki link), but I thought it would have been picked up by other developers. And yes, Trillek seems dead unfortunately.
It's not a game, but I found it fun to write simple programs; the machine code is so limited you need to find tricks to do anything non-trivial. For a challenge, try to write 1: a program that multiples two inputs, 2: a sieve of erastothenes, and 3: a program that can sort input.
The spec for the assembler is on the wikipedia page.
I found HRM quite boring, but that is because it is just a simplified assembly language. The solutions were always obvious and there clearly was a single solution for size or speed categories. But TIS and Shenzhen I/O are much more interesting for people already familiar with assembly, because it is a different systolic architecture and because the solution design space was much larger and interesting.
I would only reccomend HRM for someone who has never done assembly.
A counter example: I've written some assembly, long ago. HRM was a taste of the fun bits. No, it wasn't hard---but it was a sequence of good tastes to remember.
Having never done assembly, but other languages, I'm really enjoying HRM. The first bit I got through really quickly, and am seeing some of your points, but it is definitely getting me thinking in a different way.
I wanted to add that Shenzhen and TIS problems have much more constraints, which makes it challenging and forces you to think of dramatically different solutions (after discovering that I ran out of instruction or data space in each module). I have literally spent a week trying to figure out how to solve some of the more complicated Shenzhen problems (and then I noticed the dev released an update that simplified those problems).
It's kinda ironic that I bought TIS-100 when it first came out, played for a few hours, lost interest, and never really touched it since. But then, later I found great fun writing actual x86-64 assembler.
This is the issue I have with Zachtronics games - while I like playing them, sooner or later I start feeling like I might as well be working on real code.
Amen to this. TIS-100 is a puzzle game that happens to use assembly language as its means of expression. The barriers it puts up are wholly unrealistic and therefore it can't really to be said to "teach assembly language" in any particularly meaningful way.
I've had some fun solving very simple problems in brainfuck. This would be an interesting choice for a programming game because how simple it is. You can learn it in like 5 minutes. And also it's very easy to visualize the state. You can watch the program move around the tape and increment and decrement cells. Try it yourself, write a program to reverse an input string.
It's a niche skill, there are applications in e.g. embedded and hardware development, security/malware analysis, performance hotspot optimization, where sometimes you'd want to go below C to asm or machine code.
On the other hand, learning some assembly helps even when you're not using assembly - it increases the understanding of how things work under the hood and helps your reasoning about performance and security considerations even when working in much higher level languages.
IMO, assembly will remain an optimal tool for writing simple programs for very small microcontrollers. Consider the ATtiny4, for example, which has 32B ram and 512B of flash for code.
If you can operate within those constraints, then you can build at a <$1 price point, and run on 2mW of power, less current than an LED. Heck, you could run the thing off of a joule thief, and pot the entire assembly in epoxy.
Fitting a pared down libC into that might be possible, but why bother? The system is so small and simple, that the rationale for a high level language doesn't really apply. Most of your code will probably just be bitbanging and setting control registers anyway.
But, most importantly, assembly is just plain fun, which is what will keep you coming back to the platform :)
Sure. Knowing what's going on at the very bottom is useful for thinking through performance issues. Huge datasets run into hardware constraints. Knowing what's going on at the bottom can be useful there too.
It's not mandatory, but it can be useful. The 3rd differential equations class may not be mandatory for a career in physics but it can be useful to understanding the foundations of the field. Learning Latin isn't mandatory for becoming an English teacher, but understanding the roots of words can be helpful.
TIS-100 looks cool but the keyboard didn't fit on my iPad. Downloaded a few other games from the provider and all has oAuth issues. Too bad - they looked good.
HRM was a lot of fun; I wrote an interpreter in C# to test the scripts and test them on a pc; thought about creating a website where people could posts new challenges and create optimal solutions; some changes to hard levels take forever in the game; I could just edit a few things and have near instant results.
Any recommendations for games that teach other programming languages? Obviously there's Swift Playgrounds. I'm an adept programmer in several languages, but would love to learn some others, but find learning from documentation very tedious, and would much rather play games to learn.
A lot of the problems are problems due to the architecture though, not necessarily hard to implement in more conventional architectures.
The article quickly goes over it, but for those who still wanna know more about the architecture, the TIS-100 is composed of nodes that can store a small number of lines of instruction code, have a working register, and have 4 I/O ports, UP, DOWN, LEFT and RIGHT. If asking for input, they will block until input is received from the specified adjacent node, and if passing output, they will block until the specified adjacent node asks for input. There are also memory nodes, introduced later in the game, to store more data.
These nodes are on a grid. Some of them are disabled, and the memory nodes' placement differs from program/puzzle to program/puzzle. Thus, careful selection of nodes and I/O ports is required for completion. I don't know if anything similar exists in actual hardware.
There's also a built-in "debugger" which simply allows you to run the program step by step and view all values, blocked nodes, and current instructions, which really helps, and possibly teaches players how to generally debug actual machine code. The programs run on a set of unit tests, and you can see which ones fail and why.
In classic Zachtronics fashion, there's graphs explaining your performance in the end, in terms of time, and space. Users not familiar with actual hardware architecture principles won't probably be able to figure out themselves how to get the best time, because most problems require use of pipeline-like instructions, due to the blocking nature of the nodes. So while it teaches tricks and fundamentals, I don't think it teaches more advanced and important stuff. And that's not a bad thing, it's a great game.
Would recommend to anyone.