rustom <rustompm...@gmail.com> writes: > Some points that seem to be missed (or Ive missed them?) > > 1. A dichotomy is being made between 'static' languages like C and > 'dynamic' languages like python/lisp. This dichotomy was valid 30 > years ago, not today. In Haskell for example > > - static checking is stronger than in C/C++ -- its very hard if not > impossible to core dump haskell except through memory exhaustion > > - dynamic-ness is almost that of python/lisp -- on can write > significant haskell programs without type-declaring a single variable/ > function
You're confunding type strongness with the requirement that the programmer should declare the types, and with the time when the types are checked. http://en.wikipedia.org/wiki/Comparison_of_programming_languages#Type_systems type strong static explicit Ada type strong static implicit Haskell type weak static explicit C type weak static implicit ? type strong dynamic explicit (*) type strong dynamic implicit Common Lisp type weak dynamic explicit Objective-C type weak dynamic implicit JavaScript (*) Usually languages provide explicit typing as an option, but can deal with implicit typing, when they're dynamic. There are also a few languages with no type checking, such as assembler or Forth. > Much more mainstream, C# is almost as 'managed' as dynamic languages > and has efficiency comparable to C. Nothing extraordinary here. Common Lisp is more efficient than C. http://www.lrde.epita.fr/~didier/research/verna.06.ecoop.pdf http://portal.acm.org/citation.cfm?id=1144168 Actually, it's hard to find a language that has no compiler generating faster code than C... > 2. The dichotomy above misses a more pervasive dichotomy -- hardware > vs software -- as real today as 30 years ago. > > To see this let us lift the discussion from that of *languages* C vs > Python/Lisp to philosophies: > -- C-philosophy: the purpose of type-checking is to maximize (runtime) > efficiency > -- Lisp-philosophy: the purpose of type-checking is zero-errors (aka > seg-faults) via continuous checks at all levels. > > If one is honest (and not polemical :-) ) it would admitted that both > sides are needed in different contexts. > > Now Dijkstra pointed (40 years ago) in Discipline of Programming that > this unfortunate dilemma arises due to lack of hardware support. I am > unable to reproduce the elegance and succinctness of his language but > the argument is as follows: > > Let us say that for a typical profile of a computer we have for every > one instruction of the pathological one typified by the maximum > function, a trillion 'normal' instructions. This is what he calls a > very-skew test -- an if-then-else that checks this would go the if-way > way one trillion times for one else-way. It is natural for a > programmer to feel the pinch of these trillion checks and (be inclined > to) throw them away. > > If however the check was put into hardware there would be no such > dilemma. If every arithmetic operation was always checked for overflow > *by hardware* even languages committed to efficiency like C could trap > on errors with no extra cost. > Likewise Lisp/python-like languages could easily be made more > efficient. > > The diff arises from the fact that software costs per use whereas > hardware costs per installation -- a transistor, unlike an if, does > not cost any more if its used once or a trillion times. > > In short the problem is not C vs Lisp/Python but architectures like > Intel wherein: > > 1. an overflow bit harmlessly set by a compare operation is > indistinguishable from one set by a signed arithmetic operation -- > almost certainly a problem > > 2. An into instruction (interrupt on overflow) must be inserted into > the software stream rather than raised as a hardware interrupt. Hence the use of virtual machine: when your machine doesn't do what you want, you have to write your own. When Intel will realize that 99% of its users are running VM, perhaps they'll start to wonder what they're making wrong... -- __Pascal Bourguignon__ http://www.informatimago.com/ -- http://mail.python.org/mailman/listinfo/python-list
