"Strong typing vs. strong testing"
Pascal J. Bourguignon
pjb at informatimago.com
Thu Sep 30 20:37:22 CEST 2010
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
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
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
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/
More information about the Python-list