Re: ADTPro beta available

["mdj" <mdj.mdj@gmail.com>]

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.

> >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.

> >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.

> >> That's not the path chosen by Java though.  Java is single-platform: it runs
> >> only on the Java platform.  It creates an illusion of being cross-platform
> >> by having the Java platform emulated on various other platforms.  But by that
> >> method, you can also make MS-DOS programs "multi-platform".
> >
> >Nonsense. There is no 'Java platform' in the sense the term is used for
> >every other platform.
>
> :-) ...    http://www.research.att.com/~bs/bs_faq.html#Java

Of course, Bjarne uses the same definition as you, and I disagree with
his as strongly as I disagree with yours :-)

I do however wholeheartedly agree that languages owned by corporations
is a Bad Thing(tm).

> >All functionality is delivered by the platform the Java program is
> >running on, except the virtual machine, which is just a virtualised
> >processor.
>
> You forgot the *quite* *lage*, and growing, class library of Java.  Or
> are you saying that the Java class library offers no functionality?
> If so, I strongly disagree with you.

Of course not. However this code inherits the cross-platform benefits
of Java.
I would agree that such libraries, once compiled, are locked into the
Java environment and only usable with it, but really, the *only*
effective solution to this problem is source level access, as the open
source community is proving.

> >You could create a standalone platform that could run Java programs if
> >you like, and this has been tried before (without success).
>
> Yep -- these efforts repeated the earlier failures of Western Digital's
> "The pascal Micro Engine" (which executed UCSD Pascal P code directly
> by the processor - a processor which, needless to say, contained a lot
> of microcode) as well as Intel's first 32-bit CPU, the iAPX-32 (which
> executed an Ada variety of P code -- it too failed for the same reason:
> slow execution.  The 80386, which was released a few years later, ran much
> faster).
>
> >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.

> >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.

Matt