Re: Android?Why Dalvik?
On 5/30/2011 1:43 PM, Nasser M. Abbasi wrote:
On 5/30/2011 1:09 PM, BGB wrote:
for source compatibility, yes, cross-platform GUI is a big issue.
for binary compatibility, the much bigger issue is the lack of a common
set of binary formats, as well as different CPU architectures and
operating modes.
a VM could address this.
The funny thing, is that Java when it came out, was supposed to
solve all these differences by putting a virtual OS between the
application and the OS, this way one writes to this one common
virtual OS (the VM) and not have to worry about the different
OS's below it.
But now it seems we have different virtual OS's also coming out.
So, I have an brilliant solution I'd like to suggest:
we need is a SUPER VM
A super virtual OS, is a virtual OS which runs on top of a
virtual OS.
i.e. the super VM, hides which VM it is running under, so it
runs on top of all the other VM's:
SUPER VM
Java VM, Google VM, Windows NET VM, etc..
WINDOWS, LINUX, Mac, VMS, etc..
This offourse, until one comes up with a different version of the
SUPER VM, then we go and make a SUPER SUPPER VM. So we need
to make sure this time, that we have provisions in place to
prevent someone from making a different SUPER VM.
I would like to go patent this now.
well, IMO, trying to homogenize the environment is itself a problem...
this is actually part of what I think is a weak-point of the JVM strategy:
they try to gloss over the real OS/... by basically creating a new layer
of abstractions, and wrapping everything in the new API.
to many OS's? make a "one virtual OS to rule them all" (JVM).
too many languages? make a "one language to rule them all" (Java).
sadly, this strategy is prone to eventually show its limitations, as now
the VM/framework implementer has taken on the responsibility of
providing for pretty much any major feature the OS's might provide, and
that apps might want to make use of, and the issue of what features may
and may not exist on various targets, ...
my idea was less drastic:
rather than by creating an entirely new set of abstractions, one creates
a VM which is itself better suited to heterogeneous environments.
in C, we called this mechanism "#ifdef".
a new language can likewise devise newer, ifdef-like mechanisms.
for example, in my present language, this would be done something like:
$[ifdef(SOMEFEATURE)] public void someMethod()
{
...
}
and:
$[ifdef(SOMEFEATURE)]
{
...
}
where: $[...] is the present syntax for attributes (they started out
just as MS-style "[...]" attributes, but were more recently changed due
to the prior syntax creating syntactic ambiguity in some cases).
the advantage then, is that one doesn't have to provide as much, as for
any features not provided directly by the framework, well, one can go
back to the OS.
for example, I can make Win32 API calls from my scripting HLL, not
because I explicitly implemented support for Win32 API functionality,
but more because the VM can see all of the Win32 API functionality...
granted, yes, this same functionality will be absent if running on a
different OS, say, Linux, hence the need for an ifdef-like mechanism...
was recently though thinking of the issue like "maybe, you know, my
language might need some sort of standard library...". since, as-is,
nearly everything I have been doing API-wise has basically been via
making calls into C.
if by some chance a JVM port were made of the VM, then pretty much
everything would have to redirect to the Java class library instead.
lacking a defined API of some sort, this could be a little ugly.
but, then I have to come up with what the API should look like.
I could do nested packages and classes, or I could do it more like a
pseudo C style (maybe with packages and a lot of package-level
functions). it is... a decision...
my present personal leaning is mostly to do things C style, with
classes/... for some things, but not as the main style.
but, also possible would be to just partly rip off the design of the
Java class library... Packages: "bs.lang", "bs.io", "bs.util", ...
albeit I would probably diverge somewhat WRT the "io" package,
personally as I can't see just why there needs to be so many classes in
there, and would much rather assume doing file IO in a more C-like manner...
for example:
import bs.io;
void loadSomething()
{
File fd;
string[] sarr;
fd=File.open("foo.txt", "rt");
while(!fd.eof)
{
sarr=fd.gets().split();
if(!sarr[0])continue;
if(*sarr[0]==';')continue;
switch(sarr[0])
{
case "foo": ... break;
case "bar": ... break;
default: ... break;
}
}
}
past ideas here have also included putting all standard exceptions into
their own package, but there is not as much reason to do so with my
language, partly because I can put multiple classes into a single file
and so they are less liable to clutter up the package.
or such...