language interpreters/ interpreted languages weaknesses?

[phil]

On 2 Sep 1999 10:38:49 GMT, m.faassen at vet.uu.nl (Martijn Faassen)
wrote:

>Ian Clarke <I.Clarke at strs.co.uk> wrote:
>
>>> I think Java can compete in popularity with Perl. And Java's (usually)
>>> interpreted.
>
>> I did consider Java, however the Java source code is not interpreted
>> directly, it is compiled to Java byte code.  Ok, so right now most Java
>> byte code is interpreted, but hopefully in the future dedicated chips
>> will be available.  I am aware that Python code is also compiled to an
>> intermediate byte-code, however (so far as I know) the compiled bytecode
>> is rarely distributed without the companion source.  Whether Java (as a
>> whole) is an interpreted or compiled language is something that could be
>> debated by people with more free time than me. I personally consider it
>> to be a compiled language, as it requires a compiler.
>
>Well, that's a rather strange distinction. Most interpreted languages
>work this way. It'd be fairly easy to make a Python 'compiler' that
>makes .pyc files from .py files without immediately executing them.
>
>Java happens to *look* a lot like compiled languages like C++, but why
>insist on calling it a compiled language when it's a bytecode interpreter?
>(most of the time, with all kinds of advanced tricks, and the bytecode
>is more low level than usual, etc, etc, but it *is* bytecode).
>
Yes,
i don't understand the logic here. A compiled language uses a compiler
to produce machine instructions and requires no further assistance
from language specific tools., An interpreted language is compiled (or
not) to an intermediate format (that may or may not be machine
independent) and subsequently requires assistance from language
specific tools to run. For languages that use no intermediate bytecode
(such as shell scripts) this involves a parser/translator etc; for
programs that produce intermediate code, this requires an interpreter.

C, C++, Cobol, Fortran etc. (in most implementations) are the former.
Python, Java etc. are the latter.

JIT is an attempt to make Java into the former , SI
(SpanishInquisition) is an attempt to make Python the same. (SI
doesn't exist but nobody expected it, anyway).

Compiled languages will run faster, interpreted languages will be more
flexible and it is very likely that the "executable" will be much
smaller since they use the underlying interpreter's functions to
perform functions that would have had to be generated by the compiler.
In fact, an example of how these two schemes have been merging is
MicroGrief's MFC DLLs where a lot of functionality is found outside of
the executable. The whole thing is becoming hazy.

Imho, the basic problem with Java is the LCD of its user interface.
It's like X-Windows on valium (although that's probably a good thing).

phil.