The PHP Singularity 622
An anonymous reader writes "Jeff Atwood at Coding Horror has a post about the awfulness of PHP — or, rather, a post about posts about the awfulness of PHP. He points out that PHP has been the whipping boy for the developer community for years, and while everybody seems happy to complain about it, nobody seems willing to do anything about it. He writes, 'From my perspective, the point of all these "PHP is broken" rants is not just to complain, but to help educate and potentially warn off new coders starting new codebases. Some fine, even historic work has been done in PHP despite the madness, unquestionably. But now we need to work together to fix what is broken. The best way to fix the PHP problem at this point is to make the alternatives so outstanding that the choice of the better hammer becomes obvious.'"
Recursive? (Score:5, Funny)
And now, a post about a post about posts about the awfulness of PHP.
Which would make these comments posts about a post about a post about posts about the awfulness of PHP.
---
Recursion: First you curse, then you curse again.
It's always been obvious (Score:4, Insightful)
Python has *always* been obviously better than PHP (or perl, etc.) But if you have no skills, you look for the easiest path: the goal is to get the project going.
If your expertise is Perl, climbing the Python learning curve, gentle as it may be, isn't attractive, and becomes less so as your available time to engage in such things narrows. And so your project $sucks @terribly $$ and looks like APL But it works fine because you know how all that perl weirdness operates:
$_ = shift;
tr/+/
s/%(..)/pack('c', hex($1))/eg;
return($_);
For a new user with no skills (which really seems to be the primary group that ends up using it), the availability of PHP examples and the ease of putting a canned site up seem to be the primary enticements. Slap a canned site up, and bam, there you are. *Now* you can learn how it works (which accounts of a lot of strange things on the web, but I digress.)
So better isn't really the issue. Easier is the bottom line, it seems to me. Where are the canned sites in Python? For that matter where are the canned sites in Perl or Ruby or whatever?
If "better" were all it took, no one would be running Windows, for instance, but that's not the case.
Mind you... *I'm* not running windows, and I long ago abandoned Perl for Python (and I'm so glad I did), but I'm someone who actually has the time to explore and make choices without someone else hovering over my shoulder or otherwise being compromised. I don't think that's very common.
Re:It's always been obvious (Score:5, Insightful)
Re:It's always been obvious (Score:4, Insightful)
indeed , PHP can very much be 'good enough'. Nowadays I prefer other languages, but i struggle to understand the hate towards php. Yeah, it might have some warts, but it has a standard lib that does pretty much al you can ask for and it runs on pretty much all webhosters.
Re:It's always been obvious (Score:5, Funny)
Python has *always* been obviously better than PHP (or perl, etc.) But if you have no skills, you look for the easiest path: the goal is to get the project going.
If your expertise is Perl, climbing the Python learning curve, gentle as it may be, isn't attractive, and becomes less so as your available time to engage in such things narrows. And so your project $sucks @terribly $$ and looks like APL
This is how I can tell that you're not an APL programmer. APL programs are beautiful. Perl looks as if your mom picked up the phone while you were using a BBS.
Re:Recursive? No, very iterative. (Score:5, Insightful)
Ever since programming languages existed, they have been classified in 2 categories:
- Those every one bitches about,
- and those nobody uses...
Re: (Score:3)
Re:Recursive? No, very iterative. (Score:5, Insightful)
Ever since programming languages existed, they have been classified in 2 categories: - Those every one bitches about, - and those nobody uses...
Sounds clever, but it's plainly false.
C, Java, C# are among the most used languages today. Very few serious programmers will say that they are stupid or awful. And, many criticisms aside, most programmers respect them - even love them. I program in all these languages, I like them all, and I hate PHP with passion. It's not an issue of popularity; PHP, its community, its history, all of it, is a tale of terror.
Re:Recursive? No, very iterative. (Score:5, Insightful)
Very few serious programmers will say that they are stupid or awful.
Huh? Have you just fallen off the turnip truck?
C: Unsafe at any speed. Un-bound-checked array, null pointers, etc, etc. Many people HATE C because it's unsafe, though they grudgingly admit that it's sometimes a necessary evil for system programming.
C++: Overly complex, insane learning curve, no garbage collection. There are no shortage of people who hate C++.
And Java is possibly your most absurd point. Overly verbose to the extreme, slow, insane memory requirements, slow, crazy libraries, and slow (please don't bother to claim that isn't slow).
Re:Recursive? No, very iterative. (Score:5, Funny)
C is so awful that nowbody would dare use it for any serious stuff, like kernels or drivers!!!
Comment removed (Score:5, Funny)
Re:Recursive? (Score:5, Informative)
PHP itself is an acronym for PHP: Hypertext Preprocessor.. But then what does "PHP" stand for?
It's an old joke, already trite by the time PHP came out.
GNU = GNU is Not Unix
Wine = Wine Is Not an Emulator
PNG = PNG is Not Gif (later backronymed to Portable Network Graphics)
LAME = LAME Ain't an MP3 Encoder
VISA = VISA International Service Association
Re:Recursive? (Score:5, Informative)
PHP was originally Personal Home Page Toolkit, then backronymed into the new meaning.
Re: (Score:3)
Yeah, when I started using it (back before PHP 3.0), it was actually called "PHP/FI", which stood for "personal home page / forms interface".
Re:Recursive? (Score:5, Funny)
BING = BING is not Google.
Re: (Score:3)
Re: (Score:3)
No, silly, ElePHPants.
Really? (Score:4, Insightful)
What kind of bullshit logic is that? Something is broken, everyone hates it, so let's put all our efforts in making the alternatives better? How about contributing to PHP and fixing what you're bitching about instead of, well, bitching about it? You know, it's open-source and all.
Re:Really? (Score:4, Insightful)
The problem lies at its core [php.net]. You can't fix people.
Re:Really? (Score:5, Insightful)
Indeed. For years now it's been patiently explained over and over and over again what needs to be fixed, and the core team just keeps perpetuating the same crappy nonsense. Since there are other perfectly good languages out there, I see no point in anyone, say, forking PHP.
Re:Really? (Score:5, Insightful)
But that's a valid fix. PHP has been enforcing basic type constraints on internal functions for years. And before that it was throwing up E_STRICT warnigns (that people ignored).
So now that these strict warnings are causing issues because of bad coding practices. You should -always- know what type your variable should be in a context -- saying "it could be an empty string, null, uninitialized, or a number" means you have more serious issues in your program logic to address.
Re:Really? (Score:5, Insightful)
I don't know. It looks like some guy has code that sends uninitialized or null values which to me would invoke undefined behavior and is then bitching about when that behavior changes.
From the thread: We are passing a (possibly uninitialized, or null-valued) variable to the function, in hundreds of places
Sounds to me like this guy has other issues he should be worrying about.
Re: (Score:3)
Period.
It's a bug, the submitter is correct.
Re:Really? (Score:5, Insightful)
No, 0 is not NULL. But "" cast as an INT could be considered NULL. It's not an INT. The parameter of 0 means 0 digits after the decimal. Why they don't just round or floor/ceil instead, I don't know. But first things first - you need to pass in a number to format a number.
Re:Really? (Score:4, Insightful)
Actually for once I agree with the PHP team here. My biggest complaint with PHP is that many functions give you an arbitrary result when you feed bad data to it rather than return something obvious to show you are trying to do something stupid. In this case the user should be checking to see if the result was NULL and handle the error appropriately rather than happily accepting 0 and not knowing if there was an error or if that was the correct result. Basically he is refusing to validate his input and wanting PHP to do it for him (in a bad way) which is the core of problems like SQL Injection attacks.
The formatting in DateTime is a perfect example of their absurdity where if you specify 'Y' (4 digit year) in your format but give it a less than 4 digit value (say 12 instead of 2012) it happily makes the assumption that you left out leading zeros (e.g. 12 = 0012). Even better is that if you give a month value greater than 12, it translates that into extra year(s) (int(val/12)) that gets added to the supplied year and then makes the month the remainder (e.g. 19/27/2012 against m/d/Y = 07/27/2013). If I screwed something up, I want to know about it so I can deal with it.
Then there is the inconsistent error handling functions. Most errors return NULL or false. Of that cross section most don't give you any kind of feedback as to what the error is (though the ones that give you no control and write to STDOUT/ERR really piss me off). The language has Exceptions built in. Use them!!!
And my personal pet peeve is how it handles the __FILE__ macro if there are symlinks in the path. Contrary to every other language it translates those links so that you can't see the ACTUAL path used to reference the file in question. Even though PHP has functions to translate links in paths the developers continue to claim this is as it should be and refuse to fix it.
Re:Really? (Score:5, Insightful)
Poor example. Someone goes bananas when incorrect and inconsistant behaviour ( returning a number from a number formatting function when passed something that is not a number) is changed to correct behaviour consistent with the rest of php core (returning something that is not a number), after months of pre-releases and 'this is going to break buggy code' announcements, after everybody else has fixed their buggy code, and starts name calling, rather than:
a) fixing their own buggy code or
b) not upgrading the minor version on affected systems until their code is fixed
This looks like a problem with the submitter, not the PHP team.
Re:Really? (Score:5, Insightful)
Yeah, it sucks when languages and APIs change, but it happens and if one is going to be upgrading one should take such things as a given. This is why, when you have an environment where consistency is important, language and library upgrades are big deals that are scheduled with time allocated them.. otherwise freeze your versions unless there is a compelling reason with significant measurable benefit to upgrading... crow, I still keep VMs around in case I need to go back and work with earlier checkouts with known dependencies/versions.
Re: (Score:3)
Actually, I would put the fault on the complainer here....
So would I.
I especially like how he asked Rasmus Lerdorf to "escalate this bug to someone"...
CJ
Re:Really? (Score:5, Insightful)
I honestly don't see how this demonstrates any problem with PHP people.
The guy was using some function in what appears to me as the wrong way (failed to validate inputs) and was relying on some edge-case behaviour. Now this edge-case behaviour has changed and made the mistake in his code more apparent.
I hate PHP and try to avoid it like plague, but this guy got what he was asking for.
Re:Really? (Score:4, Insightful)
The guy was using some function in what appears to me as the wrong way (failed to validate inputs) and was relying on some edge-case behaviour. Now this edge-case behaviour has changed and made the mistake in his code more apparent.
One of the things I hate about PHP was the number of times that calling a function with bad data "just works" even though it really shouldn't. (Primarily because it effectively dumps the checking onto you.) That looks like a perfect example - if you try and format a thing that isn't a number, it "works" and returns 0. Huh? That's not right. That should be an error.
And now, it is! It notices the error, and returns NULL instead of pretending that a string is a number. Great!
Someone elsewhere in this thread was complaining about mysql_escape_string and mysql_real_escape_string, and how they should have just fixed mysql_escape_string. It sounds like the person filing the bug report would have rather they created a real_number_format function rather than fix a bug in the existing number_format function.
Re:Really? (Score:5, Insightful)
That's not a good example. You want a good example of PHP core team competence, check this saga about fixing an integer overflow bug [perl.org], for example.
Or just contemplate about how 20 year old language didn't have the ability to chain method calls and field lookups on objects returned by functions until release 5.4 - it was a _syntax_ error before.
Or how strings are compared as numbers in unexpected places. I'm not talking about "42" == 42, I'm talking about "42" == "42.0", or "10" == "0xa". Well, using == in PHP is discouraged for reasons like this one anyways (which in itself is quite telling), but check this one out - if we have $x = array('42'), in_array('42.000000000000001', $x) will be true. Can't check this at the moment, but IIRC it's still there in PHP 5.4
It's bad design through and through. It was OK when it was an hobby project for templating a small homepage, but then it started growing and instead of designing features it got ad-hocs piled on ad-hocs.
Re:Really? (Score:5, Insightful)
How can you properly debug code if documented fuctions dont behave in the way documented and acts inconsistantly??
Re: (Score:3)
The PHP manual doesn't say that it will return 0, it says that it will return a formatted version of the $number input. When that input variable isn't a float as the function expects, exactly what is the function supposed to return?
http://us2.php.net/manual/en/function.number-format.php [php.net]
string number_format ( float $number , int $decimals = 0 , string $dec_point = '.' , string $thousands_sep = ',' )
Maybe it should cause a fatal error because the input did not meet the criteria, would that be better?
Re:Really? (Score:4, Informative)
Maybe it should cause a fatal error because the input did not meet the criteria, would that be better?
Yes, it would be. Silently failing is one of PHP's most common and egregious sins. I'd rather it fail and fail loudly, so bugs like this can get fixed during development.
Re:Really? (Score:4, Insightful)
Yes throwing an error would be better than an inconsistent or, for some developers at least judging by the comments, an illogical result. If the input doesn't make sense then throwing an error is the only sensible way of dealing with it. This will flag the issue to the developer rather than leaving the possibility of an edge case bug sat in the code. But it would appear the PHP devs don't think like that and instead like to preach that their arbitrary way of doing things is better than some other arbitrary way of doing things.
Re: (Score:3)
In SQL null for numbers is NULL.
In other areas, null for numbers might be NaN: http://en.wikipedia.org/wiki/NaN [wikipedia.org]
Re:Really? (Score:5, Insightful)
Just because someone has been successfully writing bad code for years is not a good reason for the maintaners of the language to enable him to write bad code. The changes were available for testing long before the final version was released. He could have spoken up during the RC phase, but he didn't. He should have tested his code against the RC version and started fixing issues in his code before the final release. Instead, he just installed the new release and started bitching.
Go ahead and send the link. They'll read that bug report and say to themselves "Why was he sending an empty string to number_format? What did he expect?"
And they will realize that they've been doing it right all along.
Re:Really? (Score:4, Insightful)
Just because someone has been successfully writing bad code for years is not a good reason for the maintaners of the language to enable him to write bad code.
This is what happens when you start with a sloppy language. People depend on the sloppy behavior, and if you then decide to become more strict, you break people's code. The right way to do this is deprecate the function and introduce a new one.
Go ahead and send the link. They'll read that bug report and say to themselves "Why was he sending an empty string to number_format? What did he expect?"
"We are passing a (possibly uninitialized, or null-valued) variable to the function, in hundreds of places and web pages, and we would not expect such a fundamental function to suddenly return a different result."
So they were depending on existing behavior. Is this shocking? In a language like PHP?
He could have spoken up during the RC phase, but he didn't.
"I get it. Yours is bigger, you've worked better, you are at the cutting edge of everything, and you have infinite resources to test every new version of every piece of software in your stack."
How many people can honestly say they keep up with alpha or beta releases for software they depend on and provide feedback? I've never worked in such an environment.
There is one very funny bit in that link, where he asks Rasmus to "escalate" the issue.
Re: (Score:3)
Fork?
Fork You!
Re:Really? (Score:5, Informative)
PHP is well beyond fixing - mysql_escape_string and mysql_real_escape_string prove it, otherwise the first method would have been fixed rather than "replaced".
The best you can hope for these days is overlaying a framework.
Re:Really? (Score:4, Informative)
PHP is well beyond fixing - mysql_escape_string and mysql_real_escape_string prove it, otherwise the first method would have been fixed rather than "replaced".
They had to do it this way for backward compatibility. If they changed the way it works, then any program that relied on the existing (buggy) behavior would break as a result.
Re:Really? (Score:5, Insightful)
That's what major version bumps are for. Make it a breaking change, rather than make it something that festers in the codebase forever. If the method is broken, then the solution is not to let apps continue to use it.
Make it a breaking change, bump the major version up, force people to upgrade through obsolescence and we would be in a much better situation.
Re:Really? (Score:5, Interesting)
What kind of bullshit logic is that? Something is broken, everyone hates it, so let's put all our efforts in making the alternatives better? How about contributing to PHP and fixing what you're bitching about instead of, well, bitching about it? You know, it's open-source and all.
An important part of fixing something is being able to recognize when it's better to throw it away and build it again. PHP has so many problems, in each layer down to the bottom, it's way past the "We can fix it if we apply ourselves": it's better to throw it away and build it again. Something like a new scripting language called PDR ("PHP Done Right").
Re:Really? (Score:4, Insightful)
From what I've heard, that's pretty much what Facebook did - start off with PHP and eventually evolved their own language from it.
Re:Really? (Score:4, Insightful)
This is the real solution, because let's face it: not everyone needs a java instance running with -MmmXxWTFBBQMemory 500000000 and 60000 classes to run a forum. People use PHP when they neither need nor want "application servers", they want it to just work.
Make a mod_pdr (or at least a fastcgi-compatible script executor where nobody has to implement the fastcgi protocol by hand for every single script like python or ruby), and you'll have the attention of the hosting people. They don't want to have to babysit 50000 different users' rails or tomcat instances, so they don't offer them.
Re: (Score:3)
What kind of bullshit logic is that? Something is broken, everyone hates it, so let's put all our efforts in making the alternatives better? How about contributing to PHP and fixing what you're bitching about instead of, well, bitching about it? You know, it's open-source and all.
The unspoken argument here is that the complainers are no longer trying to contribute to PHP by providing feedback. Rather, they have determined that PHP is fundamentally terrible at doing the work it's been recruited to do. Fixing it to be "the best possible wrong tool for the job" would not be productive.
Because it looks like it should work, you don't have the benefit of understanding that it doesn't until you've wasted your time using it and have probably committed a good deal of your project to it tryin
Re:Really? (Score:4, Insightful)
If I announce that I'm going to try to cross the Atlantic in an inflatable dinghy, there are two possible responses which a reasonable observer could have:
1. Tell me I am an idiot and going to kill myself, and to use a proper boat instead, of which many excellent designs are readily available.
2. Help me design and build the world's most awesome rubber dinghy, which, in the end, is still a rubber dinghy and still probably going to get me killed.
Re:Really? (Score:5, Insightful)
The problem with "fixing" PHP is it breaks compatibility with existing code. Not all of it, but a lot of it, because it was either written by complete imbeciles who just happened to get lucky, or brilliant coders who worked around PHP's perversions.
I'd like to think I fit in the latter category. I actually really like PHP because it's so dumb and open-ended, it lets me code whatever the hell I want without forcing much functional-programming hipster crap down my throat (I'm staring at you: Python/Ruby/Haskell/Scala/Clojure).
Yes, it's messy, and yes, it could greatly benefit from a concerted cleanup effort, but given it's install base and the mind-numbing amount of public code in use, it's hard to justify the pain in fixing all that stuff. Just think of the tens of millions of sites running some spinoff of PhpBB, the countless MediaWikis, nearly every torrent tracker, and all those pages of horrible code written by the aforementioned imbeciles. That's a lot of pain to satisfy a few pedants. Clearly, PHP works "well enough" for most of us.
That said, nothing's stopping people from forking it, fixing that code, and releasing it as something new. If it's better than PHP and helps me land paying work, or make my own projects easier to develop and maintain, I'll happily use it. Ah, but that would require these people to stop posting inflammatory linkbait on their canned Wordpress blogs and actually practice what they preach...
Re: (Score:3)
it lets me code whatever the hell I want without forcing much functional-programming hipster crap down my throat (I'm staring at you: Python/Ruby/Haskell/Scala/Clojure).
Who's forcing "functional programming hipster crap" down your throat in Python? Have you even tried coding in it?
Re:Really? (Score:4, Interesting)
Because no amount of polishing turd will make it into gold. PHP has some fundamentally wrong assumptions in its design, you can't fix it without just making it something that isn't PHP.
Re: (Score:3)
Why contribute to a project that has such a solid record of recklessly incompetent leadership? Why work to prop up an ecosystem that has developed into a vast toxic swamp?
The advantages of PHP have always been reducible to the fact that it is relatively easy for non-programmers to understand. It's accessible for people who don't have a mindset for or interest in computer science. That's not inherently a bad thing, but it is risky. As with VB before it, it is true that any crazy idiot can code in PHP, so man
Re: (Score:3)
The advantages of PHP have always been reducible to the fact that it is relatively easy for non-programmers to understand.
I would add that it's widely available. Pretty much any $4/month hosting plan is going to have PHP available. I'll warrant that this has caused some people to use PHP for Web sites when they might not otherwise have done so.
Re: (Score:3)
This is a very important point that all the elitists here keep forgetting about. Want to set up a small, low-volume website on the cheap? There's a ton of less-than $5/month shared hosting providers out there, and all they seem to support are Perl and PHP, so PHP is the choice by default. I keep seeing posts here saying "use Python!", but I don't see much support for Python in the cheap hosting providers, let alone Java.
Re: (Score:3)
We already have fixed versions of PHP the language. They're called Python and Ruby.
We just need to work on the deployment.
This is exactly it. I write nearly all my code in PHP, and it is not for a love of the language. I switched to PHP from perl (after taking a good, long (and longing) look at python) for two simple reasons:
Re: (Score:3)
I knew an admin who'd work on PHP for doing his server maintenance. He hated PHP on web based applications. You kinda remind me of him.
Yep, I do that too. Most of the time, when I need a small bullshit script for something, it's PHP. The DB integration and no-brainer multi-dimensional arrays make it way too easy to do so many things. I even wrote a bunch of MAME tools with it, because it was the easiest language for quickly parsing ROM parent relationships into a tree and running various operations on the archives with the same fine-grained control as C, but the immediacy and simplicity of shell scripts.
if php is broken what is javascript? (Score:4, Interesting)
if php is broken what is javascript?
Re:if php is broken what is javascript? (Score:4, Insightful)
if php is broken what is javascript?
A disaster.
Re: (Score:3, Insightful)
The World's Most Misunderstood Programming Language
http://javascript.crockford.com/javascript.html [crockford.com]
Re: (Score:3)
If you're doing a crazy dance with the global namespace, you are doing it wrong. Function scope works if you understand it.
Using a lambda that is called immediately just to create a new scope is a hack, plain and simple.
It isn't C, stop comparing it to C, really has nothing to do with C.
I'm not comparing it with C. I'm comparing it with every other language out there that has the same features. They all do it the same way, except for JS.
For example, the only language that has similarly stupid scoping rules (where the scope of any local is the entire function, even if it's declared inside a nested block) for locals as JS is VB6. But at least VB6 didn't have closures!
Why are you leaving out semicolons, that is bad practice
You miss the point. I'm not l
Re: (Score:3)
if php is broken what is javascript?
Still better than PHP?
Re:if php is broken what is javascript? (Score:4, Interesting)
if php is broken what is javascript?
If you've ever played Secret of Monkey Island, look at the poster of the woman near the bar.
"When there's only one candidate, there's only one choice."
and (Score:3, Insightful)
if one is happy with PHP and has still not encountered peculiar problems?
Re:and (Score:4, Insightful)
Welcome to the club.
Some of us are getting shit done with PHP. To me, that's all that matters. If all these whiners got together, forked PHP into something cleaner and faster and posted THAT to their shitty blogs, I'd be all over it.
Programming isn't about having the prettiest language. It's about accomplishing whatever it is you need accomplished, using whichever tool gets you there in the most efficient manner. These "solutions" provided by PHP haters are the equivalent of saying "I'm scared of big trucks, so here's a purple unicycle driven by an albino puppy who can bark the first 400 digits of Pi in reverse", when the problem was "I gotta move 83 tons of unobtainium from here to there by Tuesday".
Perhaps it is not broken and horrible (Score:4, Insightful)
PHP is a language for getting thing done. Just like any toolbox, you can build great or terrible things with it. It's like perl in that way (and I've done plenty of both). If you code well, there's very little to complain about with PHP. I've hired java guys onto my php projects before, and they were up and running in a week or so because we were coding with some structure instead of slapping together hacks.
And personally, I wouldn't want it any other way. I don't want language designers deciding they know what I want to do better than me. What I want, is the flexibility to build things as I see fit, and to do so quickly. Production is my goal. If you can help me build my projects elegantly/etc, then great, but getting it built quickly is always my priority.
Re: (Score:3, Informative)
PHP is a language for getting thing done. Just like any toolbox, you can build great or terrible things with it. It's like perl in that way (and I've done plenty of both). If you code well, there's very little to complain about with PHP.
I might be misinterpreting you here, but this sounds like a point responsed to in PHP: A Fractal of Bad Design [veekun.com]:-
Do not tell me that "good developers can write good code in any language", or bad developers blah blah. That doesn't mean anything. A good carpenter can drive in a nail with either a rock or a hammer, but how many carpenters do you see bashing stuff with rocks? Part of what makes a good developer is the ability to choose the tools that work best.
You also said:-
And personally, I wouldn't want it any other way. I don't want language designers deciding they know what I want to do better than me.
I also think the problem a lot of people have with PHP is its inconsistent and illogical bad design, which isn't the same thing as flexibility. I don't think having a logically designed language necessarily means one that forces its philosophy on you. I'll note that the fractal post referenced above also states that:-
I assert that the following qualities are important for making a language productive and useful, and PHP violates them with wild abandon. If you canâ(TM)t agree that these are crucial, well, I canâ(TM)t imagine how weâ(TM)ll ever agree on much.
* A language must be predictable. Itâ(TM)s a medium for expressing human ideas and having a computer execute them, so itâ(TM)s critical that a humanâ(TM)s understanding of a program actually be correct.
* A language must be consistent. Similar things should look similar, different things different. Knowing part of the language should aid in learning and understanding the rest.
* A language must be concise. New languages exist to reduce the boilerplate inherent in old languages. (We could all write machine code.) A language must thus strive to avoid introducing new boilerplate of its own.
* A language must be reliable. Languages are tools for solving problems; they should minimize any new problems they introduce. Any âoegotchasâ are massive distractions.
* A language must be debuggable. When something goes wrong, the programmer has to fix it, and we need all the help we can get.
(Apologies for the cut-and-paste splotches, but I don't have time
Re: (Score:3)
Good programmer = good PHP code (Score:4, Insightful)
Any good programmer will be able to make awesome PHP code. Bad PHP written applications are just the result of lack of passion, knowledge, and in some cases don't forget it, pressure from the customer. Combine bad programming skills, no experience with other OOP languages, pressure and "I don't care how it is done, I've done it and it works that's enough"... and you get the result. I'm tired to read and hear that PHP is shit. -- ParaBug
Re:Good programmer = good PHP code (Score:4, Insightful)
Obligitory (Score:3, Insightful)
PHP has only its members to blame (Score:5, Interesting)
Years ago I was involved with PHP, and the core developers have no real interest in making anything better, or, more specifically, accepting any criticism. I'm not the only developer to be pissed off when decisions are made "off line" and passed down. There was no sense of community. In conversations with other would be contributors, the general consensus was the PHP was headed up by a bunch of pissy children.
Don't get me wrong, I think PHP is a powerful environment and a lot of things have been done with it, but it suffers from a lack of rigour. If they could decide *what* the hell the language wanted to be, that would be helpful. If they could clean up the extensions API that would be helpful too. PHP's extensions are so powerful but there is no abstraction, your extension is essentially a PHP internal module.
All in all, PHP has had power and potential for years, but the reason why ruby even had a shot was that the PHP project can't get its act together to address, or even acknowledge, its short comings.
PHP alternatives (Score:5, Interesting)
The one big redeeming feature of PHP is you set up a single DB server (or even multimaster) plus multiple webservers, and bam! You're sharing objects/sessions among the webservers. Doesn't matter what webserver the next request hits, the session's there.
By contrast, that simple thing is something that other environments struggle with. I remember ads for "Share Java POJOs" as if that was a huge deal, and the CEO of some firm that did that said people told him that was a godsend. I'd imagine it's the same for Python and Ruby.
1. Java. Huge memory footprint. Admins hate it because it doesn't conform to certain Unix conventions.
Try this: Download any one of a number of open-source Java CMSs or ERM systems. Then watch the Java exceptions flow down your console screen. Good luck figuring them out. Static analysis rules, except when it doesn't.
Java's great if you're writing an desktop app for geologists trying to find oil or a backend bank system. For your average, ho-hum, billion-dollar website: not so much.
2. Ruby: You go to war with the webserver they give you, not the one you want.
3. Python: Great language and library. A shame it was hobbled by the whitespace issue, which meant that some programmers didn't check it out who should have. Anyway, it's hard for Beta to get traction against VHS.
Anotherwords, PHP is good enough. "Worse is better. [wikipedia.org]"
Since the three environments above are monolithic, if there's a problem, it's a problem for every client logged in. PHP, by contrast, follows a Unix minimalist philosophy: if a PHP FCGI instance (or even an Apache mod_php instance) crashes, it's just that one instance. No problem, user hits F5, reloads, PHP's stateless, you get the session back, keep calm and carry on.
When Marc Zuckerberg or a number of other entrepreneurs started hacking out Facebook, they started out with PHP, just because it's light and fast, and easy to get something up on the wall. Nobody cares about the elegance of Python or Ruby, it's all about time to market.
Finally, nothing about "you can't debug PHP", in today's discussion, please. You can very well step through PHP code. Use Netbeans and something like xdebug. Or Eclipse.
PHP: Paraphrasing Churchill, it's bad, but the alternatives are worse.
Re:PHP alternatives (Score:4, Insightful)
The biggest problem I have with python is that it spoils me. Writing python for a couple of weeks then having to jump back into a C syntax language causes me pain. It takes a few days again to get over the fact that I am constantly having to type cruft just so the compiler knows what I mean.
Re: (Score:3)
He is trying to say that improving the alternatives is easier than fixing PHP.
Re: (Score:3)
Java, Ruby, Python... Perl... none of these were invented for serving dynamic web pages. PHP did.
Re: (Score:3)
amen to this - the reason (listen up other language guys) is that it's just there, ready to go. Want to write an app, just drop a php file in a directory on your webserver and ... well, that's it.
PHP is like the old personal computers of yesteryear, the ones that booted into a BASIC prompt.
My experiences with Ruby and Python have been quite less than satisfactory, ruby required a hell of a lot of hassle to get going, installing passenger, making a symlink in the apache vhost directory to the ruby code files
Re:PHP alternatives (Score:4, Insightful)
I notice that most (not you, obviously) of the PHP defenders are posting as A/C. :)
There is no doubt that PHP has some deep flaws, but they give you an escape from a lot of the flaws. It's possible to have a reasonable codebase written in PHP if you have good experience in the language.
The main reason I like PHP is that it's ubiquitous. I learned a long time ago that it SUCKS to work in an unpopular environment, even if it has some sort of theoretical advantage. It's hard to find information, libraries are nonexistent or buggy, programmers are hard to find or expensive, etc, etc.
As I see it, there are only four viable language if you want to stay mainstream: Java, C++, C# and PHP. If you want to avoid Microsoft, you're down to three. If you hate Java's verbosity, slowness and pain, as I do, you're down to two. And if you want quick productivity and rapid development for entrepreneurial reasons, that eliminates C++ and also eliminates Java again, and that leaves one to rule them all: PHP.
I don't particularly like PHP. But it does have a lot of modern language features, and it's really easy to get code written and out. And it's reliable, if you put in the work to establish a framework (E_STRICT, turn on exceptions, etc).
I would love to see a better mainstream language emerge, but PHP just plain wins out for certain purposes. If I was working for a large organization with plenty of time and money, I'd probably pick C++ or Java. But for a small, hungry organization, it's hard to beat PHP, which was forged by necessity. And I wish I could beat it, because it does have some pretty big flaws.
Thats it! I am leaving (Score:5, Funny)
Going to Perl where I can get a simple concise syntax that is always the same among different programmers and does not have any idiosyncracies and enforced consitancy everywhere.
Lousy Developers (Score:3)
If PHP were as awful as the author claims, "Some fine, even historic work has been done in PHP" would not be possible.
Coders without the most basic grasp of object oriented designed, initial variable initialization, white-space use, code flow, etc are the problem. Languages that try to force coders to not be retarded are not the answer. It's very easy to spot coders you should never hire if they use a language that lets them reveal their ignorance and lack of organization skills.
It's far easier to modernize code while maintaining the same core language than it is to completely start from scratch with a new language.
While PHP's OO functionality is pretty lousy up until 5.3 when it finally got late static binding, it is perfectly sufficient and no excuse for crappy spaghetti code.
Re: (Score:3)
Millions of lines of fine, historic code were written in COBOL, but I don't exactly here anyone declaring it a wondrous language.
Re:Lousy Developers (Score:4, Insightful)
Fortran's pretty similar- nobody here is going to hold it up as a language marvel, but it was- it fit the niche of "powerful number processor" very well. Perl is noted for being a complete mess, but if you need a quick script to massage some text nothing is better. BASIC fit into its niche as well, and frankly so does PHP
None of them were "elegant" in the sense of LISP, Smalltalk or Haskell. How are those doing by the way?
Source of PHP programmers (Score:5, Insightful)
But the second half is that PHP should be bad at times. Often a simple unstructured script is the best. It needs to do a simple thing quickly and well. There is no need for templating, language abstraction, unit testing, separation of data, logic, and view. So if you are a bank deploying a mission critical system then it should be rigorous and perfect. But if your blog about car tires needs a widget that reads from your odometer then hack away.
I would say that all arguments that condemn PHP should whither under the light that Facebook was developed primarily in PHP with MySQL. Even now they have their Hip Hop that converts PHP to C++. Arguing against PHP is like saying that Carbon Fiber is a better material than steel for car frames. Absolutely true but most cars are still successfully made from steel for a wide variety of reasons. Next time I need to win an F1 challenge and it had better be Carbon Fiber. But for the next ride to the grocery store and I just don't care.
So to circle around one could argue that the best cars are made from this or that but the reality is that what made the truly terrible cars terrible was that the designer would have made a terrible car out of anything. So teach a "better" language to the people making messes with PHP and you will just have a different kind of mess.
Missing the forest for the trees (Score:5, Insightful)
I've programmed in every major language and several minor ones from the 1970's to the present day, never mind design methodologies. They all have their relative strengths and weaknesses, but at the end of the day, the only thing that really recommends one over the other is a) what's available, and b) what you're most familiar with. No widely used language is "broken" any more than any natural spoken language is broken. No one ever says, hey, this novel would be much easier to write if we were taking advantage of the greater expressive power of Indonesian instead of kludgy old Lithuanian.
Aside from juvenile cliquishness and fashion obsession, every language flamefest starts with people obsessing on some awkward feature of the dominant language du jour, and then concluding that all of their problems would be solved if we all switched to some other language without that awkward feature. Of course, tomorrow's language (or methodology, editor, coding standard, platform) has its own awkward qualities that will only become apparent once it collides with the real world on a large scale, setting the stage for the day after tomorrow's language. Rarely does anyone pull their head out of their compiler/interpreter long enough to recognize that it's the real world that's awkward, and no amount of switching between fundamentally equivalent machine-parseable languages is going to change that.
Instead, we keep implementing the same stuff over and over in one language after another until the pace of real progress slows so much that we can actually get excited that the document viewer we're trying to port everything over to is receiving a "major" new features in HTML5 that will allow it to get a little closer to matching the desktop GUI functionality of twenty years ago, only not as well and with the added requirement of several orders of magnitude more hardware power required to keep it going.
But by all means, let's get rid of PHP if that makes it easier to imagine that we're doing something besides reinventing the same old wheel and doing it badly.
Re:Missing the forest for the trees (Score:4, Interesting)
so PHP is like English with its mess of irregular verbs and pronouns. I guess the 'best' language is Smalltalk... the Latin of the computing world.
Re: (Score:3)
The problem with PHP is that it's not "one awkward feature", it's literally half the language. All other mainstream languages have their awkward sides, but they either have significantly less (like, say, Python), or they have something to compensate for it (like, say, C++).
In "PHP: A Fractal of Bad Design", the author compares using PHP with using a rock to drive nails in, and that comparison is very accurate. We can argue about the precise shape of the hammer, and how minor changes in the grip may have pro
Languages don't make bad code, programmers do (Score:5, Insightful)
The assumption in TFA seems to be that PHP does something that couldn't be done otherwise now, or does it more easily, or something. But I don't think that's true. There are alternative languages and alternative ecosystems now. IMO, most PHP coders don't use PHP because they have looked at the alternatives and decided PHP is the best choice, or the least bad choice, or any other choice. People use PHP because either
1: It was forced upon them for some reason or
2: It was the first thing they found and it was good enough
If that's the case, it's irrelevant how fantastic the alternatives are.
Also, while PHP code can be truly terrible, people who are determined to write terrible code will do so whatever the tool. You can use almost anything as a hammer if you try hard enough. The myth that The One Right Language somehow makes bad programmers good is still alive, especially within the Python community, but it's stll a myth.
When good programmers have no choice but to use PHP, they'll find a way to build something that is workmanlike even if it isn't beautiful. When bad programmers program, the result is going to be bad regardless of the language.
The problem... (Score:3)
When it came out, it was really handy for throwing in some server-side functionality into your HTML. Unlike Perl, where you'd have to have print statements all over the place, or load templates and replace keywords, PHP let you just in-line your functions with your HTML. (Sure, there were earlier solutions like this, like ASP but... ew!). So, it's a great first web-development language... like BASIC was for PC programming. Like BASIC, the problem came when you never realized that it was time to "leave the nest" and move on to something more rugged, J2EE, AJAX,
So, to address the original post, there's kinda no hope in trying to fix what's messed up with it, because there's *way* too big of an installed base... and most of what's messed up about it is that people are using it for larger projects than they should be.
The next step is Groovy? (Score:3)
As much as I like python, Groovy seems like the logical next step.
It's dynamically typed, it has a similar syntax, it can be procedural and oop, it has access to 99% of the java ecosystem. The learning curve from PHP to Groovy is much smaller than python I'd imagine.
Just replace Zend Framework/Symphony with Swing, Apache HTTPD with Apache Tomcat, remove $ from variable names, and while "this" may not be required, it certainly makes code easier to read and is more in line with php, and replace -> with a period.
Voila... the post-php world has arrived. With a language that has more similarities syntax-wise with Javascript, the flexibility of PHP with the option to be as strict as Java, and access to a wealth of superb libraries.
"1" == "true" (Score:3)
Or at least it does in PHP 5.2, but in 5.3, not so much. There have been many of these little idiosyncrasies over the years, enough that my company moved our core product to Java long ago. Stupid stuff like that makes it impossible to upgrade the PHP version without major QA and developer time to address all the new "fixes" the PHP folks decided to introduce in the latest minor release. Meanwhile, my C and Java code from 2001 still runs just fine. That said, when I am coding something for fun, not for profit, I usually end up with PHP on the server side. PHP is coded by amateurs for amateurs. Keep it far and away from any critical systems and it can actually be kinda fun.
PHP - python (Score:3)
Re:Fix? I think you mean, "migrate" (Score:4, Interesting)
It is not as though there is no other choice. The only two things that need to be done are (a) stop writing new PHP code and (b) start migrating old PHP code to better languages. We can do web development in Python, Haskell, various Lisps, Scala, and several others.
None of these languages use standard C-style syntax. That syntax is one of several reasons why PHP is so ubiquitous: any reasonably competent C/C++/Java programmer can adapt to it quickly.
Re:Fix? I think you mean, "migrate" (Score:5, Insightful)
Re:Fix? I think you mean, "migrate" (Score:4, Insightful)
Re:Fix? I think you mean, "migrate" (Score:5, Insightful)
This.
PHP feels natural for me, as a C guy. The library functions lack consistency, but then neither do 3rd party C libraries. You just learn how to work them and get on with your billable day. I can look at just about any PHP code and figure it out pretty quickly. A lot of it is written by mental midgets, but it is familiar enough that I can jump in and fix whatever needs to be done.
Meanwhile, all those other, functional languages venture so far off the beaten path as to make them look like gibberish. They often strike me as the product of overexcited college grads. It's like a little kid who just learned a new swear word and starts using it ten times in every sentence. Closures this, aspects that, ooh look ma I'm using list operators... academic functionality makes for cute sample code, but those of us with actual jobs have more pressing things to do than learn a new language and syntax. At the very least, PHP offers a good online manual with some very handy user-contributed snippets. Sure, some of them are ass and could benefit from some karma/moderation system, but I've often found a little 10-line function in those comments that saved me an hour of poking around, or that I could patch up and post my improved version. That right there beats all those "Look how easy RoR is" screencasts that ignore all the actual things programmers need to know to write secure, production-ready code.
Re:Good things about PHP (Score:4, Insightful)
Re: (Score:3)
mod_php the Apache module.
Re: (Score:3)
Other examples include "heavy" functions (such as regular expressions, file operations, etc), or even framework initialization - try accessin
Re: (Score:3)
If you don't understand why Classic ASP (or rather VBScript) is awful, you're simply not qualified to judge PHP. Nonetheless, please read the article linked from my sig; it explains in details why PHP - the language itself, and its standard library - is awful on its own merits, regardless of who writes code in it and how they do that.
Re:I am a PHP user (Score:4, Interesting)
I am one of those "stupid" PHP users. It's not the first language I learned, nor is it the last. I'm well aware of Python as an alternative for developing web apps, and I've tried it, but I really do prefer PHP.
One reason is flexibility in flow control. PHP has do ... while loops. Also, I can do "continue 2" or "break 2" if there is a loop within a loop, to continue or break at the outer loop. I'm honestly puzzled that Python still hasn't added these obvious and useful things.
I've asked Python types about this, and gotten reasons like "you shouldn't be doing that in the first place," which pisses me off and makes me want to stick with PHP even more.
I'm going to tell you what you don't want to hear, and I'm going to tell you because it's true: you shouldn't be doing that. The reasons why you shouldn't be doing that have nothing to do with any one programming language, they are general to all programming languages. They are the same as the reasons why you shouldn't have GOTO statements, and these things were learned near the very beginnings of the study of programming as a discipline.
There are far too many people who equate the invention of new programming language with "progress". It ain't so. That being said, it's probably possible for a good programmer to write good code in any language. (I say "probably" because I don't know all the languages, including PHP.) However, not all programmers are equally good, so it might be wise to stick to languages that won't let you commit atrocities.
Re: (Score:3)
I've been programming in PHP for 11 years - after coming from a C/C++ for 6. What I've found is that there are three types of people who despise PHP.
1. Those who love Perl (Python, Ruby)
PHP is too verbose and doesn't allows the same shortcuts that Perl, Python, and Ruby allow. This is viewed as a weakness of the language. Ruby is essentially a rebirth of Perl, and was a god-send for those Perl developer who found themselves "stuck" with PHP. I personally don't like implicit references or compactin
Re: (Score:3)