If the article about building a hobby OS was on a blog about making actual useful software, and framed building an OS as a reasonable subproblem of making actual useful software, I would expect lots of people to reply like that.
The blog is specifically about patterns used in game development not about game development per se. So it's about the journey, not about the destination.
Correct and one of the patterns is embedding a language. Maybe lua/js does not fit your criteria for whatever reason so it might be a good idea to know how to roll your own language.
More importantly, that you understand how the underlying language runtimes work and their call/data structure models. Most of us will still embed an existing system.
I am beyond very confident that the solution set containing embedding Python, JavaScript, AngelScript, and Lua covers just about everything in the problem set a game programmer reading that book is going to encounter.
And if it doesn't, it's not going to be improved by rolling your own.
Hi, I wrote that chapter. I also wrote the AI system for Hatsworth. There is absolutely no way we would have embedded Lua on a DS!
What we did do was write a tiny little bytecode VM as described in the chapter. The level editor I wrote[1] let designers author behavior using a little UI. It then compiled that to bytecode.
It worked like a charm if I may say so. Unlike a full-featured language VM, we didn't have to deal with strings, parsing, garbage collection, or any of that stuff at runtime, which would have been untenable on a DS.
That's really interesting, thank you for mentioning that. That's totally in my "just about", for sure--but this isn't 2008 (even the 3DS has 128MB of RAM) and this doesn't exactly strike me as the sort of book that somebody who already has a console devkit is going to be reading. "A bytecode interpreter" seems to me to be something that that guy (i.e., you) is going to have sussed out entirely, whereas somebody who actually needs a book like this is in just about every case going to be getting off in the weeds building something instead of going off the rack.
(That said, no-GC AngelScript uses under a megabyte of RAM on ARM; before I switched to libgdx and decided that I could do without supporting the Galaxy Nexus I'd spent a lot of time examining it. It certainly might be tight on the DS, but on any modern system, I think you're probably cool.)
'''In what situation would "just use linux/freebsd/etc." not be the appropriate solution to this problem?'''?