3 ms·
I've never really understood the desire to have high level programming environments for the micro:bit - blocks and such. I've nothing against those sorts of env
by omnicognate 5y ago
I've never really understood the desire to have high level programming environments for the micro:bit - blocks and such. I've nothing against those sorts of environments themselves. My son has hugely enjoyed Scratch and I think it has been educational for him. I just think it's missing out on what makes micro:bit awesome.
With a high level programming environment a Micro:bit is just a very limited, cheap bit of hardware you can do a few fun things with. There's novelty to it but it can do much less than the desktop computer you use to program it.
But the Micro:bit is an absolutely genius bit of kit for exploring low level programming!
AIUI, the Micro:bit has 2 microcontrollers on it, not one. The one you program is actually the less powerful of the two. The second microcontroller, which you can't program, is there to control the USB port, implement mass storage and feed anything you put there to the programmable microcontroller.
This means you have an extremely simple RISC chip, with extremely simple hardware (leds, beepers and stuff) attached that you can control, and you can program it in assembler or C just by copying files to USB mass storage.
I haven't started with this yet, but when he's ready I plan to explore this in detail with my son. It seems like a perfect opportunity to explore how computers actually work and how software and hardware interact, without the huge complexity of more powerful hardware.
I mean, this should be educational for me!
This book looks like a potential starting point (not published yet, though): https://spivey.oriel.ox.ac.uk/baremetal/Bare_Metal_micro:bit https://spivey.oriel.ox.ac.uk/baremetal/Bare_Metal_micro:bit
- jazzyjackson 5y agoI've run dozens of summercamp sessions and afterschool classes where we introduced Arduino to all ages - I don't see how block or frane based editing is incompatible with learning low level hardware - the C-ish code is already removed from how "computers really work", you're left with pin labels, read and write, conditionals, loops, and subroutines. There's an extraordinary variety of applications to build with these tools, game controllers, music makers, HID, sensor networks... I took a few classes that get into the nitty gritty of registers and bitmasks, and the outcome after all that trouble was to bitbang a serial connection, I wasn't really inspired to keep digging in that direction, although now I'm trying to teach myself 6502 assembly because I am inspired by how far you can go on such ancient hardware. anyway, most of the arduino and micro:bit code I've seen in the classroom consists of taking code someone else has written and making just a few changes. I'd say 1 in 50 of our students moved on to understanding how to write programs from scratch - if Strype lowers the barrier of entry so you don't have to learn arcane syntax or the meaning of "void", I think it will be hugely successful in lowering the cost of software development by embiggening the talent pool, making a more accessible on ramp to being productive with computers.
- rtpg 5y agoI think a huge power in frame-based programming, that is super under-appreciated, is how you can make errors a lot more obvious by limiting input. Left side is a number? Right side's gotta be one too! You can also stop `if foo = bar` style errors as well. Of course those errors show up anyways when you run a program, right? But being shown the error in context quickly, and having UI space to be able to add links to documentation and other details is a real boon to learning in my opinion. And you can provide autocomplete that only provides "good" options. This can help with discoverability (though it's tough to get a "why is this not showing up" answer, granted). Imagine if our shells actually worked like this! There's reason everyone installs all of the cool bash/zsh completions for all these tools.