-
There is a corrollary of static typing with driving SUVs. SUVs are not safer to drive, but it makes the driver feel they are safer. In contrast, passenger cars are designed to be safe because they make the risks more apparent to a driver.
For python programmers, not having the safety of static typing means that more effort is put into checking that the program runs correctly, not just compiles correctly.
-
Any tool is going to find it hard to do the kind of analysis that you seem to want on the example "foo" considered in isolation, but that doesn't mean that no analysis is possible and we should just give up now - ie. a restatement of the pre-Starkiller argument for never being able to perform analysis or type-based optimisation on Python programs without explicit type annotations.
Consider calls to "foo" that may already exist in your program - it becomes possible to investigate whether the body of "foo" makes any sense with respect to (inferred) types/values of the parameter 'x', and this specialisation is presumably taken quite a bit further in various functional languages (if not with languages associated with other paradigms, too).
Such analysis isn't trivial, but I think that it's the way to go for better tools and for improving the performance of some Python-based systems.
-
What we need is for ML, be it O'Caml, SML, or some other variant, to become ridiculously popular. In fact, any language with implicit typing would suffice. Implicit types are the way to go: all the supposed security of statically typed languages, without the feeling you're talking to an autistic child.
-
Chui Tey: Wrong metaphor. Static typing doesn't cost more fuel, doesn't pollute the environment (more than neccessary), and isn't gross.
In fact, static typing allows for increased code efficiency (as you can omit some runtime checks), gives additional information to the development tools (which can then aid your task even better) and, as Keith Gaughan rightly remarks, via implicit typing doesn't cost a single key stroke (in most cases).
Just because someone might confuse static typing with a verification of code correctness doesn't mean that static typing is worthless. It does prove that you did not make some particular error.
True, that won't save you from having to test your code thoroughly, but it can save you from this "Oh, how stupid I was this morning before I drank my gazillionth cup'o'cofee..." feeling. ;)
Hans: I also have long-running python code here. It works, but it took some time to build confidence in the code.
-
Andre, where I'm coming from is that I see virtue in strong typing, but not quite so much in static typing. With static typing, it feels as if I'm hitting my head against a wall. This is where statically-typed languages suck, but dynamically-typed ones excel.
Implicit typing is not static typing. I think you seem to be confusing static typing with strong typing. However, one does not imply the other.
Take Python itself: it's dynamically typed, and strongly typed. C, on the other hand, is statically typed, but weakly typed.
-
"I think you seem to be confusing static typing with strong typing. However, one does not imply the other."
No. I really meant static typing (that is type checking at compile time), because I don't want to wait hours for my long-running-computation to bail out on some stupid error I made before by gazillinth coffee. The line between strong and weak type systems is a little blurry - any language that interfaces with C might break its type system on the library level.
"Implicit typing is not static typing."
Correct as in "Green is not hairy". I think that speaking of traits of a language as nouns blurs the discussion on what they mean.