PHP is a big ball of crud. The only reason it doesn't appear to stink at first is due to the five layers of band-aid it is wrapped in. Read the description of this bug, and imagine what the internals would have to look like to make this bug possible (not to mention unfixable without a complete rewrite, which is still pending 2.5 years later): http://bugs.php.net/bug.php?id=8130 ''This bug was closed'' Some other signs of a well thought-out design: * is_null($a) makes a copy of the object, then checks the copy for nullness. ** LOL! -- TheerasakPhotha * The reference operator "&" (which you will need to use ''all the time'' to have sane object semantics) isn't an operator, it's special-cased in the parser in about half the places you actually need it. * You can call methods, but only if the object is in a variable... $a->foo() is ok, $a->foo()->bar() isn't, list($a=foo(),$a->bar())[1] would have been ok if array lookups weren't limited in exactly the same way... ''Each one of these issues is no longer relevant with PHP 5.'' * The parser has 1375 conflicts and 6 unused terminals. :) ** That is truly absurd, but such a thing almost never reflects badly on a language in and of itself. What it reflects is that the parser implementor doesn't really understand LALR(1) parser generators, and is just winging it by the seat of his pants in BNF, using testing to see if the generated parser is doing part of what he intended. With that many conflicts, the chances are very small that the parser is actually doing 100% of what he intended (although sometimes the number of conflicts is all out of proportion to the number of grammar errors). I implore you - if you ever consider writing anything > 1000 lines in this language, take the time to consider the alternatives. ''See here, stop whingeing. No-one has put it better than Terry Chay - php is as ugly as a bag of nails. However, it is ubiquitous and damned useful.'' -- LlewelynThomas <--Bolded for truth "The bag of nails analogy is a very good one - you can do a lot of useful stuff with a bag of nails although it won't necessarily be pretty. However, at some point, you have to realise that the time you saved at the start by being able to get started quickly with simple materials is being overrun by the time needed in maintaining the structure as your aims become more ambitious." {I don't know if any existing languages/stacks that don't force some kind of ''trade-off'' between a quick start and long-term maintenance/growth. It's really hard, and perhaps impossible, to optimize a tool for both. (I have some ideas for something that could better cater to both worlds, but these ideas are not road-tested at this point.)} ---- There is a comprehensive and rather devastating critique [written in mid 2002] of PHP here: http://www.ukuug.org/events/linux2002/papers/html/php/index.html. * See also http://tnx.nl/php (Perl-oriented criticism; PerlLanguage isn't beyond reproach in any way, shape, or form, but nowhere near as bad as PHP.) -- TheerasakPhotha ''I find this critique rather full of personal preference complaints, the kind of stuff that HolyWar''''''s are made of. The only language that would make a given person fully happy is one that is custom-made for that person.'' um, that's a joke, right? ''I agree, I wrote my own language and I'm still not happy with it.'' ---- If it were not for the .php tag, the end user would be completely unaware of PHP. Some solutions to make PHP's operation completely transparent: * Set directory index to include "index.php" so you can http://foo.bar.baz/thud/?a=b * Apache's mod_rewrite can give you an illusion of .html. * You could configure the web server to parse all HTML through php. Or, you could enable content negotiation (http://httpd.apache.org/docs/content-negotiation.html). Either will cost you some CPU cycles. To get rid of the "?", MultiViews (a part of content negotiation) can be used, or you could dive into mod_rewrite. ---- In my opinion, PHP in many ways is a superior, or even the NextStepUp from JavaScript. ''Before you jump on me, please note I said "in many ways" and let me explain:'' Whereas JavaScript, let's face it, is largely Browser / Platform / Browser Version / OS Version Specific. PHP, assuming you can get it to parse on the server, will ''always'' work. ''Unless the server breaks of course.'' [Hum hum... maybe you haven't lived thru a php version upgrade. It hurts. Plenty. I've seen it time and time again, breaking perfectly good code. Also, comparing it to client-side JavaScript is a little weird, but then, php and js are both a little weird :)] One could, therefore, instead of offering a RandomFunction via JavaScript, use PHP instead. The Output would appear as intended, and always work, for everyone. Similarly, one does not have to be "held to ransom" by allowing users access to the SourceCode - or all the variables in a Random function etc. One can also use it in conjunction with JavaScript to write BrowserSpecificJavaScript, instead of having to interrogate the browser through the JavaScript itself - making code even three times as massive - one can let the server do that, sending to the browser, the cleanest, shortest, quickest, most specific code possible. Naturally this increases ServerStrain, but end users won't mind that ''; ]'' And that, DearFriends (well, ModemBound ones anyway,) is what we all want! Great fun! -- MatthewTheobalds Ah, but you'd be forgetting server side JavaScript, young Matthew. Combined with something like WindowsScriptingHost, some of my prototype based object friends swear by it. At least as much as they swear at VBScript. -- RichardDrake ''I must confess, Richard, that I'd never heard of such a thing! I've followed that link through, it sounds very sound. Do you know of any other (preferably good) information sources?'' -- Matthew (who wishes he had a web server in a cupboard to play with) ''I don't understand the above commentary. PHP and JavaScript (well, client-side JavaScript, which is the predominant variety) are pretty much entirely separate beasts. PHP competes in the same market as Python, Perl, ASP, J2EE, etc. PHP has nothing to do with client side scripting. In fact, there is really only a small set of functionality that may be implemented either client side or server side; most stuff you want to do client side you can't do server side, and most stuff you want to do server side you can't do client side. So the comparison is almost wholly flawed, in my opinion. I think it also highlights a view of mine that may be an entirely unreasonable bias, the opinion that many, if not most, PHP fans are relative n00bs to programming and have never tried any languages that might be a direct alternative to PHP. Raving about the advantages of PHP is thus an exercise in head-in-the-sand-ism, since they haven't got a frame of reference within which to compare. On the other hand, I suppose this may say something about the ease of use of PHP (at least at the beginning level), though I suspect it says equally much about the install base, large and vocal community, and n00b-friendly documentation.'' -- Dan And about n00b level of the php world. Considering the code for those vastly used stuff like PHPNuke (which generated PostNuke which generated Xoops which generated E-Xoops, all because the previous code sucked) or phpBB, you'd believe all the php developers have been programming for two months. Not to mention things like the Zend Engine '''segfaulting''' with too much recursion (in php4, fixed now). Look at this article '''on zend.com''' which shows a complete lack of understanding of what recursion is: http://www.zend.com/zend/art/recursion.php. * In all fairness, what's wrong with its description of recursion, essentially? -- TheerasakPhotha And consider this nifty example of "security in php", a captcha example with a ''lovely'' race condition in it: http://phpsec.org/articles/2005/text-captcha.html. I won't dare to say all the php developers are n00bs, but it seems like there are way too much of them at every level. ''How is the number of n00bs an indicator of how good a language is? By your logic, every popular language should have been chucked within two years of it coming out. Java was filled with n00bs when it came out. So was C++. I think that the number of n00bs is an indicator of the popularity of a language (everyone is using it, so everyone wants to use it).'' It's not an indicator of the quality of the language, but it is worth noting. The user base typically has a large or even predominant influence in how the language is developed - what features are prioritized, what features are abandoned, etc. Since the PHP community ''appears'' to be much less, ah, mature, the sorts of features that seem to get prioritized are horrible abominations like magic quotes, rather than more elegant features that only more advanced programmers understand. I think there's a reasonably strong argument one can make here, that a language that is focussed on advanced use can still be easy for beginners (see e.g. PythonLanguage), but a language that is focussed on beginner use rarely is as good at accommodating an advanced user (e.g. variations on BASIC). But, like I said above, this may be wholly unreasonably bias on my part. -- Dan ---- The thing that always bothered me about PHP is that it's a new language, and a fairly clunky one at that, for performing a task that could easily be performed in Perl, which inspired the PHP project. Why didn't they just make a template system for Perl instead of inventing a whole language that's kind of like Perl only not? ''A 'template system for Perl' is almost exactly what PHP started out as in 1994; a bunch of Perl scripts for maintaining the pages on the primary author's site. Before too long, however, it crossed the threshold that so many such systems cross when they're popular, and became computation-universal. After that its (literally, its) functionality has sprawled out in all directions, ingesting whole the API's of a ridiculous number of libraries; unfortunately without much regard to abstraction.'' Because in general Perl is TooPowerful. In order to do anything interesting in Perl, you have to use lots of weird constructs and syntaces that aren't easy for newbies to the language to figure out. By contrast, PHP reads mostly like C or JavaScript, and everyone is familiar with those. ''Question: How is a cryptic syntax a good thing?'' ''Perl is a "career language", rather than a scripting language. It takes longer to figure it out and requires more knowledge to read other's code. PHP is made to get into it easy and get out of it easy.'' My guess is that PHP is popular, not because it looks like C, but because it looks like HTML! ''How so? It looks like a Unix shell scripting language to me?'' '''This is my guess why PHP is popular: C, C++, Perl, HTML, JavaScript, ColdFusion, ASP... it looks like whatever you want it to look like''' Many PHP pages are mostly HTML, with some PHP bits thrown in. The ability to start with just a ''little'' PHP explains its rapid spread. ''Look through the PEAR library, you will have a hard time finding ''lots'' of HTML''. ''Yes, that too. You can have pretty much an entirely normal HTML page, but with a couple of '''if''' statements thrown inside a form to determine which fields or default values are appropriate (to choose a simplistic example). Makes things much easier for beginners to server-side programming.'' If you want a language that looks like HTML, then go to ColdFusionLanguage. ---- PHP is an ultimate instance of AddEverythingSomebodyMightNeed. As such, it has developed to be a very quick solution to many needs that are known from beforehand. However, it is relatively unsophisticated as a programming language, has a horrific TypeSystem (with automatic conversions happening all the time and messing up program logic), and is all the time somewhat broken. -- PanuKalliokoski "horrific TypeSystem" -- if you came to php from a language that had weak typing, then it seems quite natural. It is a strange juxtaposition, (C++ - like syntax with weak typing). However MumpsLanguage (my former world of expertise) also has weak typing, and this (like pointers in C) can be used to tremendous advantage by one who isn't afraid to use the "Force". -- RichStone ''I wrote my own comparison functions to reduce typing problems. Besides, I need to often trim and convert/ignore case to compare, so I need such a function or operation anyhow.'' ---- If Programming and PHP in particular is so easy then why do I find it so incredibly difficult to grasp the basics? I can install it, I can hack things for my own uses and I understand so much, but yet I don't have the first clue how to go about writing my own first application so I am forever either borrowing or downloading other people's work only because I cannot seem to grasp the thing that everyone else seems to find to utterly simple. Could it be the math? I've ALWAYS sucked at math. ;) A Fan What are you trying to do in PHP? You may be using the wrong tool for the job. ''Try the text PHP and MySQL [ISBN: 0672317842]. It has very simple, yet practical examples. It's not just another reference manual. Although, if you just want to implement a standard web feature like a message board, there are usually free packages out there already that you can install and use without writing new code. -- BlakeMason'' ---- How do you unit test PHP? Or any web scripting language for that matter. ''WebTesting''. PHPUnit http://www.phpunit.de ''is the de-facto standard'' SimpleTest at http://sourceforge.net/projects/simpletest/ ''no one uses that anymore'' Related tools at http://phpqatools.org/ ---- Its type checking is horrible. You can't know with a simple test if a variable contains '0', 0, "", [], or has not been initialized so parameter setups become hell. ''This is not accurate WRT PHP4 and newer. The first three can be handled with the '===' operator. is_array() and isset() can handle the other two.'' The function/method nomenclatures for simple types (strings, array...) is widely inconsistent and a mess. ''No argument there!!'' And the killing blow: it does not handle unicode! ''It doesn't have to. PHP is an example of a DomainSpecificLanguage - it interfaces to a database or filesystem, and spits out HTML. Keep your unicode in the database, it's just an opaque blob to PHP.'' I'm going to try mod_python to write a little site now, I can't stand doing it in PHP. ---- Regarding PHP's "typing", the problem in my opinion is that it seems to use a hidden "type" attribute for variables. I would rather it be more WYSIWYG, and use type-specific comparitor operations like Perl (strings and numbers are compared differently. I make my own comparing functions in my PHP). It seems to want to keep one foot in the static or "strong" typing room and another in the dynamic room, but the mix causes problems. (Those who are fans of static typing probably will not like PHP. Typing preferences are one of those HolyWar things.) ---- ''For everything in life, there is an explanation and a PHP function.'' -- Luc on The Move ---- One of my guesses about why PHP is so popular is the documentation. PHP is often claimed to be easier, which might be true, but I didn't think so when I started learning it. Instead, I thought the documentation content and format were such a godsend. I still think PHP has the best documentation among all languages. Not that I have read all others', of course. Every function has an example, and the user comments are just invaluable. Groundbreaking. And you can even take it home in CHM format to read off-line... -- Luc on The Move ---- A lot of the information up top is either dead wrong, or out of date. But because most of it is opinion based, I am hesitant to refactor. ''I disagree a lot. I think your opinions are more biased than the above. But I'm not objective myself...'' Too true, I do in fact have biased opinions. Just because my opinions are biased, it doesn't mean that they are wrong. Regarding php and typing, stop trying to make PHP into yet another Java. If you want a type-safe language, use a type safe language. ''The type problems are not about its being dynamic but about the frightening automatic conversions and the constant changes in the type system. "1" and 1 should be quite equivalent, shouldn't they, unless explicitly queried for type. Now, !"1" is "" but !1 is 0. Yay.'' Actually, I am starting to agree with people when they talk about PHP's type system. !"1" is "", because you are casting the number into a string (with quotes) and then casting that further into a boolean, (with the ! operator), which evaluates to false. Which is then turned back into a string, and (bool)false is (string)"". Is that the right way to handle it? Probably not, but that is what is going on behind the scenes. ''Logical, annoying and a little confusing but logical.'' If you '''need''' to deal with types, then use the === operator (compares both the type of the variable and the content). Also, using the is_ functions can help. Function nomenclature in PHP is a known issue, and is slowly being worked on AFAIK. As a rapid prototyping language, PHP is an excellent choice. It is extremely easy to get started with PHP. Also, what might take you weeks to write something in Java or C++, will take you days in PHP. ''Easy learning and quick prototyping don't come hand in hand, actually they often have contrary goals. Also, it's ridiculous to compare PHP with C++, and hard to compare PHP with Java. None of these three languages is what I would use for rapid prototyping (or anything other, for that matter).'' Perhaps I should have said PHP and Java-with-servlets? How do Easy Learning and Quick Prototyping have contrary goals? Because PHP is so easy to learn, there is a lot of sloppy code out there. It is very easy to write bad PHP, it gives you the rope, you hang yourself. (''That sounds just like C/C++'':) ''Yes, and it's hard to write good PHP. For example, just try to make a proper OO framework for ''anything'' in PHP and you'll see.'' I have. It just means you have to have self-discipline and not expect the language to be the whip-wielding mistress. (see BondageAndDisciplineLanguage) PHP is not a server-side only language. PHP-GTK gives you (limited) GTK (GUI) functionality, and PHP as a shell-scripting language. ''You must not have done shell scripting very mush. sh is far superior for shell scripting, compared to PHP, and for quick-to-build graphical apps, Python is both easier and scales better.'' Agreed, I think I spoke a little too quickly there. Any True Shell Scripting languages are better choices for shells scripting. But what I am saying is that PHP can compare with perl or python in the scripting department. I haven't seen how you work with GUI in elements in python, so I can't comment on that. Now, what do you mean "Scales better"? Is the python executable smaller in size, so you can run more instances? I get the impression that when people say "Language X scales better than Language Y", what they are really saying is "Language X is better than Language Y". PHP is a Language unto itself. It should not be confused with HTML. PHP5 (of which there is a beta out now) will be an absolute dream, the reference issues will be dealt with (objects will be passed by reference by default), also, objects are no longer lists with functions bound to them. Interfaces are being implemented, as well as public, private and protected variable/method access. There is a bunch of other PHP5 goodness to come. ''In my book, anybody who says "will be an absolute dream" really can't be trusted to provide any light in pros-and-cons discussions...'' What, with 5 words, anything I have to say is invalidated? Because I enjoy the language, and enjoy the updates to the languages, anything I have to say is invalidated? ''PHP5 was released in 2005. It fixed many of the complaints listed in this topic. Should the complaints that are no longer valid be removed?'' And finally, a PHP Application Server is in the works... SRM (Script Running Machine, http://www.vl-srm.net ). It also is in beta, but it is quite funky. (Note that this is a true application server, and not a framework pretending to be one.) ''no, this is a dead link'' If anyone needs any PHP help, by all means, drop me a line. -- JonathanArkell ---- PHP lacks named parameters. I want them. ''Can someone please explain this for me? Is that where you... uhh... what?!'' ["named parameters" and "keyword parameters" are synonyms; the latter term is preferred e.g. in the Lisp world] That's when you specify bindings by keyword instead of position in the argument list. They're useful when a function might have a bunch of optional parameters that can be supplied in arbitrary combinations. In a hypothetical PHP that did support them, it'd be something like: function foo($x, $y, keywords: $bar, $baz, $bain) { ... } foo(2, 3, $bar = "some value"); foo(4, 5, $baz = 13, $bain = "note that bar is not supplied"); You can simulate this by passing in a dictionary, but then you need to call array() with it's funky syntax every time you call the function. That's rather inelegant. <-- as of PHP 5.3 you can use [] instead of array(). ''You can just use compact() http://php.net/compact'' ---- I've been doing rather too much PHP programming recently... the project I'm working on has well exceeded 10k lines of code. Much of the above is out of date as PHP 5.0.0 has now been officially released; I bit the bullet and transferred to it, even though I was so far in already. I only had to change 2 lines of code to be compatible. With regards to debates about typing conventions; I control the flow of data in my computer. It doesn't matter how the typing works; ''I'' know what data type a variable is, and ''I'' tell my functions what data to send where; having to first inform a language what type a variable is, and then assign it a value of that type, surely goes against OnceAndOnlyOnce? Loose typing allows my functions to be more flexible; most of them can accept various types of data and handle them appropriately. I find strong typing makes my life more difficult. -- PeteHurst ---- I'm now coming up on 5k LOC (not counting support code like templates, unit tests, or SQL) and am beginning to like the language a bit more. As far as language quality goes, I'd put it on par with Java, which isn't terribly high, but is better than a lot of people give it credit for. DynamicTyping comes in much handier when you get used to it: I often use it to simulate TypeUnion''''''s, like the Dylan false-or() construction. The $object->$method($arg) construction gives you a limited form of HigherOrderFunction, like a CeeSharp delegate. I've found it's saved me dozens of lines of what would be duplicated code in Java. Lightweight syntax for arrays, and the ability to add an element at the end with $array[], is similarly useful. The biggest annoyances are SelfDotSyndrome ($this->method()) and the inability to compose method calls (mentioned above). I thought the default CallByValue semantics would be a problem too, but they haven't been so far, mostly because I've adopted a more FunctionalProgramming style where I make copies instead of mutating the object. I'll have to see if performance becomes a problem, but I OptimizeLater. I've noticed that I use classes mostly as namespaces in PHP. A lot of them contain no instance variables (and hence no state), but are done simply so I can keep name collisions manageable. Or I'll put all the state in an AbstractBaseClass that's responsible for updating and maintaining it, and delegate operations to subclasses. I've found programming in PHP becomes much easier if you stop worrying about how the language sucks so much and just learn the idioms that let you get work done easily. Languages don't have to be perfect; most of them have warts (except for SchemeLanguage ;)). But it's usually more productive to focus on what you ''can'' do with the language rather than what you ''can't''. -- JonathanTang Just ran across an interesting bug I thought I'd share: I was running a really simple - no functions or object-orientation - PHP script, and it kept entering an infinite loop and using up all the CPU. I couldn't imagine how something like that could loop forever; there were only about three loops in the entire script, and all of them were trivial for or foreach ones. But with the help of a few echoes, I narrowed it down to this line: for($i = 0; i <= 3; ++$i) { If you're used to staring at Java or C, you might wonder what the hell is wrong with that. Well, I forgot the $ before the second i. In PHP, an identifier without a $ is a define()ed constant. In PHP, undefined constants are equal to the string value of their identifier; in other words, the undefined constant i has the value "i". In PHP, strings can automatically be coerced to numbers; if the string is not a numeric value, it has the integer value 0. So the for statement above really means: for($i = 0; 0 <= 3; ++$i) { which obviously doesn't halt. All without a warning message (I suspect that I could have changed a setting somewhere to warn me about this, but I haven't really fiddled with my php.ini). Luckily, this only took about 5 minutes to track down, after I spent 20 minutes trying to regain control of my computer. But you'd think it's pretty shitty language design that lets a missing character lead to an automatic infinite loop. -- JonathanTang ''If you value your sanity, always develop with error_reporting set to E_ALL. (You can do this at runtime by calling error_reporting() function, or can set it in php.ini.) This would have displayed a warning here.'' ---- Current PHP is a mess, I've recently found a nice complaints collection http://czth.net/pH/PHPSucks, and as a PHP fan I have to say it's all true. That's why I hope someone will step in and make a PHP6 around ParrotCode, which breaks backwards compatibility but fixes all the ridiculous bugs (especially wipe out the SafeMode made for lazy hosting providers, and the MagicQuotes for stupids). -- MarioSalzer ---- '''' PHPSucks is a bunch PERL whiners lamenting the loss of market share to PHP. Most of the comments on the site are at least two years out of date and talk about issues that have long been resolved. The rest of the comments whine about PHP not being more like PERL. Get it straight, PHP IS NOT PERL, PHP IS NOT JAVA, PHP IS NOT C++ AND PHP IS NOT XXX. Does the language have quirks? Yes. Could things, in retrospect, been done better? Absolutely. Is the PHP team addressing these issues? Obviously. Will it take time? Of course. I challenge any of those whiners out there to point out a language that is perfect. No quirks, no warts, no inconsistencies, no constructs that let you write bad code. Nothing that could be improved upon. And when you find that language cross link to it from here so we can put a discussion page and whine that version 2 sucks and that it's not more like PHP. '''' Ahem, I feel better now. ''You're partly right that we're a bunch of whiners - I feel a probably irrational dislike for PHP - but simply saying "other languages are imperfect" is no defense. Nobody here has argued that Perl is perfect, to take your example (I'm not such a Perl fan myself), but rather that PHP is ''more'' imperfect than many alternatives. The primary complaint I have with PHP is that, contrary to being relegated to the depths of obscure domain specific languages as I think it should have been, PHP has flourished and gained popularity, yet, in the process, has hardly improved as a result. That's quite frustrating, since I would like to be more optimistic and think that ''good technology'' is what is needed for success, not a bunch of children and inexperienced Web developers who think PHP is the r0xx0rs. But regardless of my personal prejudices, I think it's fairly cut and dry that many alternatives exist that don't have the number of flaws that PHP does, and, if you are trying to decide what language to use, that is what really matters.'' -- Dan Well the domain of PHP happens to be creating web sites, one of the more popular ones ever. ''It's also a very good shell alternative. I've mostly switched from Python to PHP for my command line scripting needs.'' ---- Please consider the follow: There are certain programming languages created to serve certain purposes. Just as there are certain color, styles, and types of automobiles to suit your personal needs. Programming languages are designed for purposes determined by the creator to solve their (not necessarily your) problems. Many times, they create features not addressed in other languages. Oftentimes, they mimic the behavior of other languages they like. If type checking is what you want, use a language that has it. As programmers, we should not complain about this language not having this feature, and this other language not having this feature. I believe, and this is my own opinion, we should concentrate on using the right programming language for the right task at hand. We are the intelligent nerds, and pride ourselves on our capabilities and pure ingenuity when it comes to solving complex problems. So quit flaming and complaining and start acting like mature professional programmers and show the world what you're capable of. The best way I can compare the right language to the right job would be like a woodshop craftsman using the right type of chisel for the detailing. You could use any one you want; we use whatever IDE suites our fancy and if we do not find one we like we can always make our own. Just a like a craftsman would. Programming is a skill, and, just like any skill, it takes time and patience to learn the right tool to use for the right job. The best examples I can give are programs that use several languages. These programs use each language where it is best suited by using the most "efficient" syntax were it is needed. Kernels are a common example of this. I call on all programmers out there to learn as much as possible about as many languages as possible. This way, you will be able to decide what programming language to use for the job, and not waste your time and our time complaining that X language does not have Y feature. In short, use the language that is best suited for ''your'' problem! -- crmacd It's not that simple, because not all software flows out of a single En1337ened individual. When you have a bunch of crappy programmers writing crappy programs with a crappy language, you're going to have a crappy time maintaining that crap at some crappy hour on some crappy Sunday morning, resulting in a perfectly good day off going down the crapper. PHP must be destroyed. --crappy TheerasakPhotha How does PHP allegedly allow for more abuse than say Perl, or even Java? I would like to see examples of such grand language-specific abuse. ---- I have been using PHP for four years now. I have a background in CeeLanguage, CeePlusPlus, ColdFusion, FortranLanguage, JavaLanguage, and PerlLanguage plus a number of others you probably never even heard of so I think I can speak to this. PHP is an easy to learn, easy to use language that is well suited for light lifting. It has a fairly good library of functions and classes that cover most of what needs doing. Most of the heavy lifting is done via functions written in C so speed is not an issue. All that said, PHP has not yet matured as a language. I am sure that there are a few people out there who still remember K&R C. How things would change from platform to platform. How functions would behave differently from vendor to vendor. How functions would not be orthogonal and modularity would be enforced by coding standards rather than language constructs. Most of these problems were resolved as the language matured and was standardized. This is where PHP is now. PHP5 is beginning to resolve the big issues. Oddly enough, PERL5 was the turning point for PERL as well so maybe it takes five versions of something before the problems start being solved (''System V was the turning point for Unix''). Hmmm... another example of the LawOfFives? ---- The company I am working for is using PHP4 since four years. Until now, no-one wants to switch to PHP5, because our software product has grown to an enterprise web application with several hundreds of thousands of lines of code. The big overhead to make it PHP5 compatible would take a few weeks of precious developer time. Furthermore, I am part of many other projects written in Java (Struts) and C/C++. So, I have experience in all of them. However the PHP4 product is a maintenance horror. Definitely some developers made bad design decisions (me too), but the point is that PHP dynamic semantics is a bug source. For example: I had a typo in an argument of a method call: function Foo(&$oObject) { //do some cool things with the object } $oObject = new CSomeObject(); Foo($oObjext); As you can see, I wrote $oObjext rather than $oObject. However, PHP didn't complain about it. Why? Because Foo takes a reference as its argument. (Otherwise PHP had "thrown" a notice.) As you expect, it took me a while to find it. By the way: we use the hungarian notation for PHP. I love strong datatype checking... -- ChristianMueller ''Isn't the warning/error level configurable? I agree that one did not have fine-grain control over which kind of errors it ignored at each level, etc., but a stricter adjustment is possible I believe. In general, you seem the kind that prefers strong typing such that a dynamic/scripting language will not make you happy. Also, maybe version 5 has a better solution for the above.'' ---- Haven't used PHP in a while, but the same typing problems for doing fancy stuff also opened up some fairly intuitive ways to use the NullIsBenign pattern for casing, and the implicit ability to pass an arbitrary amount of arguments into a function (would that be a ReverseCurry?) allowed for some very powerful casual polymorphism - not more expressive, and potentially a big pain later as it allows functions to keep growing with new parameters without forcing refactoring, but very conducive to quick and dirty prototyping. ''This may be related: EmulateKeywordAndDefaultParameters'' ---- I've been programming in PHP for over 7 years (not always by choice). In my opinion, the biggest problems are tangential to the language proper: * error_reporting(E_ALL & !E_NOTICE); no, hiding errors does not make things easier for beginners; it make things harder for everyone; * magic_quotes_gpc - die! die! die! NuffSaid. * php_short_tags - and three other ways to embed PHP code into other files, two of which can be deactivated. How stupid is that? * register_globals - possibly the most moronic language feature ever; luckily, few programmers rely on it; * running halfway through a script before noticing that a required extension was not loaded, and that's just because a vital function is missing. The usual suspect: GD. Fortunately, PHP5 solves these issues halfway (by making them non-default), and PHP6 will get rid of them (except for error_reporting). -- FelixPlesoianu ''PHP6 will not get rid of template syntax. https://wiki.php.net/todo/php60 is the 'todo list' for PHP6, http://www.php.net/~derick/meeting-notes.html is a more detailed (but older) document'' PHP6 has been pushed off to the future = Unicode support. Features originally targeted for 6.0 have been rolling out into PHP5 updates since 5.3.x. PHP 5.4 (released 2012-03-01) made