Re: ADTPro beta available

[pausch@saaf.se (Paul Schlyter)]

In article <1152753763.236501.32100@35g2000cwc.googlegroups.com>,
mdj <mdj.mdj@gmail.com> wrote:

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

I could agree on that one: writing a Javascript for e.g. Firefox will
enable you to write a program which runs on Windows, Macs, Linux, etc
computers.  So that Javascript program is "platform independence" in
the same way as a Java program is.

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

Precisely!  Doing the latter is "passing the bucket" of cross-platform
development to someone else so you don't have to dabble with it.  Or
to be more specific in the case of Java: the Java program is single-
platform (runs only on the JVM), while the JVM itself is cross-
platform (there are several versions of the JVM, which runs on
different platforms).


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

Yep -- so you don't have to spend the effort making your program cross-platform.

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

Precisely!  Therefore, the burden of writing a cross-platform application
does not fall on your shoulders.

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

OK, I found XP Embedded there -- but I still miss Windwos CE.... :-)

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

By dealing with the differences of course.....

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

Interesting ... now if we could get .NET for the JVM, we coudl stack
JVM-.NET and IKVM on top of one another any number of times....  :-)

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