Re: ADTPro beta available

[pausch@saaf.se (Paul Schlyter)]

In article <1152667950.882952.317390@m79g2000cwm.googlegroups.com>,
mdj <mdj.mdj@gmail.com> 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 never claimed scriptig languages are platforms.  Therefore I don't think
Perl, Python, Ruby, or Javascript are platforms.

Otoh Java is not a scripting language.  And it's not the Java language itself
which provides the platform -- it's the JVM.

> I prefer a more rigidly defined 'platform' which encompasses operating
> systems and user interfaces myself (two things a JVM does not provide).

A user interface is not part of the platform.  If it was, it would be hard,
or perhaps impossible, to exchange the user interface to something else.

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

There's the cruical difference!  The JVM defines a binary code which
source code should be compiled to.  And in principle you can compile
other langauges too into bytecode.
 
> 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.

Indeed there's a difference between native platforms and emulated
platforms.  But the same platform (Java, Windows, MS-DOS, or whatever)
can be native in some circumstances and emulated in other circumstances.
Each copy of Windows for instance (starting with Windows 3.x and including
all 32-bit Windows versions) contains an emulator for MS-DOS.
 
>>> 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.

That's not the way I define portability.  Of course code is easier to
port to an environment where the data types don't change representation,
but that's almost like saying it's easier to not port code than to port
code.
 
>> 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.

The JVM itself (which is written in C btw....) is indeed an example of a
successful portable application.  But a lot of effort has been spent at
making it as portable as possible.

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

True - the only alternative would be several binaries, one for each platform.
The JVM itself is a good example of this - there are several versions,
for Win32, for Linux, for Solaris, for AIX, .....
 
>> >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.

That's due to practical circumstances, not principles.  The CLI runtime
could be ported to other platforms as easily as the JVM (in either case
a lot of hard work is of course involved).  But since Microsoft owns
both the CLI runtime and its host platform Windows, .NET programs runs
only on Windows (although I believe there are efforts to make a .NET
CLI runtime for Linux as well).  If Solaris had been as dominant as
Windows, the situation with Java could have been similar and there
could have been a JVM available only for Solaris.

.NET does have one advantage over Java though: .NET is a multi-language
environment - there are at least a few languages available for .NET.
I suppose that's why that environment is called ".NET" rather than "C#"....
 
> We can argue the semantics of IT terminology til the cows come home,
> but really, things are what they are.

...or we could conclude that some terms are too vaguely defined.
Perhaps intentionally -- vagueness is an opportunity for advertisers.
How big is 1 kilobyte?  1000 bytes?  1024 bytes?  And how big is
1 Megabyte?  1000000 bytes?  1024000 bytes?  1048576 bytes?  All
varieties are actually used in one situation or another....
 
>>> 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

A number of real-time OS'es running on embedded systems, for instance.  Or
a number of OS'es running on cell phones. Cell phones might be considered
embedded systems, but which share a lot of properties with general purpose
computers -- after all, cell phones do have a display and a keyboard, plus
connectors to external devices such as memory cards or serial ports, plus
(nowadays) hundreds of megabytes of memory.

I just browsed through Sun's download page for Java SE, and from the list
of OS'es, Windows CE and Windows XP Embedded were both absent.  Yes, they
are both 'current' platforms, and neither seem to have any JVM.  No, XP
Embedded does not run everything which runs on XP Home or XP Professional.

> 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

I agree with you about the practical stuff.  What I'm discussing is the
terminology.  Java's solution to the portability problem isn't "platform
independence", it's rather "platform hiding", by providing an interface
layer which looks the same on different host platforms.  In essence
this creates a new, uniform, platform - even though you don't want to
call it a platform.

Now, if we could have .NET running on other OS'es besides Windows, and
also get other languages than Java running on the JVM, things could get
quite interesting....  what about e.g. Java running on .NET, or C#
running on the JVM?



-- 
----------------------------------------------------------------
Paul Schlyter,  Grev Turegatan 40,  SE-114 38 Stockholm,  SWEDEN
e-mail:  pausch at stockholm dot bostream dot se
WWW:     http://stjarnhimlen.se/