in reply to Re: Re: Re: Re: Re: Re: New JAVA Specification
in thread New JAVA Specification

I agree it's mushy territory, and will become more so with Perl 6 and its distinction between compiler and VM. But the difference between the languages is not just that Java keeps the two steps entirely separate, but also that the Java language is designed to achieve dynamic runtime behavior not through reliance upon a ready-to-hand compiler but on mechanisms like typecasting and classloading.

One might view Java (and Perl 6 when people start releasing bytecode versions of their software (and you know they will :) ) as residing in an intermediate category between C et al and Perl 5 et al. That's the argument made in this article.

"The dead do not recognize context" -- Kai, Lexx
  • Comment on Re: Re: Re: Re: Re: Re: Re: New JAVA Specification

Replies are listed 'Best First'.
Re: Re: Re: Re: Re: Re: Re: Re: New JAVA Specification
by diotalevi (Canon) on Jun 17, 2003 at 20:43 UTC

    All of the languages C, C++, Java, Perl, BASIC are compiled. their source code is read by a lexer/parser and transformed into another form. BASIC (ok some forms of BASIC that I've been told do this) would be an interpreted language because it uses an iterative approach to the source - each line is individually read, parsed and executed. C and C++ are both compiled to another source code format - assembler which is itself compiled to serialized machine code targetting a particular processor. When I look at Java, Perl and emacs I see a similarity in that each compiles to an internal abstract form which is then executed by a virtual machine.

    I don't privilege the implementation of the virtual machine so that having an intermediate serialization of the compiler output separates one implementation from being scripted and the other not.

      Well okay, but then why privilege the distinction between VM and hardware? They're both targeted architectures after all. I think a critical distinquishing characteristic of an interpreted language is that the stages of lexing/parsing/emitting VM specific code/runtime are not strictly separate from one another, but the program can move between them at will via the likes of eval. In Java the separation of those steps is enforced not just in the de facto separation of tools, but in the way the language is intended to work. You compile, and only then do you run.

      "The dead do not recognize context" -- Kai, Lexx

        No... I think the VM provided by my hardware is a distinct enough component that it is a good place to draw one sort of dividing line. The distinction between compiler and execution environment is blurry when you consider the various non-(hardware)-machine code languages like Perl, Python and Java. I suppose if you wanted to be ultra pedantic you could note that hardware is also a VM because things like ix86 are actually an API to whatever the hardware actually executes which itself can be an API, etc.

        I don't think the meaningful thing is on whether the language has an eval-like construct. That is more about language design than it is about scripting language delineation. In fact, is there anything stoppping a person from implementing eval in Java? Certainly you can manipulate Java source code from within a Java program. You can execute the compiler - I'd just wonder if it is possible to load classes during runtime (and I suspect it is).