ES is a fairly interesting looking open source research OS created by Nintendo. Runs natively on x86 (and qemu of course), kernel is written in C++, uses an ECMAScript interpreter for all of the userland, uses Cairo for graphics, and even has a port of Squeak.
Why on earth? And why using such choice of technologies?
Squeak? Javascript? FAT as filesystem? this is horrible!
Doesn’t seem at all like a wise choice for a next-next-gen system.
Sony had already too much trouble forcing developers to use Linux as developer platform and only valid devkit, so most ended up using CodeWarrior.
Apple had already too much trouble forcing users to ObjectiveC.
Not going to work!
Have you read some of the doc provided in the link? it seems that one can build component using c++. FAT is a simple and small file system that can be easily used on small devices. With JavaScript, because of its interpreting nature, it helps developers rapid testing i rekon. I don’t know much about squeak so it would have some advantages on the device i guess. however, i guess there would be much c++ based development would be going on later. keep an eye on this if you are interested but telling that it won’t work. please. grow up.
Actually, this doesn’t look like they’re going to use it for more than experimentation. Just look at the licence terms, they’re far too liberal
I must agree that it looks like a weird technology, though.
Simplicity and broad adoption.
(yeah, broad adoption; Squeak is *big* at Disney.)
What makes you think it’s a next-gen system? It’s a research system. And you know what my suspicion is? That’s Nintendo answer for homebrew apps on the Wii.
FAT access for the SD card: check.
Interpreted languages to sandbox the development away from the “crown jewels” (i.e., the encryption keys), and to ensure portability between the development environment and the target environment: check.
Use of a graphics library that can make great use of hardware acceleration: check.
But of course I’d rather have Lua instead of Javascript; Lua is much, *much* bigger among the game development community, so it’s definitely a wiser choice. Maybe in the near future, who knows?
?!
I think you’re mixing the facts here.
Uh… Noooo? The only Carbon apps you see nowadays on Mac OS X are those based on large existing codebases that started back on Mac OS 7, like those by Adobe and Microsoft, and apps ported over from Linux and use the eventual toolkit that doesn’t bind to Cocoa (like Qt), but those are really few and far between (and to be honest I’ve never seen a single native Mac OS X app based on Qt).
Not a *single* interesting Mac OS X-exclusive app is written in Carbon.
Careful, you’re talking about Nintendo here. You know, that little company in Japan that simply prints money out of a little thing called Nintendo DS, as if the Wii wasn’t enough?
Edit: the obligatory Lua pimping
Edited 2007-11-30 20:21
I think their choice of JS bindings may be related to their other choice of using (WHATWG/HTML5) CanvasRenderingContext2D (from <canvas>, initially from WebKit IIRC). Not sure which influenced which, though.
With some small bootstrapping, you can actually write something that will run in a browser, then copy the code over to this thing – using whatever debugging utilities that already exist for browsers.
JS as a language is.. well, at least more widely available than <canvas>. (Think Acrobat, Flash, WSH, kjs…) I have no idea if they wrote their JS interpret from scratch, though; it sure looks like it.
> Not a *single* interesting Mac OS X-exclusive app is written in Carbon.
Finder?
I thought we were discussing 3rd party apps? Because I assume Apple itself would have no problem with either languages. Or even Pascal, were it supported on OS X, for the matter.
Anyway, the point is not about Apple, it’s about the marriage between language and functionality. For all I care Es could support a single language, and it could be BASIC, Forth, Lisp, Eiffel, Haskell, #!/bin/sh, C++, Dylan… All those languages by themselves amount to rigorously nothing, but the tools written around them to enable sane development, these do.
For a console-restrained OS with a focus on homebrew games (remember, a wild guess), I think something like Java makes a lot more sense than Smalltalk (and people that know me know I’m a strong proponent of Smalltalk, although I think polishing Squeak with more and better antialiasing wouldn’t hurt, and neither would an improved dynarec), but not your average Java implementation, mind you. People would have to remember it’s a constrained, embedded environment, and the current “best practices” in RAD that ignores tight memory management are simply non-starters there.
While we’re going wild with suggestions and hypothesis here, I’d vote for porting Blender and its gaming engine, albeit with Lua instead of Python. That would be way cool.
It’s a research system, not a console system. All sorts of crazy things can be used in a research system.
(And it runs on x86. That alone should tell you it’s not for a console system…)
Edited 2007-11-30 20:26
NetBSD is capable of running in x86 and even on Dreamcast (Hitachi SuperH RISC CPU), with a gazillion platforms inbetween.
They can work on x86 while developing and then port it to a different platform.
Edit: grammar, grammar
Edited 2007-11-30 20:38 UTC
It’s a research system, not a console system
That doesn’t imply or answer anything, the question is Why does nintendo do that and with such choice of technology? To me it seems more like someone playing around in one of the Nintendo R&D houses, as the technology has nothing to do with anything i’ve ever seen from them.
btw: I’m an official developer.
I dunno. I think the mix of technologies makes a lot of sense. Javascript is quite a reasonable language for writing userspace stuff that doesn’t need to be fast. And Squeak is an excellent platform for doing GUI stuff in an easy-to-use way, and supporting it gives you quick access to a well-developed, portable GUI system.
“Why on earth? And why using such choice of technologies?
Squeak? Javascript? FAT as filesystem? this is horrible!
Doesn’t seem at all like a wise choice for a next-next-gen system.”
Yeah. And what’s up with the Wii? Such a weak video card? Horrible CPU? The specs are nothing compared to the XBox 360 and PlayStation 3! This doesn’t seem like a wise choice for a next-next-gen console. The Wii will fail horribly, I tell you!
What? They sold how many millions of those things? Oh, never mind.
Would you start your research operating system by supporting ZFS, Ruby and .NET? All this stuff is irrelevant as what matters is extensibility and the possibility to implement other stuff later.
I wouldn’t be surprised if it was meant as a possibility for their next-gen system. Mainly because I suspect that they are at least considering AMD’s spider platform for it. By the time for the next-gen nintendo system rolls around, a spider-on-a-chip solution will likely be available, along with the fact that the Wii’s current hardware at 33nm will probably be cheaply available to provide backwards compatibility, since I suspect that’s what their next handheld will be based on. That or they’ll do something I really don’t expect like an intel based handheld.
Reading from Wikipedia, it appears that SQUEAK is a really really powerful language (a Smalltalk dialect)…
What about game development in Squeak, with ES as the underlying os?
…to invest time on something like this.
But it certainly looks like a quick and easy system to set up and operate.
AROS? Just wondering. Nintendo + Amiga magic.
Oh, it’s Google translation from Japanese
http://translate.google.com/translate?u=http%3A%2F%2Fne…
“Es namespace shown in terms of such a device in addition to the event and the console device you can find. Each of these events manager and manager console by dynamically namespace registered by the device.”
“ECMAScript as garbage collector working language interpreter for the liberation of memory and virtual machine can be completely leave the system resources are freed KANARAZUSHIMO interpreter side can not trust you.”
YOU HAVE NO CHANCE TO SURVIVE MAKE YOUR TIME!
Squeak EToys are a means to allow children to easily develop their own programs:
http://www.squeakland.org/
Sun have their own JavaScript kernel called lively:
http://research.sun.com/projects/lively/
which can be run by clicking on the “Enter Lively Kernel” link.