"Strong typing vs. strong testing"

[Pascal J. Bourguignon]

TheFlyingDutchman <zzbbaadd at aol.com> writes:

>>
>> > "in C I can have a function maximum(int a, int b) that will always
>> > work. Never blow up, and never give an invalid answer. "
>>
>> > Dynamic typed languages like Python fail in this case on "Never blows
>> > up".
>>
>> How do you define "Never blows up"?
>
> Never has execution halt.
>
> I think a key reason in the big rise in the popularity of interpreted
> languages 

This is a false conception.

Whether the execution of a program is done by a processor of the
programming language, or a processor of another programming language
(and therefore requiring a translation phase), is a notion is NOT a
characteristic of programming language, but only of execution
environments.


1- There are C interpreters
    CINT - http://root.cern.ch/root/Cint.html
    EiC - http://eic.sourceforge.net/
    Ch - http://www.softintegration.com

2- All the current Common Lisp implementations have compilers,

3- Most current Common Lisp implementations actually compile to native
   code (ie they chose to translate to programming languages that are
   implemented by Intel, AMD or Motorola. (Notice that these programming
   languages are NOT implemented in hardware, but in software, called
   micro-code, stored on the real hardware inside the
   micro-processors); some choose to translate to C and call an external
   C compiler to eventually translate to "native" code).

4- Actually, there is NO current Common Lisp implementation having only
   an interpreter.  On the contrary, most of the don't have any
   interpreter (but all of them have a REPL, this is an orthogonal
   concept).

5- Even the first LISP implementation made in 1959 had a compiler.

6- I know less the situation for the other dynamic programming language,
   but for example, if CPython weren't a compiler, you should know that
   CLPython is a compiler (it's an implementation of Python written in
   Common Lisp, which translates Python into Common Lisp and compiles it).


> is that when execution halts, they normally give a call
> stack and usually a good reason for why things couldn't continue. As
> opposed to compiled languages which present you with a blank screen
> and force you to - fire up a debugger, or much much worse, look at a
> core dump - to try and discern all the information the interpreter
> presents to you immediately.

Theorically, a compiler for a static programming language has even more
information about the program, so it should be able to produce even
better backtrace in case of problem...

-- 
__Pascal Bourguignon__                     http://www.informatimago.com/