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