PHP needs a champion, a Douglas Crockford and book entitled "PHP: The good parts".
PHP faces a lot of similar discrimination that JavaScript did for the longest time. Sure, there are still criticisms for JavaScript but for the most part people have settled and realized that to make JavaScript good you have to write good code. Which is exactly the case for PHP.
The trendiness of PHP bashing exasperates the actual issues of PHP which can easily be abated with good practices.
We need a call for someone to get up and preach the best practices of PHP. And with that, a call for PHP Lint based on those best practices. There are a few individual attempts at providing JS Lint type analysis for PHP files but nothing from anyone with clout. We could use an official analyzer supported by recognized field leaders pushing quality coding practices.
That solution worked well for Javascript, since it is impossible to remove the bad parts since they're embedded in older browsers.
For a server side language I would imagine a better solution is taking the good parts of PHP and creating a new language out of it. Its a very difficult thing to do, and attracting the top members of the PHP community will be challenging -- but could have a useful result.
I hate a lot about PHP, but it definitely has good parts. Python and ruby are great languages - but their style is completely different. I use PHP because there isn't a better alternative that "has the same feel."
The problem is that there are so many dissenting opinions on just what the good parts are.
I for one love PHP's natural templating ability, it's the main reason I use the language, but a lot of people think it encourages mixing business logic and presentation code.
I found that book to be disappointing, not up to O'Reilly's standards, and certainly not in the same league as JS: the Good Parts. I guess they rushed it out to capitalize, which is a shame.
will return a parse error, because sizeof is an unary operator despite looking like a function (the parentheses are mandatory when using it with a type name). In PHP, isset is implemented as a "language construct", essentially like another operator.
I believe that this (ideas thrown around) is the truth, Rasmus Lerdorf comes across as a very pragmatic developer who's more interested in getting things done rather than being an architectural perfectionist.
But I'm not saying that in a derogative way. Coming from C#, Java and Ruby, I feel that PHP is kinda fun and refreshing. The object model is quite simple, and I love the $$ (variable variable) syntax, and how 'reflection' is way simpler than any other language. It's language for hackers.
Just a disclaimer: I have zero work experience with PHP, just personal experience.
I put it inside quotation marks because it's not the true-reflection API per se, but I believe it was a mistake to even bring that up, and to generalize by saying it's easier than 'any other language'.
I was talking about old methods like get_class_methods, get_class_vars, get_object_vars and $$.
Here's an example which I used to answer another user above:
$a = new A;
foreach(get_object_vars($a) as $name => $var) {
$a->$name = $a->$name + 1;
echo $a->$name . "\n";
}
By no means those things are absolutely "beautiful", but they get the job done and they're one-liners, hence, simple. They're simpler than Java and C#, languages which I worked for years. Also they're easier than Ruby sometimes.
To be honest, I just think it is fun. I can make things in PHP with five lines that would take me multiple pages in C#, but the opposite is true too, for other areas.
Here's an example from the PHP docs on the reflection API, in the comments:
$a = new A();
$reflector = new ReflectionClass('A');
$properties = $reflector->getProperties();
$i =1;
foreach($properties as $property)
{
//Populating properties
$a->{$property->getName()}=$i;
//Invoking the method to print what was populated
$a->{"echo".ucfirst($property->getName())}()."\n";
$i++;
}
You have to instantiate another object to inspect the first one! Here's Python, just as an example. (Most languages would be simpler. As with most things, it would be difficult to find a language where reflection was more clunky than in PHP.)
a = A()
for i, key in enumerate(a.__dict__):
setattr(a, key, i)
f = getattr(a, 'echo'+key.capitalize())
print(f())
On another thread somewhere, someone once suggested that PHP is actually Blub -- a fictional language whose immense and inherent superiority cannot be explained, only experienced.
As a long time PHP dev, let me assure anyone who thinks that this is the case: in no way is PHP Blub.
> You have to instantiate another object to inspect the first one! Here's Python, just as an example. (Most languages would be simpler. As with most things, it would be difficult to find a language where reflection was more clunky than in PHP.)
I was about to agree with you then I remembered the work put into the Newspeak language (which I was once hopeful would replace Smalltalk as my favorite).
In Newspeak, reflection is always indirect because of security reasons.
You ask the system to give you a Mirror, and that mirror can reflect against an object you have access to. Security name-spacing and authorization is encapsulated into the mirror, so you can say:
- Give unauthorized users access to your VM with live objects, but they can't change anything because their Mirrors only allow for inspection.
- Make changes to a live object indirect. So if you add an attribute to object live object X, the system will go out of band---say to the database or announce to remote systems---that the change occurred and further action may be needed. That's great for access audits.
In that respect, PHPs reflection class isn't too bad. Though I think its a bit underpowered.
"Blub" isn't a fictional superior language; it's a fictional average language probably imagined to be similar to Java. It was, so far as I know first described here: http://www.paulgraham.com/avg.html
PHP is Blub in the sense that it is not the most powerful language[0], and some of its users decline to recognize that other languages have advantages over it. From my perspective, there can be no perfect language; certain characteristics are more optimal in some situations, less so in others and mutually exclusive. Type safety and certain kinds of dynamic behavior are an example.
[0] I'm not claiming here that any specific language is the most powerful, just that PHP certainly isn't.
What I mean is that the commenter believed that all other languages are Blub to PHP, as in, PHP is higher on the spectrum of powerful languages and other language users did not realize that they were looking up when they looked at PHP.
The naming of ReflectionClass is enough to make me want to cry.
I know naming things in CS is hard, but if you're having to put the word "Class" in your class names to make your code readable then you've got real problems.
I suppose that's fair enough. It's not exactly ideal though is it, but PHP's lacklustre naming conventions are hardly ground that needs to be trodden again.
That's why I put the word reflection inside quotes, I wasn't talking about the proper reflection API, but about functions like get_class_methods, and stuff like $$.
Here's an example similar to yours:
$a = new A;
foreach(get_object_vars($a) as $name => $var) {
$a->$name = $a->$name + 1;
echo $a->$name . "\n";
}
Also I'm a newbie when it comes to PHP, I never worked with, and I've been programming for almost a decade. Sorry if I didn't make it clear. I just wanted to make a positive comment on the cool aspects of a language which is mostly bashed around these parts.
I'd be happy if we moved to "+" for string concatenation and "." for object member access (but this would break every script out there). Though I've been a PHP user for 5+ years, I still do this when switching back from longer JS / Ruby development periods.
It doesn't want to read your Twitter direct messages.
Here's what's going on. The Twitter API currently has two levels of permission: "read" (can access your data, which includes your tweets and followers even if you have a private account, and unfortunately also your DMs) and "write" (can update your account, including posting new tweets, adding new followers, creating new lists etc).
Most Twitter users were unaware that granting "read" access to an application gave that application access to their DMs. This was a problem. Twitter opted to solve it by introducing a new permission level, "direct messages", which is write-plus-direct-message access. They plan to remove the direct message ability from the "read" access.
To give developers time to fix any apps that this would affect, the switch-over date for direct message access is set to June 30th.
Up until that date, the Twitter OAuth authentication screen includes copy that tells you that the application will be able to access your direct messages until June 30th.
This does NOT mean that the application author intends to access them - it just means that the permission level you are granting gives them that ability up until the cut-off date.
This issue is a big problem for people like us ( http://lanyrd.com/ ) who use Twitter for authentication, because it scares away potential users. At least after the 30th we won't have to worry about the DM clause, but we'll still suffer from users assuming that we're going to tweet on their behalf.
Unfortunately, we need "write" access so that the follow buttons on our site work (Twitter's new JavaScript follow buttons aren't appropriate for our attendee directory because we show 20 people on a page: http://lanyrd.com/2011/europython/attendees/ ) - we also need "write" access for our currently-in-alpha Twitter list management features.
The best solution I can think of would either be finely grained permissions (so we could ask for list and follow access but not send-a-tweet access) or the ability for us to specify a reassuring message to be displayed on the Twitter OAuth screen clarifying our intentions.
The application doesn't access your direct messages, but the bare minimum privileges for authenticated API access is "read only", and that happens to include the _access_ to direct messages.
Just an Idea. I think what causes so many sentiments against PHP is due in part to the mass adoption of PHP.
These days, you find PHP almost everywhere. And how do you get to PHP? Let's assume we are in collage and want to write that next big website that's surely going to rule them all.
Now, we don't really know that much about all this "tech" stuff. But hey, I can hit "show source" in the browser. This must be easy. After a few baby steps with a WYSIWY(WishYoud)G tool, you decide to learn /some/ HTML for good. Once you figure that HTML alone can't do a lot, there's a somewhat native path to PHP.
You keep on reading tutorials written by others, who know as much as you or a little more. You are still on the cheap side, and need to keep tight on your money for that next big website you are going to write.
And the more you read the more enlightened you feel. Wow! I can actually do that and my dead cheap webhost offers PHP as well. Life is good.
Because you don't lack any minimal intelligence, you figure out how to write your next (big) website. You probably didn't succeed in writing the next FaceBook, but hey, you are now /one/ of the /web guys/. You probably think what you are doing is real fun.
There are then two paths you can take:
- A: stick with PHP and feel enlightened all the way, when ever you learn some new trick, or
- B: wonder if PHP is the only true real thing. You don't know C or some other "ancient" language, so you are still a little afraid. Perl seems to look a lot like PHP but it's syntax is confusing and no one of your friends on the forums you are frequenting is using it anyway. Then there is Python or Ruby. Wow those look strange. No curly braces for function bodies. Why do people here talk about templating? What's this about? Do I need that? PHP was so easy... Anyway, you are still curious and learn about this "other" way of writing webapps (that's what we are still primarily concerned with). Once you start to figure out that variables do /not/ have to start with $ to be valid, you wonder what else PHP might have hid from your novice learning? There is a lot more. Not necessarily PHP's fault. Just the lockin in that PHP mindset.
----
The basic problem with PHP (to me) is that I've seen it to be more a motel on the way to enlightenment. Some just find it too comforting to move on. Others, once they've passed it, rarely(ever?) come back unless someone else tells (forces) them to do so.
"What PHP really needs is: Strong leadership and an official process to submit new ideas, extensions", "New blood, and less old blood.", "A plan for the future of web development".
PHP is an open source project, sure. But really, have you ever tried to volunteer for the PHP core? I've never gone through a more painful process -- so much political bullshit, resistance to change (even backwards-compatible change), and echo chamber nonsense. I attempted to volunteer on PHP for a long while, but finally realized it just wasn't worth it and gave up.
From what I've observed, when people try to contribute things most programmers, and even most PHP users consider to be improvements, the core team seems to reject them. Array literals are the example that jumps to mind, but I know I've seen other things along the same lines. The core team has a vision for PHP that doesn't match what most of us think of as good, so few people waste their time trying to fix it.
I added "To die", because that's my honest opinion after having been a PHP dev since ~PHP3. Whether it's the language's fault or not, my experience with other people's PHP code is that anything big tends toward spaghetti except in a few well-engineered cases. Non-pasta is the exception that proves the rule.
People who actually know something about programming well, frankly, would not start new projects in PHP. Its only use to me is as a litmus test -- if your answer to "What do you think of PHP" doesn't include a significant critique of the language, I probably wouldn't like working with you. (Nor you with me)
There's nothing inherent in the language that makes building non-spaghetti code difficult. All the weird annoyances and idiosyncrasies are a big pain in the ass but, unlike say COBOL or Basic (or even C), they don't fundamentally prevent you from building nice organized easy to understand code.
That being said, I totally agree with you -- other people's PHP code tends towards spaghetti in the vast majority of cases. My take from this is that if PHP were to disappear tomorrow all these programmers building spaghetti would just inflict their level of skill on other platforms.
There's nothing inherent in the language that makes building non-spaghetti code difficult.
Technically, that's mostly true. Culturally and psychologically, I'm inclined to say it isn't. Just as you're more likely to leave things lying around haphazardly in a room that's already messy, you're more likely to write sloppy code in a sloppy codebase. When the language itself feels sloppy, it's damn hard to avoid that effect.
Sure, you can write good code in PHP, but why would you want to when there are so many other languages out there? The only reason I can think of is if you're selling a product to be deployed on shared-hosting websites belonging to customers.
PHP is the default web language. If you're pitching to a client who expects to maintain the code once you're done and you suggest Clojure, Node.js, or even Ruby in a lot of cases you won't get the gig. By doing so you've raised their costs; PHP programmers are easier to find.
This is the main reason I'm not doing web consulting!
I don't think that's actually true, aside from maybe $10/month extra in hosting[0], I think costs tend to be lower with not-PHP. Using PHP greatly increases the probability that a random contractor will be a bad programmer who will write things that are broken, require more billable hours to get things done or make a mess that slows down the next guy.
I've never lost work due to suggesting not-PHP to a client. I have, however regretted failing to do so several times. I've come to believe that a client's insistence on using PHP is nearly as much of a red flag as a programmer not knowing anything else.
[0] If a client is worried about $10/month extra in hosting costs, you'll probably also have to fight them for every dollar. They might even try to get out of paying what they agreed to. I've had it happen.
I like to think -- informed by my own experience -- that PHP collects a disproportionate share of bad programmers because it's the easiest for bad programmers to use. Chiefly, it is possible to start writing scripts with not even a modicum of planning and forethought; you only need to know what your filename will be. So it stands to reason that they would move on to the new easiest language for bad programming.
Or maybe they would rediscover their passion for something other than web dev, go back to school and get English degrees.
I disagree; it's possible to write programs with planning and forethought in any language, and even simple languages like Python have much higher average quality code.
I think it's a matter of culture, which is reflected in the language itself and in the community that surrounds it and writes code samples and OSS software.
I don't think it's a matter of culture so much as a matter of scale. It's the same with most web communities, the quality of the community tends to go down as the membership increases.
Any language that lets you mix it in among standard HTML is going to generate spaghetti a lot of the time, because page order display and logic flow are inherently contradictory. Logic flow should be hierarchical and static, while page display is a text representation of visual UI choices having little or nothing to do with the logic of the data behind them. But for generating models, it's nice and quick. And for writing form/json/flash service code it does certain things extremely well; you can take a json object, parse it, escape it, run it through a mysql query and return a nicely formatted result object in about five lines. Again, it's whatever you want it to be.
The lack of commenting and downvoting means this list will lack any kind of real curation. There's several large blocks of text on the popular list that should have been submitted as multiple items.
This is ridiculous. It's like saying hammers should include screwdrivers. Just know your toolbox and you won't have a problem.
PHP is great. What's with all the hate? It's a good tool for a certain kind of job, not the right tool for others. Big deal. There isn't a single language that you can't find bones to pick with. It's all about what you do with it and how you like to code. If you're comfortable writing server-side script in brainfuck, more power to you.
Some people want every language to be just like Java, so they can switch between languages with little to no effort -- never mind we'd have only Java in the end.
Some people want everything abstracted out, so no implementation details have to pe paid attention to -- nor leveraged, ever.
Some people won't believe a language supports something until there's a class explicitly named after it (``proper unicode support'' my ass -_-').
Some people believe an object wrapped around something will magically make it better (``a core object that represents the HTTP Request and Response'').
The list goes on...
Please let PHP remain PHP, at least let it retain the good parts :-)
So, uh, can't we all just get along? I mean, I could make a list about why Java's a nightmare, or Javascript or C# or something else, but if I were hiring a coder who said, "yes, we must write this server in Neko" I would say, "okay, why?" And if the reasons were good, then great. Do it. These are just tools. You should never lean on them for something they weren't designed to do; but if you find that one matches the job, then use it!
PHP faces a lot of similar discrimination that JavaScript did for the longest time. Sure, there are still criticisms for JavaScript but for the most part people have settled and realized that to make JavaScript good you have to write good code. Which is exactly the case for PHP.
The trendiness of PHP bashing exasperates the actual issues of PHP which can easily be abated with good practices.
We need a call for someone to get up and preach the best practices of PHP. And with that, a call for PHP Lint based on those best practices. There are a few individual attempts at providing JS Lint type analysis for PHP files but nothing from anyone with clout. We could use an official analyzer supported by recognized field leaders pushing quality coding practices.