[gameprogrammer] Re: Stonewolf and Limbo (WAS: Re: Daydreaming, questioning....)
- From: Paulo Pinto <pjmlp@xxxxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Tue, 27 Oct 2009 17:42:07 +0100
Nice email.
Inferno/Plan 9 was supposed to be the next UNIX, right?
Cheers,
Paulo
On Tue, Oct 27, 2009 at 5:29 PM, Ethan Grammatikidis <eekee57@xxxxxxxxxxx>wrote:
> 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:
