On Fri, Dec 08, 2000 at 10:36:48AM +0000, Simon Cozens wrote:
> On Thu, Dec 07, 2000 at 10:11:11PM -0500, Bradley M. Kuhn wrote:
> > I believe strongly that we need to make sure the design does not become so C
> > specific so as to leave us where perl5 has left us: "No C compiler on your
> > platform? Sorry!".
>
> Huh? There are platforms have Java VMs but not C compilers?
> This is something I find difficult to believe. (What language does one write
> Java VMs in?)
Cross compiled on another platform.
Mobile phones (eg all the nice one using ARM chips) have a lot of software
written in C (the language). But if you're targeting an embedded device you
don't carry the entire C run time library on it (vfprintf et al).
ARM's debugger is aimed at embedded devices (such as phones); it expects
to debug a single block of code that is OS-and-software
Next to my desk here I have a book on Symbian programming which I have
skimmed. It looks very much that while you *are* writing in C++ the
language, the severe stack limitations mean that you are not going to
write something like idiomatic C++ on a conventional OS.
[you're expected not to use automatic variables on the stack, relying on
their destructors to happily clean up when you throw an exception, but
rather to register pointers to things you new()ed with cleanup systems]
But I'd expect a Java implementation for Symbian will behave much like
a Java implementation for any other "OS" [eg Unix, NT, Netscape]
(sorry, back in the theories not backed up with experiments again)
So it seems likely to me that while (eg currently) a phone or PDA will
have its operating system written in C, there won't be a full C run
time environment. And the Java Virtual Machine may well be written in C,
but only what it needs would be there.
Something like a Unix machine with all stuff essential to boot as static
binaries, a full (static) Java VM, and no libc.
My view on the language war.
1: If we initially specify the API in tied-to-1-language terms it will
constrain the future by making it hard for anyone ever to write an
implementation in another language.
In his report on Sapphire (http://www.perl.com/pub/2000/09/sapphire.html)
Simon says:
One of the great design choices of Perl 5 which appears to have been
completely and utterly rejected in the discussions on Perl 6's proposed
language is that we do things in the most general way possible.
I'd argue that we extend that approach to the design.
There have been arguments in favour of Java, but it is countered by
arguments that currently good Java compilers are not common.
On Wed, Dec 06, 2000 at 08:22:46PM -0500, Bradley M. Kuhn wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > 1) Targeting a single compiler, no matter whose it is, is a bad
> > idea. We're writing in a *language*, not for a compiler. Targeting a
> > specific compiler restricts us even more than choosing a language.
>
> I would note that if we write in Java, we aren't targeting a single
> compiler, although at the moment, the only efficient compiler for Java might
> be GCJ.
Similar concerns about the coverage of robust C++ compilers has also
been expressed. (see http://mozilla.org/hacking/portable-cpp.html for
mozilla's C++ portability guide.
Portability rule 1: Don't use C++ templates.
Portability rule 3: Don't use exceptions.
Portability rule 5: Don't use namespace facility.
*if* we find we need to stick to that, then that makes C++ a lot less fun)
The current perl source (C and macros and macros and macros) is
nearly impenetrable, and hard to maintain. Using C again could lead
to the same sort of obfuscation as a side effect of quest-for-speed
Expect to use the 1999 C standard is likely to cause portability
problems for the next 10 years or so, on the basis that as we are still
seeing the odd 1989 non-standard-ness.
There is a view that constraining ourselves to 1 compiler (whatever
language) is bad.
My view is that constraining ourselves to 1 implementation language while
designing is just as bad, and will lead to a poorer design than if we
start general, and do implementation language specifics later.
(whilst being aware ideosyncrasies of particular languages that would
make certain design choices bad).
If we can make the design more portable across languages, my opinion
is that we should achieve a design more portable across platforms
and compilers for any given language we chose to implement in.
2: Subjective opinion: If we commence writing the canonical implementation
in Java it will take us a very long time. We will spend proportionally
more time finding and circumventing nits, bugs and portability problems
between Java environments than with either C or C++. I believe this
because I am assuming that projects like mozilla have found most of the
portability problems with C++ (are there other open source C++ projects
that are as widely or more ported than mozilla? groff??) so we can
take advantage of this knowledge for C++, or perl's knowledge for C.
[I don't know of any mature projects in Java, but I confess I've not
looked]
My opinion (not based on experiment - anyone got 2 spare parallel
universes I could borrow) is that we'd actually get a Java
implementation finished more quickly if we prototype the initial
implementation in C or C++ now (and personally I'd favour C - are
the experiences of Topaz and C++ published?) and let other people trail
blaze similar projects with the *initial* implementation in Java, and tell
us the pitfalls, so that we don't use up our time finding them.
(a bit like print a googleplex
http://www.informatik.uni-frankfurt.de/~fp/Tools/Googool.html
except that I'd expect the crossover point where it is worth
getting on with it rather than waiting will be in a year or two
And we use that year or two for the initial implementation
)
Perl is designed to make easy things easy and hard things possible.
We seem to be arguing about the best method for making it *im*possible
to use anything but the initially-chosen-implementation language to
implement perl. This feels like a bad thing.
Nicholas Clark
