Re: Are these all really true ?

<ludemann@expernet.com> wrote:
] During development, interpretation is often superior. My edit-run
] loop with Smalltalk, Prolog, or Lisp (even perl) sure beats the
] edit-[make]-compile-link-run loop using C++.


So, obviously, you don't care if it's an interpreter or a compiler.
It just has to generate and execute code quickly. This is not
necessarily hard to do with a compiler. But of course the execution
speed will not be as good as when your compiler takes time to
optimize things. On another hand, an interpreter can prove faster
because it can reduce the memory used through careful choice of
byte-codes (for instance). And when the semanic level of the language
is high enough, compiling doesn't make much sense since the speed
depends a lot more on the speed of the library than on the speed of
the generated code (Perl is often faster than C code on regexp stuff,
for instance, and compiling Perl wouldn't make it go much faster).


] Multi-TASKING (multi-processing) is better. Multi-threading is an
] ugly hack because most OS people don't know how to do fast
] multi-tasking systems (it can be done: one high-performance telephone


I have to disagree: multitasking is just what OS people have found to
overcome the widespread use of unsafe languages like C. With a
strictly typed language, the "address space separation" can be had
through compiler checks.


On another hand, multitasking is a pain since it only allows "flat"
messages between tasks. A multithreading system where the type system
makes sure other people won't destroy your data, you can take
advantage of the shared address space to send structured messages by
just sending a pointer.




Stefan
--

Return to the comp.compilers page.
Search the comp.compilers archives again.