I've been waiting for PHP to use traits my whole professional career as a PHP dev. Super excited they're here now.
What to Look For in PHP 5.4
51–60 of 67 posts
Re: What to Look For in PHP 5.4
#52I'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 i…
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/).
Re: What to Look For in PHP 5.4
#53Earlier quoted context omitted.
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.
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 programm…
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.)
Re: What to Look For in PHP 5.4
#54Earlier quoted context omitted.
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 programm…
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…
"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 >". 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.
Re: What to Look For in PHP 5.4
#55I'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 i…
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 applic…
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.
Re: What to Look For in PHP 5.4
#56Earlier quoted context omitted.
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 programm…
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…
"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.
Re: What to Look For in PHP 5.4
#57I've been waiting for PHP to use traits my whole professional career as a PHP dev. Super excited they're here now.
Yeah, the lack of traits/mixins were the biggest problem with php's object model.
Re: What to Look For in PHP 5.4
#58Earlier quoted context omitted.
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 programm…
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…
> 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.
Re: What to Look For in PHP 5.4
#59Earlier quoted context omitted.
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 programm…
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…
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.
Sorry I can't be as advanced as you.
Re: What to Look For in PHP 5.4
#60I'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 i…
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.