Re: ADTPro beta available

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

Michael J. Mahon wrote:

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

That essentially consistent frame is a fairly massive amount of
functionality, which is quite possibly larger in size and complexity
than Java itself is.

And again, there's potential, and there's *is*.
> >>>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.

Or both, yes :-)

We must consider the corollary that if you provide all the types of the
richest hardware layer, you end up with inefficient execution on less
rich hardware.

Java tends to walk the line of having the datatypes that are present in
hardware on virtually every platform, which is a pretty good.

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

Completely agree. This is actually something I would love to see. Java
unfortunately is hobbled by its (quasi) syntactic compatibility with C
style typing. Certainly much nicer models have been demonstrated in the
past (Ada for example).

One could also argue it's hobbled by picking a lowest common
denominator in the area of floating point - you don't get extended
precision types for example (although intermediary operations are
performed to the highest precision available in the hardware
environment). Not providing this leads to ineffective use of hardware
resources on some platforms, that's true, but by providing it you open
up potential inefficiency on the other platforms, so it's a tradeoff.

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

Oh but I do :-) I find it surprising that the same techniques when
applied to software systems are considered inefficient.

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

Well, it is just an implementation technique. The intermediate language
exists only to provide an abstraction which makes the interfaces
between backend and frontend common, thus allowing reuse.

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

Yes, but said platform only exists within the execution of the
compilers themselves, and isn't exported. Indeed the techniques are
similar, and you could argue that virtual machines are just
serialisations of said intermediate code with a harness to compile and
execute it at runtime. Effectively just externalising a layer which has
existed within compilers for a very long time. Do we call it a platform
once we've written it to disk and given it a name?

Also agree about the restriction of the Java language being the only
sactioned front end making the JVM more restrictive than the CLR,
although I think this is more a political restriction than an
architectural one.

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

I agree. I feel though, that while of course instruction sets are an
element of platforms, they aren't enough in and of themselves to create
one. A program that does no I/O after all, does nothing, and
instruction sets don't imply a particular I/O architecture. Indeed
these components evolve perhaps more quickly than instruction sets, to
take advantage of faster I/O subsystems.

Fairly obviously, at any point there exists an interface between one
subsystem and another, there is the opportunity to replace one of them
with an alternative that is functionally equivalent. Does this mean it
will happen? No.

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

Agreed. Unfortunately there's not a lot of actual choice out there.
Lots of possibilities indeed, but I don't see any other comparable
choices if cross platform deployment is a goal.

One solution that may become a better choice as it evolves is the Mono
project (an open source implementation of .NET). If they ever achieve a
degree of API completeness you could then argue that the CLR is a cross
platform deployment target, but for the moment it remains incomplete.
If the progress of the Wine project over the last 10 years is any
indication, chasing a moving target means you'll always be behind, and
it'll never happen.

In the end these things are not decided by what's conceptually
possible, but by what is politically or economically beneficial to IP
holders. It seems obvious that creating cross-platform tools is not on
the rader of a company whos bread and butter is selling an operating
system. Java on the other hand is motivated by keeping alternative
hardware platforms relevant in an increasingly converging market. Sun
after all, make money selling boxes, not Java licenses.

I don't see much value in theorising the potential portability of other
platforms when there is little or no evidence to suggest that said
platforms will be pushed in that direction by the owners of them.

Matt