On 7/29/2011 7:06 PM, David Barbour wrote:
On Fri, Jul 29, 2011 at 5:08 PM, BGB <cr88...@gmail.com
<mailto:cr88...@gmail.com>> 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.
yeah, making it not lame is itself a difficult problem.
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.
possible, but those are not problems which can be readily addressed.
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.
XMPP doesn't depend directly on namespace prefixes (an XML subset is used).
the merit of XMPP is that it allows transporting fairly arbitrary
messages, which is fairly useful.
its main downside though is that textual XML uses a lot of bandwidth and
imposes a 1.5 kB/s transfer limit (past this point and throttling is
used), limiting movement updates to about 1 update per second.
however, if the protocol were compressed and bandwidth was uncapped,
then it could be a bit more useful.
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!
well, of the languages I have tested against.
to say that I can't really interop with Java doesn't mean that all other
languages will work automatically.
but, pretty much anything with a strong C FFI should be reasonably
possible to interop with, but there is more of a problem with languages
which lack a good C FFI. this is because, for the most part, the C ABIs
(and some limited aspects of the C++ ABIs) are the substrate on which
much of the rest is built.
so, roughly this excludes languages with poor C interop.
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.
it is a generalized issue of API designs, or more correctly, the common
lack of good external APIs.
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'?
why would these need to effect ones' decisions?...
competitiveness may not actually matter, since ideally one will write a
VM to serve ones own needs, when they have a use for it. these sorts of
things are not done (entirely) in a vacuum.
but, anyways, the future will come along when it does.
a lot more is likely about doing the right thing at the right time, and
if now is not the time, then when? one can likely get a lot more useful
doing what is needed for today, and leave what is needed for tomorrow
for another day.
not that one shouldn't prepare for the future though, but if and how
things will go generally can't be reliably predicted far in advance, but
one can create contingencies for various possibilities. life exists in
the here and now, and things that have not yet happened don't yet exist.
like, it is the whole idea behind "Carpe Diem" and similar.
now, as for things like poisoning rivers/... this would be irresponsible
and against a good sense of ethics. it is not about if/when this will
matter, but that this would not be *the right thing to do*.
it is like, certain things remain right/wrong or moral/immoral
regardless of if/when the consequences may decide to show themselves.
What is 'better'?
well, dunno.
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.
those are generally problems with other aspects of the implementation,
and not the use of a stack-machine model in the IR.
both heterogeneous address spaces, closures, etc..., work fine with a
stack model.
under what basis do you think they are problematic?...
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
