Re: interpretive vs. compiled

thomas.mertes@xxxxxx writes:

On 19 Jan., 22:31, p...@xxxxxxxxxxxxxxxxx (Pascal J. Bourguignon)
wrote:
Moreover, compilation or interpretation is mostly an orthogonal
question to the speed. There are interpreters that execute code
faster than the code generated by some compiler. (For example, an
interpreter executing on a given processor might still execute your
program faster than the code compiled for a virtual machine executing
on that same processor).

IMHO comparing the speed of an interpreter (probably written in a
compiled language) running on the bare metal with compiled code
running on a virtual machine is an unfair comparison.

Actually, in general dynamic programming languages are used to build
more complex applications than static programming languages.

I doubt that. E.g. Operating system kernels (which are usually
written in a compiled language) are famous for being very very
complex.

For example, the operating system of the Deep Space 1 RAX experiment
is written in Common Lisp.
https://www-auth.cs.wisc.edu/lists/cs-announce/pre-2004/msg00464.shtml

Of course, the operating systems of the Lisp Machines were written in
Lisp, including TCP/IP stacks, NFS and X servers. (By the way, why do
you think X _symbols_ are 29-bit integers and not 32-bit?).


When writing complex applications it is very important to do a
careful program design. A heap of kludges does not help when the
problem is complex. Usually the development costs are tiny compared
to the maintenance costs which come later.

Indeed. That's why it is very worthwhile to use a high level
programming language. I mean a dynamic programming language.

For this reason it is important to have deliberate concepts before
you start to write code. It is a good idea when this concepts are
also documented as part of the program. A program consists of code
and data and the concepts of both should be documented. It is a big
mistake to omit the description of the data concepts.

It is also a fatal flaw to lose these important data concepts into a
sea of implementation details a low level programming language forces
on you.


Although the
data structure is implicitly defined in the code it should still be
described explicit. This improves the readability considerably.

Indeed. That's why you need all the means to abstraction possible.
High level and advanced dynamic programming languages such as Common
Lisp let you use data abstractions, functional abstraction,
metalinguistic abstraction, and syntactic abstraction (macros). Most
programming languages only provides tools to help you with the first
two kinds of abstraction.

Have a look at:

Structure and Interpretation of Computer Programs
http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-4.html
http://swiss.csail.mit.edu/classes/6.001/abelson-sussman-lectures/
http://www.codepoetics.com/wiki/index.php?title=Topics:SICP_in_other_languages
http://eli.thegreenplace.net/category/programming/lisp/sicp/


Keep in mind that programs are much more often read than written.
Everything that helps to make a program readable is an advantage.

There are studies about the costs of errors in big programs.
In general:
- Errors which happen earlier are more expensive than errors
happening later. E.g. A design error is more expensive than
a coding error.

Yes, that's why you must try out your design the as soon as possible,
therefore you don't want to lose time with a low level programming
languages requiring you to specify all kind of low level details such
as memory management or static type declarations.

- The sooner an error is found and fixed the cheaper. E.g. A
syntax error found at compile time (or at startup time in an
interpreter) is cheaper than a runtime error (which probably
needs a debugging session).

Indeed.


Conclusion:
If a language is more permissive (no declarations, no types ...)
you get the subjective impression of higher development speed.
But in the end exact the contrary will probably happen:
- When you rush into coding the probability of design errors is
higher.
- Without compile time checks you will probably find the errors
later.
- With the omission of data documentation in the program the
maintenance costs will grow.

For that reasons the core of many comercial big applications is
written in a compiled language.

You got it all wrong in your conclusions.



When I look at the job marked I see two big areas where developers
are searched for big applications: Java and C++. Both are compiled
languages which would not be seen as dynamic programming language.
[...]

I don't see that most projects written in Java or C++ are 100%
successes. On the contrary, there are often reports of big failures
using these programming languages.

--
__Pascal Bourguignon__
.

Relevant Pages

  • RE: 3-D graphing software?
    ... Thanks, I'll look into Scilab. ... If you're going back to a 'programming languages' solution, ... interpreter but you can also compile your code with your favorite ...
    (Fedora)
  • Re: Some General Questions about Ruby
    ... I think i'll soon begin to learn programming in ruby, ... Ruby is an interpreted language, if i'm not wrong, interpreted languages ... compile to an executable binary file native to the platform. ... executed via an interpreter, and it's not a very fast interpreter. ...
    (comp.lang.ruby)
  • Re: interpretive vs. compiled
    ... interpreter executing on a given processor might still execute your ... High level and advanced dynamic programming languages such as Common ...   happening later. ... Without compile time checks you will probably find the errors ...
    (comp.programming)
  • APLAS07 - Call for Participation
    ... The Fifth Asian Symposium on Programming Languages and Systems ... APLAS aims at stimulating programming language research by providing a ... APLAS07 will include a poster session. ...
    (comp.lang.ml)
  • POPL 2005 Call for Participation
    ... The annual Symposium on Principles of Programming Languages is a forum ... Main conference: January 12-14, 2005. ... The POPL 2005 conference site is Hyatt Regency Long Beach, ...
    (comp.lang.prolog)