Re: ADTPro beta available

["Michael J. Mahon" <mjmahon@aol.com>]

Paul Schlyter wrote:
> In article <1152667950.882952.317390@m79g2000cwm.googlegroups.com>,
> mdj <mdj.mdj@gmail.com> wrote:

<snip>

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

Exactly.

The critical thing is: whose bug is it if a Java application fails to
run on a particular system?

If it runs on all other implementations of Java (and meets the specs
for a valid Java application), then the bug is in the implementation
of the Java platform on the non-functioning system.

If it does not run on other implementations of Java (and violates the
specs in some way), then the bug is in the application.  (BTW, if such
an invalid application *does* run on some Java implementation, there is
a likelihood that that implementation also contains a bug.)

*That's* the strong test for what is a "platform".

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

I think you have a much to restrictive notion of "platform".

A more useful definition of a platform is any layer of uniformity that
enables a common market in applications.  (Unix, for example, never
quite made it to this status, mostly for competitive reasons.)

For this to be viable, the platform definition must be sufficiently
"complete" that one does not need to go outside it to write useful
applications, and it must be sufficiently "strong" that a single
testing regime is sufficient for deployment on all implementations
of the platform.

<snip>

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

In fact, .NET and the CLI create a platform whose implementations span
Windows XP, Windows CE, and other embedded Windows environments--with
the appropriate resource and functionality subsetting that is required.

This is, in fact, the problem that it was meant to solve.


<snip>

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

And, of course, networking.  ;-)

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

The fact is that for Microsoft, the CLI is an implementation tool to
simplify their own and their developers' processes, particularly the
deployment of mini-applications.

For Sun, Java was, and remains, a weapon against the dominance of the
Windows platform.

There is little truth, beauty, or sweetness in any of these approaches.
It's just business.  ;-)

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

That would be an interesting world--one not considered by the business
purposes that created the platforms.

-michael

Fast Sudoku solver for Apple II's!
Home page:  http://members.aol.com/MJMahon/

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