php.ini file that contains options to change the behaviour of the environment

Compatibility between versions is very bad, minor version changes (0.01) can introduce big changes in php

It's intentionally crippled to sell commercial caching accelerators

cluttered namespace

Magic quotes (and related mis-features) make data input needlessly complex and error-prone. Instead of fixing vulnerabilities (such as malformed SQL query exploits), PHP tries to mangle your data to avoid triggering known flaws. And what about things like mysql_real_escape. PHP makes it difficult to write safe code, instead of the other way around

Magic quotes (and related mis-features) make data input needlessly complex and error-prone. Instead of fixing vulnerabilities (such as malformed SQL query exploits), PHP tries to mangle your data to avoid triggering known flaws. And what about things like mysqlrealescape. PHP makes it difficult to write safe code, instead of the other way around

"Recursion" isn't a domain specific feature. It's an important general purpose construct. Trying to dismiss it as being special case is like saying "Oh well if you wanted good if statements, you should use some other language."

"Recursion" isn't a domain specific feature. It's an important general purpose construct.

It works in PHP. For common algorithms where it's natural, like trees or searches, it works fine. If your task benefits from an algorithm where you get a different complexity class from TCO, PHP is not for that task.

If your preferred style requires you always having the option to use recursion with impunity, to print arrays and stuff, PHP is also not the language for your task.

And yes if you do want good if statements in a demanding branching algorithm, PHP is also not the language for your task, and you might consider other languages where you'd get a factor of 100 out of your ifs.

Magic quotes (and related mis-features) make data input needlessly complex and error-prone. Instead of fixing vulnerabilities (such as malformed SQL query exploits), PHP tries to mangle your data to avoid triggering known flaws. And what about things like mysqlrealescape. PHP makes it difficult to write safe code, instead of the other way around

No they aren't. They are turned off by default now, that's quite different. Any security conscious php application has to check if they are turned on and then undo the damage. You don't always get to decide the environment your app is going to run in.

magic_quotes (and just as importantly addslashes) still exist and will until PHP6. magic_quotes now default to disabled (but can still be enabled), but only since 5.3.0, and if you just upgrade your PHP installation I doubt it's going to reach in your php.ini to set magic_quotes to disabled.

I also write PHP daily. My conclusion is that it's a fine language for getting things done. There is nothing beautiful about it. If given a choice I'd pick Python every time.

People always say that PHP is so successful purely because it's easy to get started with. I think it's also successful because it scales from small inline HTML pages to large applications similarly easily. Many programmers don't leave PHP because they never run into a problem that it can't handle. It's not like BASIC where you run into that wall quite early on.

I kind of like PHP's type coercion, and it hasn't burned me badly yet. I've never for the life of me understood why people ever even use the switch construct in any language. Either if/else or some kind of associative array seems always better.

My biggest pet peeve is probably the fact that functions are not case-sensitive. (Whereas variables are.)

PHP is an utter failure as a general purpose language (for example lacking threading), but I must grudgingly admit, after having used it a lot, that it is just fine for web programming. Like you say, it's possible to write good code in it, and it doesn't get in the way of getting things done.

However, it is possible to write absolutely horrible code in PHP, and its loose structure tends to attract people who program like this. (Much as BASIC used to do.) The code quality in libraries out there is variable, to say the least.

I've never for the life of me understood why people ever even use the switch construct in any language. Either if/else or some kind of associative array seems always better.

If all you have is a hammer, everything starts looking like a nail. :-)

I once came across code written by someone else who didn't even try to make use of "else if" or "else". It was just "if this; if that".

For business logic of database driven web applications, using "if" instead of "switch" can be enough indeed. But PHP needs extension libraries every now and then, and if it was more powerful it would make code clearer when developers tried to get their reusable code ready for end-users.

I'm trying to learn here... really doesn't switch just always suck? It makes sense in C which is at a lower level, but it's confusing and error prone fall-throughs just don't seem to add any value to me. Either it's being used exactly as a series of if/elses, or else it probably indicates a situation just begging for some more dynamic kind of structure, e.g. some kind of key/value mapping.

One of them is that a "switch" statement provides the language with some opportunity to optimize the code without having to resorting to a greater analysis of the code to just then be able to optimize it.

Also, if your code can make use of a switch statement, to the reader of the code it becomes a little easier to scan the code for what it is supposed to do. With a series of "if" it can take more repetition to scan through and then one might not be entirely sure about the open-ended possibilities of the "if".

Also, "if" statements can be nested or have more complex logic which also makes it a tad harder to read in one go and be surer of where the code-paths go. By breaking down the "if" statements with possible "switch" statements interleaved, structures emerge so one can "move on", jumping through them when reading the code.

Furthermore, in some languages the switch statement is "dumbed down" by not having fall-throughs, but languages like Ruby compensate for that by allowing for values to be agglutinated into one "case" statement of the switch. Also, Ruby allows for regular expressions in the "switch" which is both unusual and powerful. Another language that seems to have a proud "switch" statement is Scala but then I am yet to learn it. ;-)

I find the flow of the first much more clear, and less prone to bugs. I've seen many bugs (in other people's code, of course:) ), where they forgot the break in hastily changed code, or didn't understand how the fall-through worked exactly.

Yes, you can do insidious stuff in side ifs, but you can also do insidious stuff inside of switch. (Such as "clever" use of the fall-through, which someone else tries to "fix" later.)

And then some Lispers even say that as you get used to Lisp code, the parentheses start disappearing as they get so used to them as to reach the point of seeing the code around the parentheses without paying too much attention to the parentheses. :-)

For understanding flow, your switch example is better then your if statement. I had to read through all those if statements to even know that you were constantly looking at the same variable.

Your third example is crazy. Taking the performance hit of building and scanning a hash and then doing an exec just to get out of the more common/familiar switch statement is just silly. You just made your code harder to understand and slower performing.

Everyone's familiar with switch. Not everyone is familiar with redditnoobs-super-duper-i-hate-switch-statements pattern.

and then doing an exec just to get out of the more common/familiar switch statement is just silly. You just made your code harder to understand and slower performing.

It also means I can change it easily, or move the decision map to be handled by some configuration mechanism or database table, or make it configurable to the user. Or use the same codebase for more than one different installation unchanged while only changing the dynamic configuration part.

For 4 cases, this might be a little silly. For 10, it becomes less silly, especially if they are going to change during the life cycle of the app.

You realize that O(1) is constant time, right? As in you can look up anything in exactly the same amount of time regardless of the hash size? That's a pretty fucking amazing hash you got there.

Have you ever written a switch statement, in a dynamic language, where, had you implemented it as a hashtable, branching was likely to cause hashing collisions that adversely affected performance in any noticeable way?

You can change any of these easy. Adding a case statement is trivial.

You have to find the source, for one. It might be easy for you but people do screw up the breaks, trust me. If you're fortunate enough to be working on your own code base or with people as smart as you only (and much smarter than me) this might not apply.

I prefer to have items that will be changed in a location where it's clear that it is configurable data.

First of all, that's premature...deoptimization. Why would you incur esoteric code and a performance hit for something that you might do later. This is really bad.

I'm a big believer that people don't worry about performance when even slight care could make their programs a lot more usable, but... worrying about switch statements speeding up your web app? That's one hell of a PHP program you've got there where that's your bottleneck, or even detectable at all without some meticulously careful profiling.

If the problem calls for a hash map, use a hash map. If it's a problem with a finite number of hard-coded values, for fucks-sake, use a switch.

To me, large switch blocks are a stink of something that will change, and very likely a user will want to do it at runtime, or have different installations of the same code configured slightly differently. So it's not premature deoptimization, it's useful deoptimization, and not more difficult, and not detectably slower to run, and easier to maintain (for me anyway), and trivial to extend to be configurable at runtime.

Can you describe an instance where you've used a really large switch block where this kind of configuration wouldn't have been useful?

I think any structure representing a "finite number of hard-coded values" is just bad design, in almost cases.

Suppose you know execution reaches this code, but not doit(). Why not? Is it because x != 4? With switch: yes. With if ladder: maybe one of the earlier conditions covers that case, you have to go read them all. (Bonus: the condition that covers it might not even be looking at x.)

Similarly, compare what you have to do with your example above to find the code for option 3. For the if ladder, you have to evaluate each expression in sequence. Maybe they're all ==, maybe not. For switch, just look for case 3. With the style you used, it's even a straight vertical line. It's even easier if the cases are sorted.

Can you rearrange the if branches? Again, you have to check every condition between where the condition starts out and where you want it to go. (and if you're swapping with the first one, there's that else to deal with) For switch, you just have to make sure the previous case doesn't fall through, which it almost never does.

(And as far as compilers go, for some languages they can warn you if you forget a possible case and have no default.)

I've seen many bugs [...], where they forgot the break in hastily changed code, or didn't understand how the fall-through worked exactly.

Fall-through is almost always a mistake, especially if there's no comment indicating it's intentional. (Although how can you not understand how it works "exactly"? It falls through. That's why it's called "fall-through." What else could it do?)

Forgetting a break? This is why you test your changes. What if you forget a + 1? Some languages (I forget if PHP is one) will even quietly allow you to forget your return. Haste makes bugs.

That said, we'd be better off if C had insisted that fall-through be explicit.

I still stand by that if there are enough cases for your points to be valid, writing out a huge ladder of code just sucks period. It should be something more dynamic and configurable instead.

"Just test" is a non-point that applies to everything. A problem with case is that when you don't see a break, you don't know if it was intentional or a careless bug. (A polite programmer would comment, but you never really know.)

Another thing I don't like is that in a large switch block spanning multiple pages, it's easy to forget exactly what the condition was, especially if it's not just a simple variable. And what about the variable changing during the case? It would be awful programming practice, but it's not clear to me how this would affect the flow.

It just strikes me that a control structure that requires explict breaks is just a too low-level for a web language. It seems akin to someone deciding to replace all for loops with while and break instead.

Well okay, to you, switch looks beautiful, whereas to me, it looks like a hashtable of gotos and labels, with the same major wart, that being requiring the programmer and maintainer to be very much aware of the low levels roots of the construct, lest they misunderstand exactly how the code is falling through those goto labels.

It's just exactly like the way I'd program in BASIC on my Commodore when I was a kid.

Yep, that's fine. And based on the fact that you've already got a couple other replies saying, "no, the switch statement does look better," and given its widespread prevalence in the field, we agree that you disagree with the vast majority of other programmers as well. =)

But I think you've just inadvertently answered your own original question. Why do most programmers dislike PHP? Because for whatever reason, it seems to attract the kind of programmers that like to make things needlessly convoluted, for instance using too many elseif's when a simple switch would suffice.

Like you say, it's possible to write good code in it, and it doesn't get in the way of getting things done.

It is possible to write good code in PHP, but it take a lot more work than is reasonable, IMO. I prefer environments that make writing good code the path of least resistence. I find myself fighting against PHP every step of the way. If i never have to write a line of PHP code again, I'll be a happy man. Ruby made programming fun again.

I've never for the life of me understood why people ever even use the switch construct in any language.

I've found one good usage so far. Our wizard has a progress-bar of sorts, with the name of stage visible. They change colour as you progress, which we do by applying classes. For every stage, every stage prior to that stage must also have the classes selected.

Eh, maybe not. It looks to me like the sort of situation where there's a concept in the code that really wants to be represented by a class. On the other hand, I haven't seen this in context, so you're absolutely in a better position to know what works here.

For what it's worth, you're totally right about the fall through being nice there.

I hope there's some clear comments explaining what exactly that switch is trying to do, because to someone unfamiliar with the code, it looks indistinguishable from a "I forgot the break statements" bug. The previous "sloppy" code is clear in its intentions for the price of 3 more lines of writing.

a) That was a gross simplfication of the actual problem - because I'm not at work and was giving an example off the top of my head, the actual code has about 9 different stages.

b) So the actual "more lines of writing metric" would be somewhat greater.

c) The actual code has a comment at the top of the switch that reads "all fall-throughs are deliberate". I had originally added the comment to every single case clause, but a coworker considered it excessive.

Now let me give you a hypothetical situation - what happens when a stage needs to be added between the fifth and sixth stage, for example?

In the switch, I add a new case clause. In the nine level if/else tree? I add a new line to each of them. Yay for copy and paste coding.

Built-in functions such as print(), echo(), array(), are reserved words and cannot be used as the name of class or instance methods.

And adding insult to injury, built-in functions are in the thousands, making collisions much easier. Namespaces anyone? Oh yes, they finally added them in such a brainfucked way that it would be comical if not so bad for those who will have to actually use that. Oh my.

Which brings up one of my least favorite PHP features: functions with names like "pcntl_fork" and "pcntl_waitpid", the "mysql_*" family, the string functions "substr", "strstr", "str_replace", "strtolower", "str_split", and who could forget "strpos" which can return 0 on success.

That's not unique to PHP by any stretch. I could rattle off a long list of languages with functions that allow you to search for substrings that can return 0 on success.

EDIT: In fact, I much prefer that behavior to anything else. If I'm looking for the position of a substring in a string, and it starts in the 0 slot, I absolutely do not want the function to return 1 and then have to decrement the return value to accommodate. Returning -1 or false makes the most sense.

In an untyped language like PHP, strpos should return -1 for false. Otherwise you have to check the return type (false versus 0), which is a behavior you would expect in a typed language, but PHP isn't a typed language, except when it is.

It is sometimes a typed language, like when a lazy programmer decides to return false for a function that could potentially return 0 on success. This is most telling when you look at the way the language is used, as a sort of domain oriented scripting language (where HTML or rather HTTP is the domain).

Most friendly scripting languages follow the familiar conventions of the programming shell. They don't have to, but it sure is nice when they do. Those conventions say that unless there is a big red flag warning, functions should return a non-zero value on success and false on failure. And again shells are not usually typed, meaning there is no distinction between 0 and "false".

But you are going to nitpick at that example, so I'll stop there. Let's talk about the one thing that PHP is supposed to do well which I alluded to earlier which it utterly fails at: providing scripting support for HTML and HTTP. Out of the box, PHP provides perhaps the most daft collection of "web" features I can think of. What the fuck is this "header" function that depending on current output state might be silent, or might throw the fattest ERROR message possible? If PHP is supposed to be a protocol neutral technology, why does it default to sending HTTP headers in the first place? And if it knows so much about HTTP, why doesn't it require an explicit end-of-header state change that would generate errors if you output non-headers in the header?

The one thing that PHP does do well is allow users to mix code inside the HTML, a templating language if you will. This works so well people have invented crap like Smarty which provides templating for your PHP code.

Oh, and then there is PEAR. Hey, I'd like to install 5,000 buggy libraries on my website.

Like mehochh said, PHP is a typed language. Using this example in particular to try and point out a design flaw is poor because there is none. Saying it "should" return -1 is merely a matter of personal preference. There is no drawback from having to use !== false as your comparison instead of >= 0; still the same amount of code. You're arguing for what Tecktonik wants, not for what actually matters in language design.

There's very little to parallelize in places where PHP is appropriate.

You should read input, dress it up in HTML and spit it out. You can't sensibly parallelize those. While waiting for data from DB and network, there's not much you can do when the next task is to format the data.

Perhaps when you have multiple sources of input, some additional heavy processing to do then you could squeeze a little, but it wouldn't change much overall, because under load multiple simultaneous requests will give you parallelism anyway.

Yes, but most programming languages don't make their built-in functions reserved words. They make keywords reserved and even then often provide a way to use the reserved word anyway. Many of them are even smart enough to allow the use of keywords for function names, etc. depending on context.

Php is kind of a mashup of a language. I don't know a lot about the history of it (even though I use it ever day), but it looks like it initially had two or three design philosophies which all won. So if you're trying to remember the name of a function, a lot of times you can't recall if it has underscores between words or if they all run together. Sometimes the arguments jump around too - needle, haystack in one place, but haystack, needle in another - for example. So you kind of suspect that it's the same way internally.

Before programming web apps in php, I was doing stuff with C and Java. When I started php I was like "Oh damn, you mean there's a function for that already?" I assumed php was written by people who were doing web development, because it had a lot of the functions I needed right out of the box.

I don't even know what the structural complaints are, and I don't really care that much, probably because I had one class in Fortran and taught myself the rest.

The standard library is a pile of unorganized, dissimilarly named, useful modules.

No namespaces. Wait! We'll add namespaces if you give us your backslashes.

Lack of types. It's been a while but I seem to remember php thinking perl had one too many types.

These kinds of things keep programmers from really loving PHP. It's really an odd patchwork of a language. All it really has going for it is inline HTML. If you took that all away it would be a joke of a language. But it DOES have inline HTML. So non-programmers and those that live in HTML find it a useful tool.

I've done quite a bit of PHP programming in the past all of which was for financial gain. The number one reason PHP sucks is that it lacks abstraction.

While Perl has one sort function, PHP has 16. Perl has one function for splitting strings. PHP has 8. It also lacks lexical scoping, namespaces, and is generally inconsistent when it comes to establishing patterns in the core ($needle, $haystack OR $haystack, $needle)?

Overall, it has one of the lowest barriers of entry of any language (maybe the lowest?). This leads to a lot of craptastic code being written that experienced programmers often get stuck maintaining for various reasons. This adds to the hatred. I can even think of a few high profile OSS projects written in PHP that I wouldn't touch with a ten foot pole, so it's not all just "newbs" churning this stuff out.

Most of all though, it just annoys me that it's so widespread when there are so many better alternatives out there. I feel the same way about MySQL though as Postgres is a superior product, so I guess that's life.

Other folks have been more articulate and principled in their answers than I can be, so I'll just say: it's not a designed language; it's a thrown-together mess, with no seeming rationale for any detail, beyond "it's what we thought of at the moment." It's the same reason I loathe Groovy.

Easy to setup. It's in virtually all distributions. It works well on windows, it works amazingly well on *nix. It has simplistic connectivity to virtually all databases written. It has some fairly useful data types like associative arrays. It allows you to bring your C knowledge with you to make quick and dirty applications. But as it matures, it's gained a fairly decent object model. I do however miss my structs :p I haven't put html inline with php in ages. These days i follow an MVC model exclusively. And even the .NET people have an MVC framework these days to improve productiveness for web applications. PHP makes doing thinks like dynamic PDF generation simple using libraries like TCPDF. Why be a hater when you can use something to make utilities which are just so useful. I have nothing against python or ruby. I have nothing against even perl. I just found php much easier to pick up after I learned C++ in school. These days i pick up a little python / ruby here and there. Just be happy it's not javascript. Debugging php in my opinion is pretty simple as well. I have things like print_r() and var_dump() which make debugging pretty simple without an IDE or even having to use a separate debugging application.

Ruby has Prawn for generating PDF and before that it had PDF-Writer which itself was based off of a PHP library. Prawn does not have all the features of PDF-Writer yet but the Prawn API are pretty consistent and even provide a DSL-like interface should one want to cut the code needed a little more. ;-) I converted some code of mine from PDF-Writer to Prawn and while I was not able to get all the features I needed in the process, I did manage to remove lots of lines in the process just because Prawn made it more convenient out-of-the-box.

Regarding MVC, it's like security in some ways, as in you can't have security and MVC as a product, it's more like an open-ended process. One should always be on the lookout trying to keep the dependencies lower between the layers as it's too easy to bulk up the work on just the most convenient layer for your code.

And JavaScript code can be loved, believe it or not. What can't be loved is all the incompatibilities between the browsers. :-)

PHP been hacked together in a half-assed way by a community of probably smart but unorganized or inexperienced people who have collectively catered to the absolute laziest crop of developers who think that using a shitty language every day for many years is a good tradeoff for the few days they'd have to spend learning to set up something better than the Fisher-Price crap that's already on their web host. PHP has no known advantage other than being the path of least resistance, which is a strategic advantage but of course not an actual advantage.

I could get into specifics, but the best way to tell it is that from experience with many languages comes the conclusion that PHP is horrible from an intuitive sense that is more than the sum of the individual flaws with it. Not that some of those flaws aren't big, but it's important to note that these flaws add up to a culture of poor quality that feeds back on itself.

Your time with PHP is one compromise after another, and for some reason I've never understood there are apparently many people who learned PHP as their one language, cling to it, and defend all of its flaws instead of seeking out better languages, a category into which most of them fall.

You can replace the word PHP with MySQL and this post is still accurate. Half of the old "LAMP" is dead and Python and PostgreSQL are the future.

PHP has no known advantage other than being the path of least resistance, which is a strategic advantage but of course not an actual advantage.

The real question though is whether there is any real disadvantage in terms of productivity (in the narrow space of web development). Loss of sanity for purists is one, but that is the opposite of the lanugage's target and actual user base.

Which is why it's still around. The negative impact of these issues is essentially zero in most cases, which doesn't lead to it being abandoned. It's evolutionarily a success because it does what it needs.

Sort of like people who can't roll their tongue. They still succeed to reproduce, even though they're handicapped in that way. That particular handicap doesn't matter to the ability to reproduce so we get more people who can't roll their tongue. We get more bad PHP programmers and more bad PHP programming language, because it's good enough.

As programmers we deal with abstractions. With the these abstractions we build up a mental model of how stuff fits together and how they should work. Whenever a language or technology breaks the model(e.g. inconsistencies), we as programmers hate it. Because that means that we have to revise the model we have.

remembering and working within an abstract model is difficult to do. If this model is inconsistent you can't make any assumptions which is massively annoying because you have to keep checking to make sure you're doing it right.
An IDE certainly makes this easier, but an IDE is more of a patch for a more fundamental problem.

Definitely agree, IDE:s is the most visible symptom of the problem of inconsistencies in the current abstractions. But it can be other things also than inconsistency. Too many options that aren't default is another one. That can have devs hating the API. But that can be consistently bad.

When people make use of tools for pragmatic reasons or commercial reasons, the tools do not need to be pretty or make use of very good conventions, they rather need to be at the right place at the right time.

I do not know how PHP came to be on Windows, but most folks who learned programming on the Windows platform ended up first making use of ASP when it was about web programming. All the while, PHP had a slightly poorer success story on the Windows platform. PHP used to depend on Apache for example, and Apache itself prior to the version 2.x did not have a great success story on Windows either.

I know I want to say something more concrete but it's difficult. I am going to try after such introduction.

PHP's niche has been rather proudly the web application programming but before that it was mostly about allowing the creation of all kinds of files that would dynamically generate some content, with little rigor when applying reusable development techniques. While one could load files that were meant as reusable library files, it was such a basic thing when compared to what folks were getting from when their developments consisted of non-web things. Take Delphi for example. The Delphi people had more than the chance to create reusable library files, they had classes, components, a powerful language that depended mostly on just itself for creating extensions, and so on. While PHP depended on C, Apache... And Apache was at a transition period from Apache 1.x to 2.x. And Apache itself could be a little hard to configure well for the non-initiated.

On top of that, ASP was rather insecure. I once had a ASP shared host account "defaced" by a group of "hackers". PHP I would guess was itself kind of insecure for a little while. I remember seeing lists of sites being defaced and it had both Windows and Linux systems on them. To this day, I still don't fully trust PHP when trying to reuse PHP applications created by third parties. PHP code is kind of obfuscated.

On top of that, I like many others started learning Java, which was rather consistent (even when it sucked, it sucked consistently.) ;-)

If PHP had tried to be a general purpose language instead of a niche web application tool, perhaps it could have managed some greater success. But to this day, folks have been trying to milk PHP's niche success with commercial offerings like the Zend framework and obfuscators (like it was needed) and compilers to optimize PHP code...

The truth lies somewhere in there.

Besides, Microsoft's ASP.NET put some good pressure on other web application development tools, however sucky it was in some regards.

It's about as elegant as a flying sock; it flops all over the place and never seems to get very far. One minute it wants to be a cool, hip, dynamic language, the next they're adding things like interfaces and trying to write code which looks like Java. It's inconsistent at pretty much any level, and I never get the impression that the language is really helping me get things done; I'm there to appease its needs, somehow not the other way around.

Basically: it gets in my way, it's not much fun, it isn't very clean. Everything from the ridiculous mish-mash of an API, to the language syntax and the hidden limitations therein.

Ruby, Python, even Perl are more consistent, more orthogonal, more intelligently designed, and ultimately far more fun than PHP. PHP's primary advantage is simplicity of deployment for use on the web (and no, all the world isn't a website), and even that can be quite the ballache; right now I'm trying to work out why it randomly crashes under load and why the opcode caches only want to run on certain machines.

While I'm thinking about it, is it possible in PHP to have a background thread that uses semaphores or producer/consumer types models? I suppose you could use mysql and a command line cron for some of this, but there are times when life is easier doing something like this:

I don't dislike PHP. It's a quick, easy way to hack stuff together fast. I can appreciate that.

Would I write a complex system in it? No. Would I write anything mission critical in it? Hell no. But if I needed to whack together some web pages quickly, would I use it for that? You bet. Would use and have used, and am quite happy with the results.

Is it elegant and consistent? No, far from it. PHP has many flaws. But if those flaws are glaring to you, then you're probably using it the wrong way. A good craftsman knows what tool to use for what job. PHP is a circular saw - great for quick and dirty stuff that doesn't need to be precise or extendable. It's not a CNC mill - for making close-tolerance parts that fit into a larger assembly.

It has a general flavor of being half-assed. Less orthogonality than Perl (that's hard to achieve), less functionality, no clue what a data structure should be, arbitrary inconsistencies, and bugs. Also, poor release management. I use it when it's already there, but given the choice I'll use Perl or better yet, Python.

Ruby has a few rough edges too, but it seems much more like a real language that someone designed rather than grew.

5) a big global config file that changes the entire syntax and behavior of the language. PHP manages to not only be platform-specific at times, it's installation specific. A given piece of code may run fine on one server but not run on another due to how the config file is set.

6) Inconsistent naming conventions, calling conventions and behavior throughout what passes as the "base library." (The built-in functions and the common extensions.)

7) It's association with bad coding. PHP was basically in the right place at the right time and had a lot of coverage and a lot of books written about it and a lot of host providers offering it. It's not a particularly good or even easy to learn platform for doing web development, but it was better and easier than other common options for about a year or two.

I find PHP irritating with regard to function names (the string functions seem very inconsistant!).

I like the language for knocking together a small site quickly, but I much prefer a compiled language for larger projects. It is easier to pick up errors, and easier (in my experience!) to logically seperate tiers.

It's not one specific thing, it's a combination of many many small to medium flaws that add up.

There are two kinds of PHP programmers out there. Those that have not learned another scripting language and think PHP is just fine and those that do know what a real language should be like to program in and hate or at least strongly dislike PHP.

The preceding paragraph was only a slight exaggeration, there are probably some knowledgeable PHP fans out there but I've never met any.

That said, there are some good business reasons to choose PHP, but stay away from it if you can.

I didn't get into web development until after I was doing "real" programming. I've done a lot of Delphi, C/C++, a lot of C#, Java (not a big fan).

In the web world I've messed with several different technologies including scripting languages like AS3, several different frameworks, and languages. I've been using PHP for about 5 years now and though it has its flaws, PHP is hardly ever a barrier when you're working a project. The problem with a lot of these other languages is that they either weren't made for the web or they aren't really languages but rather frameworks. PHP doesn't force you to do things the right way but if you are a good programmer you won't fall into the traps. Technically speaking C and C++ are awful languages with tons of flaws but they are still the best tools for the job in many cases.

The one part I disagree with is that "PHP is hardly ever a barrier", for me it is a barrier, and frequently.

Now that is either just because of my style or my wish to use higher level features when i'm programming or it could be because you are happy with with your blub language (to use Paul Graham's metaphor), you wouldn't necessarily have been exposed to high level features in delphi, c, c++, c#, java or AS3.

No offense but I'm fairly young, in my early twenties, and I haven't met many people around my age who have been exposed to such a wide variety of technologies as myself. I will admit that I have not done too much with some functional programming languages that seem to be popular on Reddit. However, when it comes to getting things done at a relatively timely manner (not only because of PHP's flexibility but also of its wide availability) while maintaining scalable, affordable (both in terms of software and hardware costs) then you can't argue that PHP is a bad language. There is much more to a language than what most people here will make it out to be.

There are definitely business reasons to choose PHP, it's easy to find developers who get things done in a timely manner, absolutely.

PHP is pretty fast, so it's affordable with hardware too, I agree. But don't confuse that with scalability.

After a while you hit a wall in trying to keep a project maintainable or scalable in a large PHP project. This isn't even asking for features from functional programming languages, just more advanced metaprogramming features would be nice.

Your code gets hard to maintain and ugly sooner than most other languages would (even Perl has been much better for this in my experience ... yes, Perl!). This is compounded by the fact that you will, let's be honest, probably have a higher percentage of junior developers because they're cheap and they all know PHP really well (This isn't PHP's fault, obviously, but it's the reason you notice the maintainability difficulties almost immediately).

You also need to maintain libraries in a second language other than PHP for any offline processing or background tasks. If you ever need a long running php process you'll wonder why the garbage collectors are on strike.

I agree with most of what you said. Though because PHP is so "raw" if you really need to maintain a large project you can choose one of the various frameworks that will help keep everything nice and organized.

And there is nothing wrong with having multiple languages in a project. Remember, each language is usuallly created to be good at a specific task. I would never use PHP or any web geared language for running daemons since they aren't usually created to run for a very long time. Good programmers will learn what is necessary for the job rather than trying to do everything with the one language they are comfortable with.

Those are good points. I wasn't clear but the context for my comments assumed that those large scale projects would definitely be inside a decent framework.

I would disagree with there being a "decent" php framework out there at the moment. We've done research and tried out a few php frameworks at my day job (cake, symphony, codeigniter, zend) and none of them have held up to comparison with web frameworks in other languages.

From my perspective it was the lack of higher level features in PHP that made some of the nicer framework features difficult or impossible to implement. I know some people argue that it's the PHP community's general skill level that makes these frameworks inferior and that might be a factor but I also think the language itself limits how helpful and dynamic or introspective these frameworks can be. Some of the code I've seen in these frameworks to get around the limitations has obviously been written pretty intelligent people but still mainly falls short.

I should mention that my perspective comes from designing and writing a web framework currently in use for some of our medium traffic sites and internal administration apps, as well as evaluating PHP frameworks before that project started. I would also like to mention that I lobbied to use an existing open source framework but was overruled.

Your multiple languages point is well made and I totally agree. You can't avoid multiple languages, but you can minimize code duplication in a lot of cases if you can reuse your model classes/libraries/objects in your non-web scripts or daemons. There is no reason you would have trouble with long running processes in python or perl or almost any language I can think of that would be an alternative to PHP (maybe Ruby? I have no experience with Ruby in a production setting but I think it would be at least satisfactory).

All these points being said, sometimes PHP is still the right tool for the job, I just consider the class of jobs that PHP is suited for to be pretty small.

The preceding paragraph was only a slight exaggeration, there are probably some knowledgeable PHP fans out there but I've never met any.

I know a pair of them. It pains my heart to see them.

Anyway while I hate PHP with a passion, I've still come to the conclusion that it definitely is not the worst technology to code a website with. Java takes the cake (unless you go in the esoteric stuff e.g. CGI/C or CGI/Fortran). Even with "modern" web frameworks (read: not completely brain-dead, which means not Struts for instance) such as Stripes.

Oh yes, that's definitely true. I work in PHP daily (although we're transitioning to python/django thank god) and while i hate it, i'm aware that there are worse options. Everyone but coldfusion programmers comforts themselves with the fact that it could be worse.

its a hack job made for web hack jobs, and works very well for that. You want to get a site up and running over the weekend? 1000 lines of code, 30 inconsistencies, and 20 different functions with 'str' in them and your website is up and running.

I've spent most of my relatively brief programming experience working in in PHP and JavaScript, mainly because I found them to be easy to get into. PHP is widely available, has a large development community and quite importantly, comes with accessible, easy to find documentation and examples for what I needed to accomplish.

While I've been generally happy with PHP, it's apparent as I learn more that it is far from the best designed language. While PHP is effective and straight forward in some ways, it's a bit slapdash overall.

I've been learning Python and so far, it's clear that the design considerations put into the language are likely to make my Python programs more clean, simple, and easy to maintain than the ones I wrote with PHP. I can already tell that the clean-ness of the language will leave my head feeling much better and increase my productivity.

I like PHP like a toothbrush, but I wouldn't recommend creating anything of more than moderate complexity with it.

I wouldn't recommend creating anything of more than moderate complexity with it

Hah! I've worked on several large php-based web applications.

one ran the entire operation for a telecomm refurbishing company,

another is the basis for a hospitality-oriented customizable CRM system (largest customer has total budget of $227 million),

a third is the basis for city website CMS system (largest customer's budget $2.5 billion).

A fourth large project had been done in Django, but it was difficult to add sophisticated features we needed, so we scrapped it and rewrote the project in php.

Some people here (not you) are talking about sloppy code, but that's a straw man. You can write sloppy code in any language, or you can write beautiful code in any language. I worked a long time in the space sciences, and had a beautiful set of libraries all in Fortran.

A fourth large project had been done in Django, but it was difficult to add sophisticated features we needed, so we scrapped it and rewrote the project in php.

I think thats just a symptom of your familiarity with php. As someone who spent many many years doing strictly PHP work, and the last 2 working with python and mostly django, I have found that pretty much everything is easier with python and django. I'm really interested to know what you consider a 'sophisticated feature' that was easier to implement in php.

Of course there are large projects done in php that doesn't mean that they couldn't have been done (and perhaps cheaper) in another language.

You also compare a framework to a programming language. Did you write a custom framework in php? Are you trying to say that is you wouldn't have been able to write a custom framework in python? Don't you think that your high experience level with php might have been a factor?

Then you talk about how you can write sloppy code in any language and beautiful code in any language (what happened to your problems with python?)

The truth is that php is an ok language that encourages certain bad practices like mixing html and code in the same file. You can do anything with it but that's true of any language.

Dude, I was responding with "that yes, large, complex projects can be done in php" to jethro_snoodle who said "I wouldn't recommend creating anything of more than moderate complexity with it."

As far as Django and Python, I didn't have anything to do with that project. I compared our other systems to Django because we already have our own php framework...s. Yes, actually we have two slightly divergent ones, one for each department. Maybe we could have developed another framework, but our management is bottom-line driven, so everything we do has to already be paid for.

Anyway, people familiar with both systems convinced management that Django was too inflexible, and our customers weren't happy with the product, so to continue making sales we switched to what we know best and redeveloped the product in time for a gala launch party.

And as to the "beautiful code", I'm responding to all the whiners who claim there's something inherent about php that makes programmers produce sloppy code.

Man! Try reading some of the other comments to get some context before getting on your soapbox.

Just because you can do large projects in php doesn't mean that anyone would recommend it. I have a friend who makes a nice living doing huge php projects, but I still wouldn't recommend php if you can avoid it (ie are allowed to avoid it and have staff who are able to use something superior and don't have a huge investment in previously written php code.)

So you basically admit here that your Django example is totally unfair as you're comparing a stock general purpose framework to numerous custom to task frameworks that your staff were already highly familiar with. This doesn't say anything about actual choice between python/Django and php it merely says that you already had a major investment in php and you chose to make use of it. For all you or anyone else knows if your company had started with Django before those frameworks existed it could have saved them a tonne of cash.

As for the beautiful code I'm merely showing that your comment isn't internally consistent. As an aside, while most languages can produce sloppy code, python (my favorite) at least limits how sloppy your code can be (and still work.)

So please reread your comments before accusing someone of not having any context.

Some people here (not you) are talking about sloppy code, but that's a straw man. You can write sloppy code in any language, or you can write beautiful code in any language. I worked a long time in the space sciences, and had a beautiful set of libraries all in Fortran.

I'm so sick of unprincipled cowboy coders who apologize for shitty tools by saying that other tools aren't perfect either. Well, no shit. But the baseline of quality can be moved up, and there are clear and obvious ways to do it. The truth is that you simply don't care very much about quality, and are glad to use your shitty in-house NIH-syndrome "framework" because you're too busy churning out code to stop for a while and try to understand how to fix the fundamental flaws with how you approach your work.

It's certainly not without its flaws, but I like it quite a bit...I work with it every day on a very large project. PHP does a great job of staying out of the way, and allowing me to write code however I want to write it. The code/debug cycle is essentially instant which can provide huge gains to workflow.

One of my main complaints is the inconsistency of the interfaces to the built in functions...but the wonderful documentation allows me to glaze over this issue.

Why is it a good thing to be easy to get people started with web programming? I don't mean to sound elitist or anything, but don't you think there should be SOME barrier to entry to professional software development... some required learning... some previous programming experience.

Real programmers don't dislike PHP, theoretical programmers dislike PHP. People that worry about language design and elegance and consistency dislike PHP. Real programmers don't care about PHP's minor flaws because there is no competition out there, PHP lets you scale from an HTML page to a massive site like facebook and all you need to start is to install mod_php - no other language interfaces so easily with the web.

You're right about this but when compared with other languages PHP has so many shortcomings that make it very ugly.

It does its job, no doubt about it, but if you want to have a clean design and nice code PHP won't be your tool of choice.

Currently I'm rewriting an application originally built in cakePHP with Ruby On Rails. There's just no comparison. Ruby is clean, beautiful, very concise and produces not even half of the code that was necessary for the PHP project.

On top of that there's a lot left to be desired in the PHP language.

But it's very versatile and you can do almost anything with it. I see this as a gift and a curse...

PHP is pretty crappy for practical work as well.
MVC frameworks like CakePHP are a big improvement, but as soon as you try to go meta with php (ie, provididing admin pages with which the users can create their own page layouts), your projects can quickly spin out of control. Nowadays, a lot of client-side code needs to be thrown as well, and doing this with PHP feels a bit absurd.

Of course it may be my incompetence, but of the dozens of large PHP projects I've had, all started exponentially losing structure as the deadline approached.

Ruby is a lot cleaner and way more fun, but unless Rails projects become easier and more widely accepted to deploy, we'll be stuck with php for a while I think.

Just more proof that scalability, efficiency, installability, deployability, and documentation matter quite a bit. This is why so many superior languages and platforms fail. They totally ignore these things. They're difficult to install, don't scale, have poor documentation, run too slowly, etc.

I think part of PHP's success comes from what you say, and part also comes from the fact that it's fast. There's a meme out there that says "performance doesn't matter." It's wrong. Performance doesn't matter until it does, at which point all the sudden it matters a lot.

"Real" programmers dislike PHP, inexperienced programmers like PHP because they don't know better and inexperienced hacks defend it after they should know better.

My day job is on a platform written in PHP that serves a little above one million uniques on an average day. My dislike of PHP isn't because i'm a theoretical programmer, it's because PHP is god damn awful.

It's pretty fast, it's easy to find cheap developers for it and it's easy for someone with a tiny bit of webserver knowledge to set up. Those are it's only strengths.

I would prefer to use something a tiny bit slower (because your db is almost always the bottleneck anyway) and spend a few hours learning how to set up my servers (even if it is harder than installing mod_php).

Because for professionals things like speed and maintainability are also important. And with modern sane language features your libraries and frameworks can be much more useful and teams can produce better code and implement features faster. It also makes it easier to write code that is maintainable, which anyone working on something "real" spends the majority of their time doing.

Note to new programmers: If you're going to start an e-penis competition in a forum for web developers don't take PHP's side unless it's a forum for wordpress "consultants".

Hate to break it to you, but Facebook's core infrastructure isn't written in PHP. It's written mainly in C++, with the presentation layer being written in PHP.

That's still impressive for PHP, but don't kid yourself into thinking that they use PHP to power all of the back end services which build up the data needed to display a Facebook page because PHP is too slow for that. Java is probably too slow as well.

The problem with PHP is that, as you said it looks like shit but so does perl. PHP really is used only for www stuff.

It has NO other domain outside the www. And now anyone says php-gkt - har har, python AND ruby had bindings to gtk, qt, wxwidgets etc... since ancient times already.

PHP is practical, it does the job, and you can do great apps in it.

But the language in itself is horrible. Like perl. But less capable (perl at least is a REAL programming language which isn't limited to the www. Ironically, the weakness of perl - the www stuff - was PHPs foothold. If anyone thinks perl has learned something - look at the perl websites... they look like shit because the guys who maintain them must be 60 years old guys who learned perl when they were young, but stopped learning new stuff)

PHP has a "break first" methodology. This is good in the sense that when you design your system, each entry point from the web has a termination path as your .php files are hit. However from a development perspective, it's much like any scripting language that is inherently error prone; in comparison, there is a level of confidence that you reach by running through a compiler stage and ending up with some object code or an executable. The compilation process serves as a filter or catch point, for many bugs.

Reddit dislike PHP, most programmers do not dislike PHP. Beginners probably found PHP as a good language because it is so easy to get started, you can just get a webhost and assume everything would work. It's a bit more complicated with Python and the others.

PHP is also great in a way because it is itself a templating language too. Makes it easy to learn. And there's no need to pre-compile your source code. I still like that part of PHP.

I don't 'dislike' PHP but it gets my goat at times for reasons amply described by others here.
Ubiquity amongst hosting providers is a major win for those of us who code online apps for small enterprises, perfect it ain't but you can get results and host wherever.

Call me old school (ex mainframe here) but I never took to object oriented (turned off by Java, and now look at that mess of abstraction) and regret that aspect of PHP's evolution. OO enforces a hierarchy of processes and data - big mistake, processes are best done in a modular way (unix approach, do one thing and do it well), while data is best handled as relational (entities echo the unix atomic concept).

A good language would take this atomic approach to process and datum but I'm not aware of any language like that, php is just following the paying herd - maybe that's the ultimate problem and if so then Perl may yet retake pole position given the innovations going on in that free community.

I used to do Java programming, it was pretty cool but when you really get to looking at what's going on, it's like some huge bureaucracy where nobody ever does anything, they just pass their work on down the line.

Where I work now we have our legacy php systems and our newer ones which have more of an MVC style. When I got picked to update one of our products, I got excited because it was so much peppier than our other stuff. But then I found out the legacy system was done without most of the levels of abstraction of our new stuff, and I would have to update it to use one of the new models with more abstraction layers.

C# has more intuitive syntax and a cleaner development model than PHP. Python is of course heavily superior to either but here we are.

I'm not sure what you're talking about with your gripe about processes and data. What is the difference between having a hundred small
processes that do one thing and one thing well and cooperate to perform a task and having one executable that does the same task with a hundred objects that each do one thing and one thing well (assuming the objects were available in a library for proper reuse,)? As for data being relational, well, what on earth does that have to do with Object Oriented programming languages? Are you perhaps suffering from the "modeling real world objects" misconception that has plagued OO?

PHP is a pretty good language, it does what it's supposed to pretty well.

Sure, there are some inconsistencies, such as needle-haystack pattern being inconsistent and lack of naming conventions. But what it does makes up for that.

A lot of traditional programmers get annoyed because it takes fine tuning away from them. This is a good thing, because they get tend to get worried over the little things and produce shit pages. Imagine how much time the'd waste if they had control over threading or union data structures.

It all depends how you do your web programming. I've never used ASP.Net on Apache but Mono will run on it. I'm also not sure where mono development is at right now.

The biggest advantage I see is tool support. Now I'm no Microsoft fan but Visual Studio is pretty good kit and even the free versions make coding web apps very simple.

There is an expected way of going about ASP.Net web apps but you aren't locked into it, so you can use it in any way you desire. Theoretically you could create the infrastructure to compile php to ASP.Net bytecode and use php on top of ASP.Net the same way you otherwise would (of course I can't understand any reason why a sane person would do such a thing.)

ASP.Net is language neutral so it allows for things like Boo (quasi python that gets compiled into .Net bytecodes.)

ASP.Net allows for and encourages the separation of code and html (I see putting anything more than a function call in an html file as madness.) It is also simple and intuitive to use code that may not have been written with a web app in mind. MVC (not real MVC but the modern architecture we call MVC,) is assumed and the system is built around it.

While I think that even html monkeys can deal with <%=someFunction()%> ASP.Net does allow you to wrap everything up in special tags that allow inclusion of dynamic controls without any code at all in an html file.

The ASP.Net standard libraries are far more intuitive and easier to use than java's bloated maze.

ASP.Net has stolen good ideas liberally and avoided speed bumps that earlier systems hit. (Master pages are sweet and simple, though I'm pretty sure they are stolen from OSS.)

While the MS server (ISS? I can never remember the acronym) may not be the best ASP.Net is highly integrated and gives very high performance at least when running the MS versions of everything.

As for drawbacks, well in order to have the latest and greatest you're pretty much stuck with MS software. I personally don't have any windows machines but where I work they've already sold their IT souls to MS so this doesn't apply there.

Other than that if you do some really custom things that java already supports it probably doesn't have the same bulk of existing functionality that java has (which above I explain can be an upside as well.) But realistically it is language neutral, adaptable to your development style, has a solid library, the best tool support I've seen for any type of web development, and is high performance (I've seen benchmarks where it has come first though they were a while ago and you know how benchmarks are.)

Edit: I almost forgot to mention that while I find C# inferior to python it is very fast, incredibly easy to pick up (if you've ever coded in C, C++, java, or javascript before anyway,) and quite modern. C# is what java should have been.

Most people refer to ASP classic as "ASP" and ASP.NET as "ASP.NET". That's all I was saying.

To add my own opinion, when PHP first took off, ASP was in fact the only comparable mainstream language and I will agree with GP that it indeed sucked balls. I think ASP's grossness increased the appeal and popularity of PHP, and also possibly spread the mindshare of free software outperforming commercial packages.

I don't think most programmers dislike PHP... but those that do are more vocal about it.

Most of the arguments against PHP are things that make it bad for the programmer, but not bad for the application. When you propose what language to use for a project, it's unlikely your client will give a shit what the type comparisons are like or if the language has namespaces -- they just care whether it's going to get the job done, and PHP does that quite well.

Wow, there's a bunch of people criticizing PHP on the web, yet the language is still successful? That IS interesting! It's almost as if there's a large number of people who use it, but don't go out of their way to say things like "PHP's alright, I guess" -- which I believe is the attitude of most of the PHP community. You might say they're being "less vocal"...

I think you've agreed with me without realizing it.

The main point I was trying to make: There are lots of valid reasons for a programmer to dislike PHP, but few of those are cause for avoiding the language altogether. You can recognize and criticize its flaws, and at the same time, see it as a good choice for your particular project.

It's a scripting language, people. I use it quite a bit, but I don't call it a "programming language". PHP is great when you just want to get a blog going or manage some dynamic content. True, it has a Java-like OOP layer (albeit limited and somewhat silly), there are some good extensions like cURL and many database connection extensions, BUT. You're not going to build the next hot app with PHP.