On Fri, Jul 29, 2011 at 5:08 PM, BGB <[email protected]> wrote: > > Linden Labs tried to do similar with Second Life, but it hasn't really > caught on very well in-general. > however, most prior attempts: VRML, Adobe Atmosphere, ... have generally > gone nowhere. >
I've looked into several systems, including Second Life, VRML, and Croquet. Someone eventually explained the problem: 3D has issues with information density - i.e. unless the information in question is a visual model, it's hard to use. This makes it suitable for games, CAD, and situational awareness... but not so much for regular use. A big 3D virtual world was what I wanted at age 23. My tastes have since changed a bit. Today, I'm much more interested in distributed command-and-control, wearable and ambient computing, and augmented reality. The most significant barriers to such technology - involving composition, distribution, security, concurrency, and resource management - are the same. But I still keep the gaming issues to help filter language designs. > > potentially, messages could be delivered over an XMPP-like message > protocol, albeit ideally it would need higher bandwidth limits, server-side > scene-management, and probably a compressed and/or binary transport: > XML+Deflate, WBXML+Deflate, SBXE(1)+Deflate, or EXI. > Fortunately, there are a lot of people doing good work on the issue of message serialization. David Ryan's Argot, Google Protocol Buffers, and various other options are also feasible. I would want to choose a model suitable for real-time embedded systems, and that doesn't rely on namespaces. > > the one language I can't really readily interop with is Java > So you can readily interop with Clojure, Lustre, Oz/Mozart, and Distributed Maude? Wow, that's really impressive! > today, we cannot effectively compose, integrate, and scale frameworks, > DSLs, and applications developed *in the same* programming model or > language. Even *without* the extra complications of foreign service > integration, there is a major problem that needs solving. > these are more library/API design issues though. > No. An "API/library design issue" is, by nature, an issue that can be isolated to *specific* libraries or API designs. When a symptom is systemic, as in this case, one should seek its cause. > Problem is, many of the more interesting things I want to do would be >> complicated, inefficient, unsafe, or insecure with our current foundations. > > > granted, but expecting any sort of widespread fundamental changes is not > likely to happen anytime soon, so probably better is to "go with the flow". > Would you plant a tree, knowing that it's unlikely to grow tall and wide enough to offer shade 'any time soon'? Would you pollute a river one day at a time, knowing that the chemicals won't reach poisonous levels 'any time soon'? Would you write one line of code for a VM, knowing you won't reach something competitive 'any time soon'? What is 'better'? > many languages can generally be implemented fine on stack machines. > I did not say that there weren't many languages that can be implemented on a stack machine. > > all in all, stack machines are fairly well proven. Indeed. They are fairly well proven to be simplistic, too, as is proven by the complications surrounding concurrency, heterogeneous memory, function passing, and so on.
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
