4 ms·
I think the author's lack of distinction between static vs dynamic and strong vs weak typing detracts from his point. Static vs dynamic typing boils down to whe
by uiri 12y ago
I think the author's lack of distinction between static vs dynamic and strong vs weak typing detracts from his point.
Static vs dynamic typing boils down to whether typechecking is done at compile time or at run time (for various definitions of "compile time" and "run time"). Strong vs weak typing is whether the language will raise a type error or it will try to silently convert types. Python is dynamic but also strongly typed. I feel like PHP's weak typing contributes to the maintainability issues mentioned - passing in the wrong types to the APIs cause silent failures rather than generating some kind of error message. I feel like this makes it more difficult to design a good API because you have to take care of more cases rather than simply throw an exception when you get something badly typed. Since programming in a statically typed language is going to require a test suite anyways, I'm not sure that it buys you much over a strong dynamic typed language like python. That said, an argument could easily be made the other way - it doesn't cost much to use a strong statically typed language like Java. You are going to have to spend time on type safety in each case the question is just whether it is while trying to get a prototype to compile or ensure that a mature project exhaustively tests arguments of illegal types (to pick the worst case for each side).
- seanmcdirmid 12y agoActually, in the type theory community, Python would be uni-typed and strongly tagged. They use a formal definition of type that doesn't have a dynamic qualifier (so call them tags instead). I guess my point is that we can be pedantic, but each one of us will probably have a different interpretation of the terms.
- chadaustin 12y agoWhat I've found in discussing these topics with some colleagues are that the terms "strong typing" and "weak typing" are so vague that almost everyone has a different definition. The academic literature uses types to mean checked at compile-time, and tags to mean checked at runtime. Python, calls them types but checks at runtime. I think the fuzzy terminology can work as long as we all declare in advance what we mean. :) In general, I agree with your points. Where strong type systems start to help a lot is when you have super-complicated data flows and invariants, where many different types might actually have the same representation (say, a 32-bit integer or small string), but only some operations are valid on some types. That stuff gets tricky in Python, even if you implement a unique class per type.
- bandrami 12y agoOne could look at it as two orthogonal questions, yielding four classes of language. Question 1: does the runtime receive interpretation semantics of values from the compiler (yes = "dynamic", no = "static")? Question 2: does the enforcer of interpretation semantics ("types") do so liberally or conservatively (liberally = "weak", conservatively="strong")? So, dynamic strong would be Lisp[0], dynamic weak would be PHP, static strong would be Haskell, static weak would be C. I suppose there's even a fifth option of "no interpretation semantics to begin with", which would be something like Forth. [0] As you seem to allude: a dynamic language makes this question more tricky.