[gameprogrammer] Re: Stonewolf and Limbo (WAS: Re: Daydreaming, questioning....)
- From: Ethan Grammatikidis <eekee57@xxxxxxxxxxx>
- To: gameprogrammer@xxxxxxxxxxxxx
- Date: Tue, 27 Oct 2009 18:41:04 +0000
On Tue, 27 Oct 2009 17:42:07 +0100
Paulo Pinto <pjmlp@xxxxxxxxxxxxx> wrote:
> Nice email.
>
> Inferno/Plan 9 was supposed to be the next UNIX, right?
Thanks! Plan 9 was, yes, and both come from the same lab. Ken
Thompson was, I think, in charge of the Plan 9 project at its
inception. He was certainly involved. Plan 9 is still with what's
left of that lab, but Inferno was sold off some years ago.
>
> 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
> >
> >
> >
--
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:
