"Only a subset of all possible programs can be written with statically typed languages. For some people that is enough."
I'm a big fan of dynamically typed languages & duck-typing. I don't see how this can be true though.
You say there are things that you just can't do in a static language. Technically, this is of course not true. You can greenspun anything you like into a static language. What you lose is: a) A lot of time that could have been put to use elsewhere, and b) Dynamic languages usually have a more convenient syntax for their features.
I use both statically (C, Java, Haskell) and dynamically (Python/Perl) typed languages. While performances is a point worth considering when comparing the two approaches, I'd put more emphasis on the safeness assurance you get from a statically-checking compiler.
I use a dynamic languages when prototyping or when simplifying tools reducing the boiler-plate of checking program safety at run-time exist. On the other hand, I use static-type languages when I need to stay safe writing a complex system.
Of course, you may be forced to write a program in C because you need performances while the design would be simpler in a dynamic language. Yet, I think that's a perversion of what statically typed languages were created for.
"I'd put more emphasis on the safeness assurance you get from a statically-checking compiler."
Or the lack thereof... type errors are only one type of bug a program can have and they are usually much more straightforward to find than algorithmic errors, race conditions etc. Static type safety is a *very* thin layer of safety indeed.
There are many large and complex systems written in dynamic languages - and many bug ridden ones written in statically typed languages...
Yeah, one quote is obviously false (Turing-completeness) and the other still holds if you switch the words "static" and "dynamic" around. Heh.
@Cristiano and Michael:
Safeness is one thing, but you do have to go to the effort of designing your types to the level of safety you need. You _can_ catch algorithmic errors and race conditions with a good enough type system, but it doesn't come for free - you need to specify more detailed types if you want to check them. For most code and for most coders, that's not going to happen. 
Worth far more to me are the guarantees I can infer when reading some other idiot's code. Where idiot frequently means me-a-month-ago.
> dynamic language performance
How many different things are you lumping together in the phrase "dynamic language"?
Is being able to change a prototype object's parent at runtime enough to make a language a "dynamic language"?
Is it either "dynamic" or "static", or can we have both in the same language?
"Lisaac: The power of simplicity at work for operating system"
http://citeseerx.ist.psu.edu/
vie...i=10.1.1.8.1282
my definition of a dynamic language is one where you can place different types of objects into a single instance of its main array type without any extra annotations (e.g. no casting). so for example, Lua is dynamic:
local x = { 1, "two", function() return 3 end }
this is somewhat of an acid test, necessary thanks to kneebiting equivocators
i don't see why people think making a large system in dynamic languages is hard, except for the fact that dynamic languages are usually more expressive. but assuming a task takes just as many lines of code in both, what is it about wearing a straightjacket 24/7 that makes you better at martial arts?
if you want discipline, study formal logic and write a prolog compiler in assembly. otherwise you're just wanking, and wasting your own time. though if you think you need a straightjacket to keep you from making braindead, no-foresight-whatsoever, takes-more-than-a-simple-edit-to-fix mistakes, maybe you do
forgot to add... static languages are good at catching a class or two of those takes-a-simple-edit-to-fix mistakes. the kinds of classes of mistakes that happen like never. static and to an even greater extent "correct" programming languages are some of the best examples of the worst conflation of theory and practice
@Greg M:
I guess you're talking about the much more flexible type systems like ML and Haskell's. Could you show us an example of how that would work?
What I'd envisage is a simple program in Haskell that typechecks, but has a simple coding error (say, adding two arguments together rather than subtracting one from the other). What would you do to make that error findable by the type system?
I've heard that this kind of thing is doable, but never really understood how it would work. Does it make the type statements in the program a sort of higher-level program that the compiler executes?
> this is somewhat of an acid test, necessary thanks to kneebiting equivocators
I hope, whoever those "kneebiting equivocators" are, they quickly point out your equivocation on the meaning of array - and loudly explain that your example shows Lua's one-and-only do-everything table data structure.
Does Python stop being dynamic because numpy arrays are homogeneous?
x = ( 1, "two", a = a + 3 )
could be
x :: (.Int,.{#Char},.(.Int -> Int))
Oh no! A typed tuple!
I, like you Michael, look favourably on the goals of the PyPy project, but I'm starting to question the deliverables, or lack thereof. If I want extra speed in my Python prog. I am more likely to use Psyco or weave or ... rather than something from PyPy.
Is it the case that PyPy is to Python as Perl6 is to Perl ?
- In the sense that they are both:
* Offering significant advances on the status quo.
* Been going for some years.
* Not yet 'released'.
- Paddy.
P.S.: Nice post!
it's an acid test, so i guess python isn't dynamic 
tuples accept different types in most languages
I thought the acid test for a Dynamic Language was the presence of 'eval' ?
Well... there is an 'eval' for C# now, and for other statically typed languages like F#.
@Paddy,
Pypy was released a long time ago, although it is still not complete and its goals haven't been met yet. You can check the pypy status blog for more information, but as far as I know, the plan is to deliver a usable implementation that could be used as a replacement of cpython by the end of this year.
Right now, they are focusing on their jit, which is the last and most difficult task.
@Michael: your posts and clear explanations are always welcome
the reason for the acid test is that in Python's case it doesn't matter. dynamic languages don't care if they're considered dynamic or not, and they definitely don't care if they're considered static. but static languages get butthurt when their severe restrictions are questioned, and so they go into vague defenses about how they're "static in some ways, dynamic in others"
@Luis,
Thanks for the update on PyPy. I'm looking forward to it.
- Paddy.
For large projects, one of the biggest payoffs of static typing is checking that methods and properties are used correctly. Customers hate getting messages like "object 123 sent message 234 to object 345, which could not accept it." (the common failure mode in a Smalltalk-like system I used once).
Typos and inconsistencies happen so easily that having some way to find them is nearly essential to deliver customer-friendly code. Strong typing is one (but not the only) way to do this. In fact, when optimizing performance much useful information is developed about possible bugs. The question is what to do about it, and how to verify that the programmer intended what you found.
> (although integrating Tracemonkey involved Mozilla in a
> move away from reference counting to garbage collection
> - and they managed to automate the process of changing
> a lot of the source code)
I think you're referring to changes in XPCOM, which is outside SpiderMonkey proper. SpiderMonkey has been using a mark-and-sweep garbage collector for a long time.
> So what is a tracing JIT? Rather than compiling up-front,
> a tracing JIT analyses the flow of types through your
> program and can compiled specialised 'paths' for the
> frequently used parts. If you have a function that is
> called with integers and adds them, then machine code
> that performs this operation will be generated. The
> function is protected with a guard so that if it is ever
> called with different types then new code can be
> generated or the normal language mechanisms used.
V8 uses polymorphic inline caches to type-specialize the generated code, as well, so the characterization of V8 as "up-front" is misleading.
Commenting by HaloScan
