What do you mean lately? PHP has gotten tons of well deserved criticism since it was created. It isn't "hate" to point out that a popular language is much worse than many other comparable languages.
When that "well deserved criticism" comes from the same people who feel compelled to post in every PHP thread, obsessively, over and over again ... it's hate.
Hate isn't inherently negative. You can hate evil, etc.
However, if you hate a programming language ... there's really something wrong with you. It suggests a very sheltered life. There are far more important things in life that deserve your hatred.
>When that "well deserved criticism" comes from the same people who feel compelled to post in every PHP thread, obsessively, over and over again ... it's hate.
No, you choose to label someone else's opinion as "hate" because it lets you dismiss it and throw out baseless insults at those people with less risk of getting taken to task for it. You told other people (theoretical people at that) what they think, and then told them there is something wrong with them and they lead sheltered lives. How incredibly arrogant.
I think something that forces me, almost daily, to waste my time dealing with problems that are simply nonexistent in more sane languages deserves my hatred. (And I have a LOT of hatred for it!)
It becomes "hate" when the criticism is ill-informed and largely irrelevant. The bits of PHP that are "much worse" are mostly either legacy cruft that nobody in their right mind uses anymore, or bits are rarely touched in day to day programming but are safely wrapped in frameworks, ORM's, libraries etcetera.
Beyond that, PHP simply isn't particularly elegant (mostly since it was never really designed to be a programming language), and we all know it.
Other than that, I rarely see any relevant criticism, let alone constructive criticism.
>The bits of PHP that are "much worse" are mostly either legacy cruft that nobody in their right mind uses anymore, or bits are rarely touched in day to day programming but are safely wrapped in frameworks, ORM's, libraries etcetera.
Huh? The article in question demonstrates otherwise, note they just now fixed one of the problems with anon functions, a relatively new feature. PHP continues along the path of adding "features" randomly and without even understanding the purpose behind the feature, and so you get half-features that kinda work and don't really solve any problem in the context of PHP, but were just added so they could check off "some feature we don't understand" on the feature list.
>Other than that, I rarely see any relevant criticism, let alone constructive criticism.
In the context of PHP, I think "you should use a better language" is as constructive as you can really get. There's nothing wrong with warning new web developers that PHP is worse than every other language that lives at the same sort of level (perl, python, ruby, pike, etc).
>PHP continues along the path of adding "features" randomly and without even understanding the purpose behind the feature, and so you get half-features that kinda work and don't really solve any problem in the context of PHP, but were just added so they could check off "some feature we don't understand" on the feature list.
This is not how features get added to PHP. Please spend some time on the PHP mailing list if you would like to know how it works.
Agreed. The "largely irrelevant" point I think is key. Just about every PHP pitfall is avoidable when employing best practices (something that is encouraged for all languages anyway).
We see the same thing with JavaScript and C++ (to a lesser extent) because some developers are simply afraid that a less experienced programmer might commit the sin of using the "bad parts", as if Python and Ruby transform careless career programmers into artisans.
Nobody can hate something as strongly as somebody who's spend way too much time looking at it. That, in this case, would be me.
Those frameworks and ORMs that you claim as a panacea are generally obfuscatory at best (Symfony2, which is a brilliant example of what you can do with PHP and a cautionary tale of designing a system that makes sense to twelve people, ever) to downright maliciously bad (CodeIgniter, get the hell out of my universe and take Joomla with you).
If you can muddle along with glacially inefficient frameworks (often with APIs that make core PHP seem not all that terrible for a time) and ORMs (personally, I don't use an ORM for anything, and credit where credit's due, PDO is actually a very reasonable solution), more power to you, but some of us (hi) have already been to that dance and realized it wasn't going to work for us. So I do criticize PHP on many fronts, from its psychotic language decisions to it's slapdash internals and it's blatant encouragement of idiotic programming practices. (You can say "nobody in their right mind would use that," but the existence of crapfloods of shitty PHP--hello, Wordpress--suggest that either that's not the case or the biggest PHP projects out there are run by lunatics.)
If I end up writing PHP, invariably I end up grabbing Silex and building the useful bits on top of that. While doing so, I continually wish it was a language where imposing actual application structure wasn't essentially actively discouraged; the outright necessity of shit like call-by-name loses what little error-checking you can otherwise get and the solution to any data storage problem seems to be "MORE ARRAYS!". PHP is a tool where a sufficiently advanced developer finds themselves fighting it as much as using it, and that is a shame. Because it doesn't have to be willfully obnoxious. It just is.
I mean, I went back to Java for my own projects, over continued bashing at PHP. That is a low bar. (But, to be fair, Play makes Java tolerable.)
"Nobody can hate something as strongly as somebody who's spend way too much time looking at it". Wrong. You can look at something and not hate it as much as someone who just hates PHP because he/she didn't like the syntax or it didn't fit their needs.
"Those frameworks and ORMs [...] are generally obfuscatory at best". This is your opinion, not a fact. Don't state it as a fact, unless you've got concrete examples to prove it.
"downright maliciously bad (CodeIgniter [...])". Another opinion with no facts to support it.
"glacially inefficient frameworks". Another opinion with no facts supporting it.
"it wasn't going to work for us". Good. It works for many other people, you happen to be in a different group. More power to you.
"psychotic language decisions". Another opinion stated without any facts or even examples.
"slapdash internals". As someone who has developed plugins for PHP, I have to ask you what exactly can be qualified as "slapdash", to the point where it brings PHP's internal code quality below similar products?
"blatant encouragement of idiotic programming practices": Please, do share with us which "idiotic programming practices" does PHP, the language, encourage, and other similar languages do not? Otherwise, this is another opinion without any facts to support it.
"application structure wasn't essentially actively discouraged". For the thousandth time, learn to provide supporting evidence to your arguments.
"the solution to any data storage problem seems to be <<MORE ARRAYS!>>". This statement makes no sense. Here's a counter example: if I had 1TB worth of data which I wanted to save to a MySQL cluster, I would _not_ need more arrays than to store the same data to a single MySQL instance, because the storage layer has nothing to do with in-memory representation of an item (except when the programmer decides to make the two similar, but that has nothing to do with the language). Therefore, your statement is false.
"a sufficiently advanced developer, finds themselves fighting it as much as using it". Please provide some evidence. As a counter-example, I can point to Facebook, which probably has "sufficiently advanced developers" that are not fighting with PHP.
"I went back to Java". I hope you stay there.
In conclusion, I'd like to say that, given your unsupported claims, you seem to not have reached a sufficient level of proficiency with PHP. You did say you spent a lot of time looking "at it", but that doesn't necessarily imply that you understood PHP.
All the rhetoric in your comment makes for a decent rant, but it will only appeal to similarly-minded people, who hate PHP because of random, half-brained personal reasons.
"If you can muddle along with glacially inefficient frameworks (often with APIs that make core PHP seem not all that terrible for a time) and ORMs (personally, I don't use an ORM for anything, and credit where credit's due, PDO is actually a very reasonable solution), more power to you, but some of us (hi) have already been to that dance and realized it wasn't going to work for us."
Count me in as someone who took a look at the frameworks and said "no thanks". I think where the frameworks fail is that they always feel the need to go OO. PHP's design is pretty procedural in essence, because it's not a lot more than an HTTP wrapper with some useful procedures you can call. If you wrap that in an OO layer, by necessity you have to complicate things. I've found the best use of objects in PHP is in support of procedural request handler code. The only framework I use is ZF, because you can easily use it without buying into the whole MVC and routing paradigm.
Woah, in one sentence you claim about PHP devs feeling the need to go OO and then the next sentence you extol the virtues of ZF? ZF is all OO, all the time.
He already answered your question in the post you are replying to:
>because you can easily use it without buying into the whole MVC and routing paradigm
As much as I think the zend framework is terrible, you can pick and choose whatever bits of it you like and ignore the rest. There's no working around assumptions or anything, it is just a normal way of using the framework.
> it's blatant encouragement of idiotic programming practices
PHP doesn't encourage bad programming practices. It simply doesn't encourage good ones. That isn't just semantics, either.
There are times when you need to break the rules. They're rare, but they're there. PHP is a language which leaves you that option. If choose to use that optional frequently, then you have nobody to blame but yourself.
Look, there are a number of criticisms of PHP that the language definitely deserves, but I'm not sure if you've hit on any of the legitimate ones.
the outright necessity of shit like call-by-name loses what little error-checking you can otherwise get
I'm sorry, but I use PHP everyday, and I rarely find myself needing to use call-by-name, except when it is required by internal functions. Many internal PHP functions that manipulate arrays do require the arrays to be passed by reference, but this doesn't prevent unit testing or error checking at all. I can't find any validity in this complaint and am assuming it is more problem of your coding style than an error inherent in PHP's language design.
the solution to any data storage problem seems to be "MORE ARRAYS!"
Brilliant observation. This is because arrays in PHP do double or even triple duty. They can be simple number-indexed arrays, they can be associative arrays, and they are internally implemented as hash tables, so they can also act as hash tables. Is your problem a semantic one or one of functionality?
PHP is a tool where a sufficiently advanced developer finds themselves fighting it as much as using it, and that is a shame.
I'v been thinking about using Php lately. I come from a C# background, so I was poking around to see what I would be missing or gaining from Php. Why haven't they added a compiled option yet? I know you can use http://phpcompiler.org compiler to do it but why hasn't it just been added to the project? The speed increase is well worth it. Also I noticed Php doesn't have generics or Template classes. I use these a lot in my C# libraries. Anyone know if thats going to be added anytime soon? I do like that its used everywhere. Also looking for a good MVC framework for Php like Asp.net MVC.
UPDATE
Can you please stop down voting. I'm not hating on Php, read my other comments below.
Yeah your probably right about asking this here. I was hoping for some Php experts maybe to point me in the right direction. I'm not trying to hate on Php just want to learn an open source framework or language that has similar features to C#. I really don't want to learn Java because I think thats a dead language. I'd rather use Mono but they don't have very good support for asp.net mvc.
That aside, PHP is plenty fast as long as you avoid Zend and design your apps correctly for what you're doing. Lots of bad stuff out there giving PHP a bad name, like Magento.
Have a look at some jvm-based languages/frameworks. Grails/Groovy, and Rails with JRuby may be interesting to you. Both Groovy and JRuby have strong metaprogramming aspects, which may be of interest.
Heck, even Play! might change your mind about Java.
In the PHP world, there's a huge number of choices/options out there, and finding something that fits your style can be a challenge (because, until you know your style, you don't know what fits).
I too wish php had a widely supported compiler, but in reality it's not something that most projects require. The overhead of interpreting php is a lot lower than e.g. making a single db call. Also, in the most common usage scenarios, PHP processes only live for the time it takes to deal with each request, so how do you approach that if you're compiling your code? Keep spinning up new processes or rewrite your application code?
those charts don't say whether APC is enabled, which leads me to suspect that it isn't. APC is an opcode cache that greatly enhances php performance, no one runs a high traffic website without using APC
Did not know about APC...nice. Does APC just compile it after the first time and save it in memory? Can you use APC to create a packaged compiled file?
bytecode caches (like APC) store the bytecode on the fly in memory. you can't create somthing like a "binary" file.
edit: at least they're not intended to create "binaries". you can probably mess around with APC and make php look and behave like a compiled language. but you won't gain any notable speed improvements beyond the on the fly caching.
edit2: you can store php projects in a jar like file, caller phar. http://php.net/phar
eAccelerator and XCache also do the same(ish) thing. APC usually helps way more on subsequent requests. While APC /can/ help a lot, it's not the magic speed bullet that some make it out to be -- if your app is a bodged mess of Joomla and stuff that you got outside developers to write for you, it'll probably still run like garbage with APC enabled.
Getting a bit off topic here, but one of the biggest performance killers I've seen is PHP devs writing Really Awful SQL(tm). Even beyond stuff like failing to use PDO and prepared queries to avoid SQL injections, if you look around you'll find tons of just really abysmal SQL. Typical problem: someone is using an oper in SQL that forces MySQL to not use indices. This absolutely kills performance and you typically won't notice it as a developer unless you're pre-populating your database with a large "real-world" dataset and doing proper performance testing.
I wouldn't dismiss PHP's speed problems that quickly. Opcode caches typically don't speed up the actual execution, just the loading and parsing. I use zend server (with zend optimizer) and I've got PHP code that is hard CPU bound, as optimized as it can be, and still takes minutes to run to process perhaps 2 megabytes of raw data. By contrast, the exact same feature implemented in Delphi runs in less than 2 seconds, even though the code is an order of magnitude less efficient.
PHP isn't just orders of magnitude slower than JIT-ed or native compiled languages, but it has no affordances for that fact. There's no standard way to run code in the background. Zend won't start working on one either, because they sell a jobs queue as part of their Zend Server product.
Frankly, a JIT-ed PHP is the only feature I need. I appreciate the syntactic sugar added in the last few revisions of PHP, but honestly, I'd trade every new feature since PHP 5.2 for a bit more speed. With stuff like closures and traits it seems like they're working on the easy stuff instead of the necessary (but hard) stuff.
PHP is not strongly typed as C# so it doesn't need generics or templates or better said it wouldn't make much difference on performance unless it would be compiled (which is not the case on the standard).
Although I don't use it I have heard the symfony2 is one of the better MVC frameworks out there. The same people have also made quite a nice templating language called twig that you may also want to look at (http://twig.sensiolabs.org/).
While it's a good idea to look around what language A could borrow from language B once in a while, it's important to not fall into the trap of imitating B at all costs in A.
In this specific case, I don't think it's a good idea to do C#/ASP.Net in PHP and vice versa. Most PHP hosting environments do have a compile-once-run-many-times paradigm by virtue of opcode caching. The advantage over a typical Java or .NET app server is that you can change files and they get automatically recompiled on the fly. So for all intents and purposes, PHP is usually running a piece of in-memory compiled bytecode.
There are many MVC frameworks for PHP, for any interpretation of "MVC" you might want. I'm sure you can find one that's closely modeled after ASP.net, but again I'm not sure this is a productive undertaking in principle.
It's been a long time since I had any interest at all in PHP, and these new features make me feel uneasy once again.
The development server seems like the only good thing about it.
Traits looks like a silly implementation of multiple inheritance mixins, with a 'use' keyword that doesn't really fit in with the language itself. And the whole 'insteadof' thing looks weird. It will lead to hackish code for many people, encouraging weird monkey-patching.
The author says "when stored in an array", then proceeds to use "$functions['anonymous']". That's not an array. Sigh. I know PHP likes to call them that, but I just find it weird that they would continue to insist on mis-naming two of the fundamental data types of computer science.
The introduction of closures can only be a good thing, and a lot better than the passing of a string name of a function as a callback argument from before.
As usual though, it's expected that most servers and frameworks won't get the update for some time, due to whatever backwards incompatible changes have been made.
I know it's all the rage to hate on PHP these days, but even giving an objective look at the state of the language, given the thriving ecosystems of its competitors, makes it look to me like something I would never touch.
I don't think that PHP referring to hash maps as an array is a bad thing, in fact I've always loved the flexibility of the overloaded array implementation in PHP.
> ...due to whatever backwards incompatible changes have been made.
PHP is normally very good that way, does anyone know of any backwards incompatible changes that have been made?
> I know it's all the rage to hate on PHP these days, but even giving an objective look at the state of the language, given the thriving ecosystems of its competitors, makes it look to me like something I would never touch.
Yes you're right, it is quite fashionable to hate PHP and has been so for the ~10 years I've been using it, but who cares it gets the job done (a language for the pragmatists not the purists).
> I don't think that PHP referring to hash maps as an array is a bad thing, in fact I've always loved the flexibility of the overloaded array implementation in PHP.
But they're not arrays. JavaScript and Lua do the same thing, allowing you to assign numeric or hashed keys on objects (or tables in Lua), but they don't call them Arrays, because they aren't. Arrays have expected behavior and implementations. So do hash maps. It's fine to amalgamate them, just give it the right name.
> PHP is normally very good that way, does anyone know of any backwards incompatible changes that have been made?
I haven't looked at any in this version, but recently there was an article (I think on HN) complaining about severe ABI changes that required all compiled modules to be recompiled, leading to adoption problems.
> Yes you're right, it is quite fashionable to hate PHP and has been so for the ~10 years I've been using it, but who cares it gets the job done (a language for the pragmatists not the purists).
I used PHP for many years as well, and for that reason I don't think it's a language for the pragmatist at all. It's not expressive enough, it encourages bad coding, and it doesn't have an ecosystem comparable to Ruby, Python, or even the amazing one Node.JS has managed to garner in the past year or so.
But they're not arrays. JavaScript and Lua do the same thing, allowing you to assign numeric or hashed keys on objects (or tables in Lua), but they don't call them Arrays, because they aren't.
PHP's arrays combine both vectors and associative arrays, but both numerically indexed arrays and associative arrays are types of arrays, are they not?
Arrays have expected behavior and implementations. So do hash maps. It's fine to amalgamate them, just give it the right name.
Whether associative arrays use hash maps underneath is an implementation detail, not fundamental to the interface PHP provides to [associative] arrays.
I would love to explain to my boss when I introduced some bad code into our repo: "But the PHP made me do it!". Really, if you can't use a tool without blaming it for when you use it badly, well...
PHP 5.4 does NOT introduce closures, they've been in there from 5.3.
As for traits, sure but as with all things it depends on who will use them. Some will make a mess out of them, while other will use them properly. Just as with any other feature in any other language. Please stop using this tiered "reason" for why PHP is bad. It's just doesn't hold water.
Multiple inheritance is a silly implementation of traits/mixins and interfaces. MI combines implementation and type inheritance but with traits/interfaces those concepts are separate and therefore it is much more flexible.
The 'use' keyword already exists in PHP for use with namespaces; it's pretty common for C-based languages to overload common keywords.
As far as I'm aware, there are no backwards incompatible changes in this release and servers have been tracking the most recent PHP versions much better these days.
Class/object members and methods do not share a "namespace", so it's possible to have a method and a member with the same name. If you assigned a closure to a member that had a colliding method, PHP wouldn't know which one to execute.
I'm guessing this is at least some of the reason for that behaviour.
Has anyone tested the three opcode caches with the 5.4 release candidates?
I am depressed that eaccelerator seems to be fading away - they removed their shared memory functions for their build with 5.3 support.
In my experience eaccelerator is slightly faster and more stable than xcache. As a bonus, when it did have working shared memory functions (under php 5.2) it has session handler support so sessions are done completely in memory (added: without any additional code or modification)
The only problem is that this still requires you to compile the session extension. I am looking into ways of working around that, since it's not really used for anything except re-direction.
You can't modify your code, but you can modify your php.ini?
OK.
PHP has a very nice feature where you can automatically prepend (and append, if you want) a file to all requests. Create a single file, modify your php.ini, done.
I am not telling you that eaccelerator isn't amazing. I am showing you how to get around problems you may run into if you end up using a different op-code cache.
You should be using APC. It has all the shared memory functions you need and a lot more momentum than eA ever had. Facebook was even hacking on it for a while before HipHop was developed. It's a much better product overall.
66 comments
[ 2.3 ms ] story [ 106 ms ] threadHate isn't inherently negative. You can hate evil, etc.
However, if you hate a programming language ... there's really something wrong with you. It suggests a very sheltered life. There are far more important things in life that deserve your hatred.
No, you choose to label someone else's opinion as "hate" because it lets you dismiss it and throw out baseless insults at those people with less risk of getting taken to task for it. You told other people (theoretical people at that) what they think, and then told them there is something wrong with them and they lead sheltered lives. How incredibly arrogant.
Beyond that, PHP simply isn't particularly elegant (mostly since it was never really designed to be a programming language), and we all know it.
Other than that, I rarely see any relevant criticism, let alone constructive criticism.
Huh? The article in question demonstrates otherwise, note they just now fixed one of the problems with anon functions, a relatively new feature. PHP continues along the path of adding "features" randomly and without even understanding the purpose behind the feature, and so you get half-features that kinda work and don't really solve any problem in the context of PHP, but were just added so they could check off "some feature we don't understand" on the feature list.
>Other than that, I rarely see any relevant criticism, let alone constructive criticism.
In the context of PHP, I think "you should use a better language" is as constructive as you can really get. There's nothing wrong with warning new web developers that PHP is worse than every other language that lives at the same sort of level (perl, python, ruby, pike, etc).
This is not how features get added to PHP. Please spend some time on the PHP mailing list if you would like to know how it works.
Ever dealt with PHP code in the wild before? The amount of PHP written by people not in their right mind is VERY high.
We see the same thing with JavaScript and C++ (to a lesser extent) because some developers are simply afraid that a less experienced programmer might commit the sin of using the "bad parts", as if Python and Ruby transform careless career programmers into artisans.
Those frameworks and ORMs that you claim as a panacea are generally obfuscatory at best (Symfony2, which is a brilliant example of what you can do with PHP and a cautionary tale of designing a system that makes sense to twelve people, ever) to downright maliciously bad (CodeIgniter, get the hell out of my universe and take Joomla with you).
If you can muddle along with glacially inefficient frameworks (often with APIs that make core PHP seem not all that terrible for a time) and ORMs (personally, I don't use an ORM for anything, and credit where credit's due, PDO is actually a very reasonable solution), more power to you, but some of us (hi) have already been to that dance and realized it wasn't going to work for us. So I do criticize PHP on many fronts, from its psychotic language decisions to it's slapdash internals and it's blatant encouragement of idiotic programming practices. (You can say "nobody in their right mind would use that," but the existence of crapfloods of shitty PHP--hello, Wordpress--suggest that either that's not the case or the biggest PHP projects out there are run by lunatics.)
If I end up writing PHP, invariably I end up grabbing Silex and building the useful bits on top of that. While doing so, I continually wish it was a language where imposing actual application structure wasn't essentially actively discouraged; the outright necessity of shit like call-by-name loses what little error-checking you can otherwise get and the solution to any data storage problem seems to be "MORE ARRAYS!". PHP is a tool where a sufficiently advanced developer finds themselves fighting it as much as using it, and that is a shame. Because it doesn't have to be willfully obnoxious. It just is.
I mean, I went back to Java for my own projects, over continued bashing at PHP. That is a low bar. (But, to be fair, Play makes Java tolerable.)
"Those frameworks and ORMs [...] are generally obfuscatory at best". This is your opinion, not a fact. Don't state it as a fact, unless you've got concrete examples to prove it.
"downright maliciously bad (CodeIgniter [...])". Another opinion with no facts to support it.
"glacially inefficient frameworks". Another opinion with no facts supporting it.
"it wasn't going to work for us". Good. It works for many other people, you happen to be in a different group. More power to you.
"psychotic language decisions". Another opinion stated without any facts or even examples.
"slapdash internals". As someone who has developed plugins for PHP, I have to ask you what exactly can be qualified as "slapdash", to the point where it brings PHP's internal code quality below similar products?
"blatant encouragement of idiotic programming practices": Please, do share with us which "idiotic programming practices" does PHP, the language, encourage, and other similar languages do not? Otherwise, this is another opinion without any facts to support it.
"application structure wasn't essentially actively discouraged". For the thousandth time, learn to provide supporting evidence to your arguments.
"the solution to any data storage problem seems to be <<MORE ARRAYS!>>". This statement makes no sense. Here's a counter example: if I had 1TB worth of data which I wanted to save to a MySQL cluster, I would _not_ need more arrays than to store the same data to a single MySQL instance, because the storage layer has nothing to do with in-memory representation of an item (except when the programmer decides to make the two similar, but that has nothing to do with the language). Therefore, your statement is false.
"a sufficiently advanced developer, finds themselves fighting it as much as using it". Please provide some evidence. As a counter-example, I can point to Facebook, which probably has "sufficiently advanced developers" that are not fighting with PHP.
"I went back to Java". I hope you stay there.
In conclusion, I'd like to say that, given your unsupported claims, you seem to not have reached a sufficient level of proficiency with PHP. You did say you spent a lot of time looking "at it", but that doesn't necessarily imply that you understood PHP. All the rhetoric in your comment makes for a decent rant, but it will only appeal to similarly-minded people, who hate PHP because of random, half-brained personal reasons.
I wish you a happy life, full of hatred for PHP.
Count me in as someone who took a look at the frameworks and said "no thanks". I think where the frameworks fail is that they always feel the need to go OO. PHP's design is pretty procedural in essence, because it's not a lot more than an HTTP wrapper with some useful procedures you can call. If you wrap that in an OO layer, by necessity you have to complicate things. I've found the best use of objects in PHP is in support of procedural request handler code. The only framework I use is ZF, because you can easily use it without buying into the whole MVC and routing paradigm.
>because you can easily use it without buying into the whole MVC and routing paradigm
As much as I think the zend framework is terrible, you can pick and choose whatever bits of it you like and ignore the rest. There's no working around assumptions or anything, it is just a normal way of using the framework.
PHP doesn't encourage bad programming practices. It simply doesn't encourage good ones. That isn't just semantics, either.
There are times when you need to break the rules. They're rare, but they're there. PHP is a language which leaves you that option. If choose to use that optional frequently, then you have nobody to blame but yourself.
the outright necessity of shit like call-by-name loses what little error-checking you can otherwise get
I'm sorry, but I use PHP everyday, and I rarely find myself needing to use call-by-name, except when it is required by internal functions. Many internal PHP functions that manipulate arrays do require the arrays to be passed by reference, but this doesn't prevent unit testing or error checking at all. I can't find any validity in this complaint and am assuming it is more problem of your coding style than an error inherent in PHP's language design.
the solution to any data storage problem seems to be "MORE ARRAYS!"
Brilliant observation. This is because arrays in PHP do double or even triple duty. They can be simple number-indexed arrays, they can be associative arrays, and they are internally implemented as hash tables, so they can also act as hash tables. Is your problem a semantic one or one of functionality?
PHP is a tool where a sufficiently advanced developer finds themselves fighting it as much as using it, and that is a shame.
Sorry I can't be as advanced as you.
UPDATE Can you please stop down voting. I'm not hating on Php, read my other comments below.
1) You're hijacking the thread with something unrelated and better suited for some online research or sites like SO
2) According to your questions you're not investigating PHP, you're looking for C# in disguise/in another set of clothes.
That aside, PHP is plenty fast as long as you avoid Zend and design your apps correctly for what you're doing. Lots of bad stuff out there giving PHP a bad name, like Magento.
Heck, even Play! might change your mind about Java.
In the PHP world, there's a huge number of choices/options out there, and finding something that fits your style can be a challenge (because, until you know your style, you don't know what fits).
http://www.reddit.com/r/php would probably be a good place to ask these questions too.
Regarding MVC frameworks, try Yii - http://www.yiiframework.com
Thanks for the Yii link.
edit: at least they're not intended to create "binaries". you can probably mess around with APC and make php look and behave like a compiled language. but you won't gain any notable speed improvements beyond the on the fly caching.
edit2: you can store php projects in a jar like file, caller phar. http://php.net/phar
Getting a bit off topic here, but one of the biggest performance killers I've seen is PHP devs writing Really Awful SQL(tm). Even beyond stuff like failing to use PDO and prepared queries to avoid SQL injections, if you look around you'll find tons of just really abysmal SQL. Typical problem: someone is using an oper in SQL that forces MySQL to not use indices. This absolutely kills performance and you typically won't notice it as a developer unless you're pre-populating your database with a large "real-world" dataset and doing proper performance testing.
PHP isn't just orders of magnitude slower than JIT-ed or native compiled languages, but it has no affordances for that fact. There's no standard way to run code in the background. Zend won't start working on one either, because they sell a jobs queue as part of their Zend Server product.
Frankly, a JIT-ed PHP is the only feature I need. I appreciate the syntactic sugar added in the last few revisions of PHP, but honestly, I'd trade every new feature since PHP 5.2 for a bit more speed. With stuff like closures and traits it seems like they're working on the easy stuff instead of the necessary (but hard) stuff.
I don't think that an official compiler is planned but HipHop (http://en.wikipedia.org/wiki/HipHop_for_PHP) might change that in the future.
There are plenty of MVC Frameworks for PHP you can try with SilverStripe or CakePHP.
In this specific case, I don't think it's a good idea to do C#/ASP.Net in PHP and vice versa. Most PHP hosting environments do have a compile-once-run-many-times paradigm by virtue of opcode caching. The advantage over a typical Java or .NET app server is that you can change files and they get automatically recompiled on the fly. So for all intents and purposes, PHP is usually running a piece of in-memory compiled bytecode.
There are many MVC frameworks for PHP, for any interpretation of "MVC" you might want. I'm sure you can find one that's closely modeled after ASP.net, but again I'm not sure this is a productive undertaking in principle.
The development server seems like the only good thing about it.
Traits looks like a silly implementation of multiple inheritance mixins, with a 'use' keyword that doesn't really fit in with the language itself. And the whole 'insteadof' thing looks weird. It will lead to hackish code for many people, encouraging weird monkey-patching.
The author says "when stored in an array", then proceeds to use "$functions['anonymous']". That's not an array. Sigh. I know PHP likes to call them that, but I just find it weird that they would continue to insist on mis-naming two of the fundamental data types of computer science.
The introduction of closures can only be a good thing, and a lot better than the passing of a string name of a function as a callback argument from before.
As usual though, it's expected that most servers and frameworks won't get the update for some time, due to whatever backwards incompatible changes have been made.
I know it's all the rage to hate on PHP these days, but even giving an objective look at the state of the language, given the thriving ecosystems of its competitors, makes it look to me like something I would never touch.
> ...due to whatever backwards incompatible changes have been made.
PHP is normally very good that way, does anyone know of any backwards incompatible changes that have been made?
> I know it's all the rage to hate on PHP these days, but even giving an objective look at the state of the language, given the thriving ecosystems of its competitors, makes it look to me like something I would never touch.
Yes you're right, it is quite fashionable to hate PHP and has been so for the ~10 years I've been using it, but who cares it gets the job done (a language for the pragmatists not the purists).
But they're not arrays. JavaScript and Lua do the same thing, allowing you to assign numeric or hashed keys on objects (or tables in Lua), but they don't call them Arrays, because they aren't. Arrays have expected behavior and implementations. So do hash maps. It's fine to amalgamate them, just give it the right name.
> PHP is normally very good that way, does anyone know of any backwards incompatible changes that have been made?
I haven't looked at any in this version, but recently there was an article (I think on HN) complaining about severe ABI changes that required all compiled modules to be recompiled, leading to adoption problems.
> Yes you're right, it is quite fashionable to hate PHP and has been so for the ~10 years I've been using it, but who cares it gets the job done (a language for the pragmatists not the purists).
I used PHP for many years as well, and for that reason I don't think it's a language for the pragmatist at all. It's not expressive enough, it encourages bad coding, and it doesn't have an ecosystem comparable to Ruby, Python, or even the amazing one Node.JS has managed to garner in the past year or so.
PHP's arrays combine both vectors and associative arrays, but both numerically indexed arrays and associative arrays are types of arrays, are they not?
Arrays have expected behavior and implementations. So do hash maps. It's fine to amalgamate them, just give it the right name.
Whether associative arrays use hash maps underneath is an implementation detail, not fundamental to the interface PHP provides to [associative] arrays.
I would love to explain to my boss when I introduced some bad code into our repo: "But the PHP made me do it!". Really, if you can't use a tool without blaming it for when you use it badly, well...
* array? yeah, it's called like that. it could even be named "fridge" or "smartass".
* due to the new release process php BC is guaranteed for non major versions. adaption will be fast.
* thriving ecosystems don't matter, PHP is just one possible piece in the toolchain.
As for traits, sure but as with all things it depends on who will use them. Some will make a mess out of them, while other will use them properly. Just as with any other feature in any other language. Please stop using this tiered "reason" for why PHP is bad. It's just doesn't hold water.
The 'use' keyword already exists in PHP for use with namespaces; it's pretty common for C-based languages to overload common keywords.
As far as I'm aware, there are no backwards incompatible changes in this release and servers have been tracking the most recent PHP versions much better these days.
Also, array[1] is the correct terminology.
[1] http://en.wikipedia.org/wiki/Associative_array
I'm guessing this is at least some of the reason for that behaviour.
You can force it to work in the absence of a collision by using a __call override. An example of which can be seen here: https://github.com/TomNomNom/Talk---New-stuff-in-PHP-5.4/blo...
I'm going to assume it's a backhanded insult and chuckle along.
I am depressed that eaccelerator seems to be fading away - they removed their shared memory functions for their build with 5.3 support.
In my experience eaccelerator is slightly faster and more stable than xcache. As a bonus, when it did have working shared memory functions (under php 5.2) it has session handler support so sessions are done completely in memory (added: without any additional code or modification)
It is unbelievably easy to build session support for other op-code caches. Here is my code for APC:
The only problem is that this still requires you to compile the session extension. I am looking into ways of working around that, since it's not really used for anything except re-direction.eaccelerator's session handler (was) simply built in and requires no modification, just add the one-word setting to your php.ini
OK.
PHP has a very nice feature where you can automatically prepend (and append, if you want) a file to all requests. Create a single file, modify your php.ini, done.
I am not telling you that eaccelerator isn't amazing. I am showing you how to get around problems you may run into if you end up using a different op-code cache.
... and it will remain that way for a long, long time.