The beauty of the BBC Micro is the stark hardware specification -- the limits are the point. That scarcity leads to different usage, different behavior, different learning patterns.
If one wants to go poking around with modern languages, multi-tier applications, color-coding IDEs, etc. there is no shortage of modern computers available.
But instead, if one wishes to learn the fundamentals of computing, and the joys of working around the limits to extract the most performance possible, I would argue the BBC Micro is a superior choice to modern systems inherently due to the low spec.
It was a mere 40 years ago that 16kbyte of RAM was a luxury item.
IIRC, Wozniak wrote Applesoft Basic interpreter in 2k for the Apple ][ ROMs. He lost the source, re-wrote it, and saved a few bytes.
Learning assembly was a necessity for the purpose of speed and efficiency (which are often inseparable). Understanding what's happening at a low level -- all the way down to the metal -- is key. Single thread. No real OS. Flat memory model, all addressable (anyone remember the fun of self-rewriting code? or direct-memory mapped graphics or I/O ?)
I've rambled enough. Hopefully I've made a point.
On the contrary, it seems you have missed my point, or at least, nothing that follows that statement directly contradicts it.
Speaking of which, you state that the BBC micro:bit (the BBC Micro was a very different computer) is good for education, which I would certainly hope, since that's what it was designed for. However suggesting that teaching assembly language to 11 year olds is a good way to encourage them to explore and engage with the platform is missing the point (of the micro:bit).
Your best chance is if someone can optimize the BLE stack to use less RAM. After all, people have written ipv6 stacks that need a fraction of that.
I imagine the main reason for going with the cheaper chip is that micropython was a pretty late entry to the list of supported coding environments, and the hardware was probably already pretty settled before the port started. Also BLE+4K of ram is probably usable in the other official (compiled) languages, and micropython does otherwise work aside from something that's a fairly advanced feature. So it would have been a tough sell increasing the cost of every board when most students and lesson plans will never use BLE and there are other languages available if they do want it/need it.
MicroPython is right out; it would almost fit Lua, but as it is it looks like your only option for independent development would be Forth.
Future versions of the device may come with 32k RAM which would be sufficient. However, until such time it’s highly unlikely MicroPython will support BLE." [1]
That's a shame. I mean, I know it can be accessed by programming the hardware directly, but for most of the kids receiving these that puts BLE out of reach, when remote sensor, remote control & mesh network type capabilities would have opened up another whole class of projects that these could have been used for.
Would another 16K of memory really have pushed the price out of range, or was this more a question of the hardware design being finalised before the software stack?
[1] http://microbit-micropython.readthedocs.io/en/latest/ble.htm...