[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ADTPro beta available

mdj wrote:

Paul Schlyter wrote:



Not if you write the software in a language designed for cross-platform
use. This is the whole point of Java - a cross platform API + a virtual
machine.


:-)

Check out:  http://www.skch.net/columns/java2.html



Yes, yes :-) The definition of platform can be pretty much widened to
that point if you so choose. This is essentially saying that a platform
is any execution environment that allows software to run. Under this
definition, Perl, Python, Ruby, etc. are all platforms. Personally, I
have issue with labelling every scripting language plus its runtime a
'platform'. I prefer a more rigidly defined 'platform' which
encompasses operating systems and user interfaces myself (two things a
JVM does not provide).

To me, there is essentially no difference between Java and
Perl/Python/Ruby. You have a language, plus a runtime system. Java is
different only in that it is compiled rather than interpreted.

If you want to stick with the highly ambiguous term 'platform', fine.
But at least admit that there is a big difference between a 'platform'
that leverages a software platform to provide functionality, and one
that leverages a hardware platform.


Actually, the primary difference is just one of layering, which
all modern systems have up the wazoo.

Each "well architected", "complete" layer is a potential "platform"
layer.  You argue that Java is not sufficiently "complete" to form
a platform, but if the underlying, complementary environments all
provide an essentially consistent "frame", then the layer is complete
"enough" to allow applications to be deployed--which is a pretty fair
degree of completeness.


In turn, the language itself is defined to avoid being bound
to architectural limits.


<g> .... if so, why does the Java language explicitly prescribe the
sizes and bit patterns of its fundamental data types?  An int is *always*
a 32-bit signed 2-complement integer, a double is *always" a 64-bit
IEEE floating-point number .... etc etc.  These architectural limits are
directly hardwired into the language itself !!!!!  Do you want to do
128-bit number crunching efficiently, on hardware which directly supports
it?  Forget about doing that in Java....



Very true. This is actually the whole point. If you can guarantee a
datatype is always the same, your code becomes more portable. Less
efficient? Perhaps. That in other languages the definition of data
types can and does change is one of the issues with those other
languages.


But by making such "guarnatees" you are essentially either limiting
the underlying hardware layer or enforcing a prohibitive inefficiency
in simulating the specified, but non-native data types.

There are other ways to specify data types that can be representation-
independent for *almost all* cases.  Data types used to interface to
an external standard are the exception--there specifying representation
is the only common ground.

If overflow, for example, is treated as an exception, then the length
of a data type and even its radix is not an issue--only the range of
values that it supports (in the case of integers).  Floating-point is
another story--but even that can be abstracted (in fact, the ability
to abstract from the details safely was one of the motivating factors
in the definition of IEEE floating-point).

For example, who needs to know how "true" and "false" are represented
until they are about to make their way out into the external world, and
that mapping can be completely programmatically defined.

Some data types need to be ordered, so that they can be sorted usefully
to the external world.  For this reason, a collating sequence must be
definable.  If characters pass back and forth to/from the external world
often enough, *fixing* the representation may be preferable to having to
translate between the internal and external worlds, as we have chosen to
do with ASCII and Unicode, but this is an implementation choice.


The entire point of it is to avoid the complexity you refer to. Rather
than it be done for each and every cross platform application, you
simply leverage a cross platform API that already exists. In the case
of Java, you also compile your code to a cross platform 'instruction
set' which is then translated or compiled as appropriate on the host
platform.


Indeed, single-platform development is simpler than cross-platform
development - we're in full agreement here!  Java avoids cross-platform
development by "porting" the entire platform, rather than the application.
This means simpler development of course, but it also means a limitation
to whatever the JVM platform offers.





But this method is not limited to the JVM.  Any platform can be made
"cross-platform" in the same way - by porting the platform to another
platform through emulation.



Indeed. But 'platforms' designed to leverage existing software
platforms have a lot more flexibility and potential integration with
the host environment don't they? Carving off a chunk of disk and
running another system in a box might "work" but it provides a terrible
user experience. This is an important distiction. The JVM is a VIRTUAL
environment, not a hardware environment. It was designed to be ported
to other platforms, and it's been done.


Perhaps you don't appreciate the degree to which all supposed "hardware"
platforms are *already* virtualizations of the underlying resources!

Today, almost no one is really "on the metal" except embedded system
programmers.  Even the vast majority of OS code is written to run on a
virtualization of the hardware provided by lowest-level code.

<snip>


Java is
used today to write programs that run on a multitude of platforms.


No - Java is used to write programs for the JVM platform.  The JVM platform,
in turn, runs on several other platforms.



:-) I find the distinction frankly a little silly. Both my statement
and yours are in essence correct. I agree with you, in theory, however
it's practice I'm interested in :-) I write Java program, it runs on
basically anything. I write .NET program, it only runs on Windows. Not
Macs. Not Linux boxes.

We can argue the semantics of IT terminology til the cows come home,
but really, things are what they are.


Whoa!  That's a *lot* of semantics!

That's like saying that compilers (for several languages) that generate
a single intermediate code, which is processed by several back ends to
run in several different environments, is "just an implementation
technique".  In fact, it replaces a problem of NxM complexity with one
of N+M complexity!  And in the process it completely standardizes the
syntax accepted on all platforms!

This is accomplished by defining an abstraction layer--the intermediate
language--which creates a "platform" for all the front ends to run on.

In fact, it is quite similar to the Java platform with the sole
exception that the Java language front end is the *only* sanctioned
user of the Java execution environment.  In this way it is more
restrictive than the "Common Runtime" environment used by C#, VB, and
other languages in that suite.

Most designers of intermediate languages do not think of themselves as
platform designers, so they frequently do an incomplete job of creating
an abstraction, but, even though many such efforts are imperfect, they
are still examples of what *could* have been perfected, had the benefits
and potential been properly understood.  (I actually proposed using a
generalization of U-code as a universal machine language to create a
multi-hardware-system platform in the early 1990s!)

As an erstwhile computer architect, I can also say that the machine
language of a system is also such an abstract interface, which, if it
is successful, will be implemented many times in different ways in
various hardware technologies.  It is only the abstraction of the
architecture that creates the illusion that all these machines are
"compatible", since the underlying hardware is often quite different.

So even hardware uses an abstract definition layer to create a virtual
platform on which all other software runs.  (In hardware, much of this
work is done by an even lower level of software, namely firmware or
microprogramming, or, in RISCier machines, in PLAs or hard logic.)

Abstraction is inescapable!


Yes
they'll only run where there is a JVM implementation, however there
exists no platform I'm aware of for which such a JVM does not exist.


You're posting in comp.sys.apple2 and you're not aware of the Apple II
and its OS'es?  OK, here they are: Apple DOS, Apple ProDos, Apple CP/M,
Apple Pascal, Apple OS/9 - none of them have any JVM.



Obviously I meant 'current' platform :-) Let's have a list of current
platforms for which there is no JVM

Look, I acknowledge there are a lot of things about Java that suck, but
really it all comes down to comparison of practical available
alternatives. If there was another way to achieve the cross-platform
functionality you get with Java with similar or better time investment,
I'd be all ears.


Java is only one of the better *de facto* choices--clearly there are
many other possiblities, depending on your long-term priorities, and
any of them could be implemented given sufficient will and marketing
effort.  ;-)

-michael

Parallel computing for 8-bit Apple II's!
Home page:  http://members.aol.com/MJMahon/

"The wastebasket is our most important design
tool--and it is seriously underused."