[gameprogrammer] Stonewolf and Limbo (WAS: Re: Daydreaming, questioning....)
- From: Ethan Grammatikidis <eekee57@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Tue, 27 Oct 2009 16:29:21 +0000
Sorry for the late reply, I've been too busy to keep up lately.
On Mon, 19 Oct 2009 13:18:41 -0500
Bob Pendleton <bob@xxxxxxxxxxxxx> wrote:
> First off, the majority of languages (I almost said *all* but I do not
> know *all* languages) were designed around the idea that resources are
> scarce. Think about C and C++. C was designed in the '72 and C++ was
> designed starting in '79. In '79 I bought 16 kilobytes of ram for my 2
> megahertz z80 for $110 which is $327 in 2009 dollars. In '72 I could
> not afford to buy 16KB of ram. It was too expensive.
A side thought really, but I want to say I'd be very careful about
considering C++ inherently efficient. I'm told the first C++ compiler
at AT&T compiled 'Hello World' to a 2.1 megabyte executable, and today
g++ doesn't manage to get it much under half a megabyte. I can only
assume C++ was 'designed' on some of the biggest mainframes around. I
don't want to get too deeply into this, I just want to warn anyone
even vaguely considering language design not to take C++ as an example
of an _inherently_ efficient language.
I _do_ think it's worth giving nominal consideration to efficiency
even when it's not a major concern. A little inefficiency in the
wrong place can multiply itself over and over again until it becomes a
show-stopper.
Alright, with that out of the way, on to the good stuff.
>
> What I want is a language that is designed to make use of massive
> amounts of memory and hundreds or thousands of hardware threads that
> contains all the libraries I am likely to ever need and the ability to
> easily integrate libraries I didn't imagine I would ever need.
"a language that is designed to make use of [...] hundreds or
thousands of hardware threads". I read this and Limbo popped into my
head. Limbo isn't exactly Stonewolf, but I suspect its syntax and
most aspects of its design may provide very useful pointers. More
below.
> I want to make
> executable code a true full fledged data type so it is easy to
> replicate it across a "cloud" and to make it part of a class in a
> database.
The one point I'm not sure Limbo covers. However Inferno (the
operating system to which Limbo is tied) may cover this well enough.
Again, see below. :)
> I want unicode to be built in from the beginning and not
> tacked on as an after thought.
Limbo again.
> I want message passing and
> multithreading to be so intrinsic in the language that you get them
> without even thinking about it.
Limbo! :)
So in summary I think Limbo is well worth looking at as something
pretty darned close to what you're trying to achieve with Stonewolf.
Limbo isn't exactly on target. It compiles to bytecode and was
designed that way to save RAM. (This is still worth something in an
embedded environment, and so Limbo has found its niche there.) Limbo
is not object oriented, which is perhaps a bigger problem, although
Inferno provides such free and unified inter-process and inter-machine
communication that this may not matter. It makes little to no
distinction between communication between processes on the same
machine and communication between processes on seperate machines. A
task may be designed as a large number of small programs which can be
distributed however the resources lie. However network latency may,
of course, throw a spanner in the works.
I mentioned above that Limbo is "tied to" Inferno. I don't think
there are any Limbo compilers apart from that included in Inferno.
Almost all of Inferno is written in Limbo, so you get one, you got the
other. Now, Inferno will run in "hosted mode" on Windows, OS X,
Linux, any unix, as well as natively on a range of architectures which
ought to make Java weep. (Pardon my bias, please. :) Inferno awes me
somewhat while Java fails to.) Given a not-too-demanding program I
could run the same application in hosted-mode Inferno on my quad-core
Linux PC as in native Inferno on a Nintendo DS or even lesser
hardware. Inferno on the DS is a lot more practical than Linux on the
DS, but I'm getting away from the point.
I really think anyone who wants to talk about 'new technology' should
take a look at Inferno's model of servers, namespaces, and its network
protocol: Styx. Servers: Any process can serve files and take special
actions based on what's written to thos files. The system is set up
so that such a file forms a very efficient pipeline. Namespaces: each
process may see a different view of the filesystem, including
differences in what servers are available. Styx: Any file may be
served to a remote machine.
It was designed before the cloud computing came on the scene, but it's
a remarkably flexible system and much more easily understood by the
casual coder, while still containing some impressively deep
implications. For example, and disregarding network latency briefly,
I think you could add a game engine - even a crude one - to Inferno
and instantly have a kind of programmer's Second Life! Better than
Second Life in some ways: far more flexible and it could be made
suitable for non-programmers with a build system written in Limbo.
Users could have a choice of build systems, and the advantages rack
up. Restricting namespaces would provide a fair level of security not
easily possible on Windows or any unix.
On the down side I don't think object permissions will come out right,
not without some magic code which could be worked around far too
easily. Computers don't really do "no copy." To be practical some
extra networking code woud be needed. Styx is TCP-based so some UDP
solution would be needed for avatar and object movement and perhaps
objects should have the option to send minor updates as UDP. Now I've
written that out it doesn't seem too complex either...
This example is actually the reason I subscribed to this mailing list
in the first place. :) I was actually astonished when the idea came
to me, it really set Inferno apart from to crowd, in my mind, since
I'm sure its designers had no idea of such a thing when they made
Inferno and yet it seems so simple to do. Well, I tell a small lie, I
was thinking of Inferno's 'parent' operating system: Plan 9. Plan 9
shares the same 'servers, namespaces, Styx' model as Inferno except
Styx is called 9p2000 and the OS is written in C. (It used to be
written in Alef, which is like C but with better facilities for
parallel programming, but it wasn't worth the effort of maintaining
the Alef compilers.) I prefered Plan 9 and C for reasons of percieved
efficiency, but Rob here makes an _excelent_ point about efficiency of
programmer time, so perhaps from now on I should look more closely at
Inferno itself. :)
Well, I can't really post all that without at least one URL, so:
Inferno main site:
http://www.vitanuova.com/
Inferno on Google Code. This page is probably more interesting to us
coders than the main site.
http://code.google.com/p/inferno-os/
--
Ethan Grammatikidis
Those who are slower at parsing information must
necessarily be faster at problem-solving.
---------------------
To unsubscribe go to http://gameprogrammer.com/mailinglist.html
Other related posts:
