4 ms·

@jtreminio I did not claim one cannot run succesfull projects in PHP. I stated the exact opposite. And im doing that again now, in the hope your reading is jus

• stcredzero 14y ago
  Nobody with the actual skillset to design and implement a programming language would consider, for example, merging vectors and dictionaries into some kind of mutated frankenarray. Actually, JavaScript and Lua have merged vectors and Dictionaries.
• ralfn 14y ago
  >>Nobody with the actual skillset to design and implement a programming language would consider, for example, merging vectors and dictionaries into some kind of mutated frankenarray. >Actually, JavaScript and Lua have merged vectors and Dictionaries. I'm not sure about Lua, but in the case of Javascript, it's not entirely true. Arrays are objects, yes, but objects are not arrays. So, unless you are extending the build-in array type, objects do not behave as arrays. They are not recognized as arrays, and more importantly, no modern javascript engine actually implements arrays as hashes. For example {}.length has no value. It does not have a length of zero, it does not have a length at all. Visa versa, when looking at an object-map as a 'map', you'll get the array entries, as well as the length property, and the push and pop methods. It's orthogonal. Imagine a javascript engine having no special implementation for an Array. We could implement it on top of the object-map. So, an array does not behave as a map, its implemented in a map. There's a clear distinction. But the parallels with PHP are interesting. Both languages were not designed with the intent of large applications, but with the intent of adding a small piece of isolated logic to what is mostly a template. Both languages have had a lot of flack for their early design choices as well. People are still upset how Javascript handles casting (which is similar to how PHP handles it), and they are still upset how Javascript handles scoping (which is again similar to how PHP handles it). Where the languages start differing, is that Javascript is much more reflective, which allows one to fix many language flaws in library or framework code, to suit different use-cases like the development of large scale projects. (just consider the hundreds of class-based systems implemented in Javascript) But even for Javascript, the same logic applies. Considering the role and purpose it has now, the language design would have been different, if it was not for backwards compatibility. And there as well, people are trying to figure out ways to make it radically better. Dart comes to mind. Compiling other languages into javascript. (coffeescript, gwt, etc.) And even arguments in favor of Node.js are all based on the assumption that we are stuck with Javascript in the browser. And just as with PHP, the original authors themselves, make no secret that their language design wasn't optimized or optimal for how we are using it now.
• notJim 14y ago
  > Nobody with the actual skillset to design and implement a programming language would consider, for example, merging vectors and dictionaries into some kind of mutated frankenarray. Why is this bad?
  • ralfn 14y ago
    Well, answer me this: Whats the order of complexity of adding an element in the middle of "an array" in PHP? So, it's bad, because it makes it very confusing, what the exact implementation is. If you can't tell how much slower your algorithm that calculates something from an 'frankenarray' gets, when the array gets bigger, you have a problem. That's one problem. The other problem is with language itself. When we call something an array, which isn't actually an array (an array being a very specific implementation of a vector) people get confused. Imagine how you would feel if PHP used the word 'variable' to mean function and the word 'function' to mean variable. So, a hash and an array are not just semantically different (that they refer to a completely different ADT's), but they are also completely distinct implementations of those ADT's. Now, this is not a problem, when you are using PHP as it was originally intended. To add a small bit of logic to a template that mostly uses fast, well written c functions in it's built-in library. 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. Now, we've seen workarounds for these problems. Facebook wrote a PHP to C compiler, and moved all crucial algorithms to C. You can use unit-testing to supplement the lack of any usable type information, and to combat the automatic casting that PHP does (which creates all kinds of bugs in edge cases, that is hard to track or test against). You can use profiling to track performance issues, and fix code that interacts with frankenarrays, in a sort of trail-and-error kind of way. People once wrote all their code in ASM. Discipline can make all the difference. But highly skilled disciplined, well educated professionals aren't the target audience of PHP. All this required discipline can be justified on practical grounds. PHP programmers are generally paid the worst (or as an employer would call, are the cheapest). Hosting is cheap. And for many use-cases you can just drop in ready to go code (Wordpress, Drupal, Joombla, etc.) and just skin it. So, i'm not saying picking PHP is a bad financial choice for a company. If you don't take on difficult projects, and don't intent to hire highly skilled coders, it can be cheap and productive. But that doesn't make the language any better..