[wvenable]

> But people are abusing PHP to write large scale libraries and frameworks. Many riddled with security issues, and unpredictable performance bottlenecks, because the language wasn't designed to actually allow you to write well defined algorithms.

I mostly agree with your post but you've gone way over the top on this statement. PHP is pretty analogous to the majority of languages in terms of syntax, structure, and capability. Frameworks written in PHP are no more likely to have security issues or unpredictable performance bottlenecks than any other language. Certainly nothing prevents you from writing well defined algorithms.

PHP's "arrays" are both vectors and hash tables at the same time. I agree that there is no reason to combine those concepts (although I love ordered hash tables). But ultimately there isn't much harm in it; it's just an extreme example of typelessness.

[ralfn]

>> But people are abusing PHP to write large scale libraries and frameworks. Many riddled with security issues, and unpredictable performance bottlenecks, because the language wasn't designed to actually allow you to write well defined algorithms. >I mostly agree with your post but you've gone way over the top on this statement.

You are right, i went over board.

>Frameworks written in PHP are no more likely to have security issues or unpredictable performance bottlenecks than any other language

I suspect there is a measurable relationship between average quality of ecosystem and how easily or difficult a language is to use. But that would not be a fair argument: a language being easy should be a good thing.

>Certainly nothing prevents you from writing well defined algorithms.

Well, not being able to guess the order of complexity of many of the core operations on datastructures, does make it a lot harder. It's generally undefined, at least by the language spec. And when the internal implementations of core datastructures change between versions, you can't even reliably implement the typical collection of sorting algorithms.

The reasons this isn't a problem at the smale scale, is that the most common operations are actually all build-in with good defaults.

>But ultimately there isn't much harm in it; it's just an extreme example of typelessness.

PHP is not typeless, just messy with types. Depending on the type, you can use different syntactical operators and you are unable to implement those same contructs for other types. Also dependent on the type, is the difference between value- and object- semantics. However, this logic is not consist with the actual algorithmic complexity. Strings are copy-on-write, for example. So you are technically passing a reference (from a performance POV), but acting like it's not.

PHP is a dynamically typed language, with lots of run-time type errors, when things don't match. We even have all kinds of functions to determine types. It's definately not typeless.

[wvenable]

> Strings are copy-on-write, for example. So you are technically passing a reference (from a performance POV), but acting like it's not.

That's just an optimization; it's not a very significant detail. All languages have these little details. Java, for example, caches and reuses Number instances if the value is below 127.

> PHP is a dynamically typed language

It's also weakly typed. You can, for the most part, assume that the type isn't very important. If you've got the value 12, it doesn't matter much if it's stored as an int, float, or string. But obviously if you attempt to do an operation not supported by the value then you'll get an error. There's nothing surprising about that.

PHP arrays just take the idea of an index and allow it to be both strings or integers. In both cases, you're providing a value for the key and getting out another value. It's pretty easy to explain. The issue, I'd say, is that programmers rarely ever index by both integers and strings in the same structure. There are also performance differences but hash tables are so fast that you need to be doing something unusual for it to matter.