And vice versa...
Originally Posted by Etnu
Nothing? Of course there are many intelligent people on both sides of the static vs. dynamic typing issue, but usually the argument made by the pro-dynamic typing people is that static typing does bring benefits, but it also brings costs and they feel the costs outweight the benefits. But I don't usually see too many people who say that data types provide no information at all, a statement that seems a bit hyperbolic to me.
Data type indicates absolutely nothing about a variable.
I'll agree that in simple web apps it probably doesn't make much of a difference whether you're dealing with an integer 1, a string "1", or a double 1.000. Primitive types can be fairly easily coverted to other primitive types without losing too much information. However, in object-oriented code I've found data type information to be highly useful. Consider two random classes that you use in your PHP code. It's not very likely that an instance of one of your classes could be converted to an instance of another... the class of a particular variable is very important, and indicates what it is and what can be done with it (what methods can be called, etc.). It seems odd to say that this information doesn't matter.
For me, one of the advantages (and yes, I see disadvantages too) of static typing in an OO language is documentation. It's immensely useful to know without a doubt what type of objects are required as parameters on a method, and what type of object I'm going to be getting back. I've found in my and other's dynamically typed OO code, there is sometimes a tendency to give object instances longer and more cumbersome names in an effort to make it clear what class the instance belongs to. This is, in a way, a type of Hungarian notation for types, and I think most people here would agree that this is a Bad Thing. Sure, you don't have to do this; you can pick the same names as you would in a statically typed language, but it sometimes makes it a little trickier to know what you're dealing with, especially if you have classes that are different but may contain a common subset of similar or the same method names.
Use sensible variable names and document your code or it'll be hard to use.
I think it depends on what style works for you. A counter argument to this is that it may slow initial development time, but it may improve maintenance time. You only write your app once, but you may be refactoring/maintaining it for a long time to come. The argument could be made that you should optimize for maintenance and not for the initial development time.
Forcing something as archaic as static typing on web development slows development cycles painfully.
As for me, I see advantages and disadvantages to both. For simple tasks, static typing can be onerous. For more complex ones, I feel it improves the ability to reflect on what the code is doing and it may improve maintenance. So, speaking for me personally, I don't necessarily prefer one over the other; they both very much have their uses.
You are being slightly inconsistent here. You say that PHP excels as a general-purpose scripting language. But earlier in your post you stated:
PHP excels as a web app language and as a general-purpose scripting language.
I don't see how a platform that has "pretty terrible" garbage collection can possibly excel as a general-purpose scripting language. "General-purpose" means that you may not be dealing with short-lived requests and environments that are being tossed out rapidly. I would argue that PHP does excel as a web app language but still has some improvements to be make before it can truly be "general-purpose".
Fast garbage collection is meaningless when you simply toss away the entire app context at the end of the request (the way that you build PHP apps). PHP's garbage collection is actually pretty terrible, but it doesn't matter because you just toss it all out at the end of the request.
I beg to differ. Perl most definitely has its warts, but it's still very useful for many tasks. PHP does not currently, and likely never will, have anything comparable to CPAN. You may find Perl the language ugly (although in many ways it is much more advanced than PHP: true block-level scoping, namespaces, closures and truly-anonymous code blocks, etc.), but there is an amazing selection of truly-useful reusable code available at CPAN for just about any task you can imagine. I've found that the same cannot be said for PHP. My personal opinion is that the lack of namespaces in PHP makes encapsulation at a library-level difficult and discourages the development and sharing of generic classes and class libraries.
It can replace perl for everything
Disclaimer: I've been pretty down on PHP in this post. Before anyone gets the idea that I'm a "hater" let me state that I do think PHP has a sweet spot in certain types of applications, and I use it heavily where it makes sense. It just feel that this attitude of "PHP has nothing to learn from other platforms" holds it back, and that's a shame...
EVERY language is "compiled".
Actually, I've seen it stated that Ruby scripts are currently not compiled to bytecode/machine language, but are converted into an abstract syntax tree and interpreted. So, it could be argued that Ruby isn't compiled.