Re: ADTPro beta available

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

Paul Schlyter wrote:

> I never claimed scriptig languages are platforms.  Therefore I don't think
> Perl, Python, Ruby, or Javascript are platforms.

Perl and Python at least, can be compiled into a bytecode
representation. Does that change anything?

Javascript is an interesting one - while Javascript itself isn't a
platform, many would consider a web browser to be a platform.

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

:-) Just wait while I casually unbolt GDI+ from this machine and drop
an X server on instead....

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

So by your definition, writing code yourself to get around portability
issues is cross-platform, but leveraging someone elses already written
solutions isn't?

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

Indeed, the effort goes in there, so you don't have to expend the
effort yourself. It's rudimentary abstraction, nothing more.

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

Yep, they do the work so you don't have to.

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

The CLI itself is quite easy to reimplement, and has been many times.
The API on the other hand, is quite difficult to port, since it relies
heavily on Windows functionality. This is the biggest barrier to having
a completely non-MS .NET implementation. The Mono guys are plugging
away at it though :-)

<snip>

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

http://java.sun.com/j2se/embedded/offerings.html

:-)

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

Ha! how can you be independant of platforms without hiding differences?

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

Well there's Mono which is a decent implementation of the CLR, but much
of the framework needs to be written.

You might however find this interesting:

http://www.ikvm.net/

Matt