Skip to main content

Why PHP sucks

(July 8 2005)

Apparently I got linked by some PHP sites, and while there were a few well-reasoned comments here I mostly just got people who only knew PHP reacting like I told them their firstborn was ugly. These people tended to give variants on one or more themes:

  • All environments have warts, so PHP is no worse than anything else in this respect
  • I can work around PHP's problems, ergo they are not really problems
  • You aren't experienced enough in PHP to judge it yet

As to the first, it is true that PHP is not alone in having warts. However, the lack of qualitative difference does not mean that the quantitative difference is insignificant.

Similarly, problems can be worked around, but languages/environments designed by people with more foresight and, to put it bluntly, clue, simply don't make the kind of really boneheaded architecture mistakes that you can't help but run into on a daily baisis in PHP.

Finally, as I noted in my original introduction, with PHP, familiarity breeds contempt. You don't need years of experience with PHP before an urge to get the hell out and into a more productive environment becomes almost overwhelming -- provided that you have enough experience to realize what that nagging lack of productivity is telling you when you go to consult the documentation for the fifth time in one morning.

Basically these all boil down to, "I don't have enough experience to recognize PHP's flaws because I haven't used anything better." Many years ago, I had this same attitude about Turbo Pascal: it was the only language I knew at the time, so anyone who pointed out its flaws was in for a heated argument.

There's nothing wrong with being inexperienced, as long as you have an open mind. If you do, try Spyce. Try RoR, if you must. Better toolkits are out there, for those who aren't satisfied with mediocrity.

I've done a fair bit of web development. I've written HTML-generating code in C CGI scripts, Cold Fusion, TCL (with OpenACS), ASP.NET, and, of course, Python with Spyce.

Two technologies I've steered clear of are any J2EE stack and PHP. I've seen enough of each to know that I'd be immensely frustrated with either. Briefly, although they are quite different, neither is elegant, and elegance counts.

Recently, though, I had to spend a few days extending a small amount of PHP code. (I'm just glad for two of those qualifiers: "few" and "small.") The more I used it, the less impressed I was, which is why I don't think a longer experience would make this post any more favorable to PHP.

This is far from an exhaustive list. It may have some reasoning in common with other voices of reason, but I'm writing this primarily from a Python developer's perspective. So, I won't waste time bashing PHP for being dynamic, which some Java zealots do; nor will I fault it for mixing code and markup, which also has its uses (and Spyce recognizes this). PHP's problems are much, much deeper.


First, let's try to be a bit more specific. Does PHP the language suck, or does PHP the environment suck?

They both suck.

In fact, they suck for the same reason: PHP-the-language and PHP-the-environment both grew by accretion of random features, not by any purposeful design for orthogonality. So you have idiot "features" like magic quotes ("Assuming it to be on, or off, affects portability. Use get_magic_quotes_gpc() to check for this, and code accordingly) and register globals (same disclaimer applies, only more so).

Trying to write "portable" php code is such a disaster that it's no wonder almost nobody tries; you can't even code for a least-common-denominator version because (a) so much is subject to change on the whim of the site's config file and (b) even if it weren't, the PHP designers change the defaults almost as often, even within minor version releases. (E.g., the registerglobals change for 4.2.)

The PHP community realizes this to a degree, even if the fanboys won't admit it. PHP5 uptake is almost as glacial as MySQL4 was/is because it breaks so much code. One of the biggest ways is, "all your copy-on-assign code, isn't anymore."

That bears explaining if you haven't coded in PHP4: any time you make an assignment in PHP4, what other languages would call a "deep copy" is performed. So you might naiively expect this code to add a new key/value pair to the associative array at $a[0]:

<?
$a = array(array('foo' => 'bar'));
foreach ($a as $item) {
   $item['new key'] = 'new value';
}
print_r($a);
?>

This, of course, changes $a not at all, because the assignment to $item is a deep copy. (It's also slow as hell if the items you're deep-copying are substantial.) The workarounds for this are truly ugly.

This changes completely in PHP5, which is a good thing, unless you're trying to upgrade an existing body of code. That's not a small "unless;" if you weren't using PHP4, there's really no excuse to start out in PHP5 instead of Spyce or CherryPy or Rails.

Even with a willingness to break backwards compatibility, a lot of broken behavior persists in PHP5. For instance, since I brought up PHP arrays: an array in PHP is really a map. When you're using it as a linear array, it's really mapping keys 0, 1, etc. to your values. (I don't want to know what it does when you're using it as a 2D array.) This might seem like a good idea, until you spend about two seconds thinking about it, at which point those of you who have had a basic introduction to data structures will be thinking, "What the hell? The performance will SUCK!" And you are entirely correct. The only other language I can think of that does this is AWK, and it was a bad idea there, too, but less of a problem since, well, when was the last time you wrote an AWK script longer than 10 lines?

PHP-the-language also shares with Perl the unfortunate tendency to guess what the programmer "really meant" instead of raising errors. (String where an integer makes more sense? No problem, we'll just throw in zero!) Unlike perl, there's no "use strict" option to mitigate this.

I could keep going, on how, for instance, the PHP environment doesn't give you any way to have a single, multithreaded long-running process, which is probably why you see so much PHP code that sticks everything into the session object. Or how PHP's string processing library adopted the C stdlib functions without improving on them. Or a dozen things, but a comprehensive enumeration of PHP design flaws would be a daunting task indeed.

In short, PHP sucks because, PHP's authors are prone to confuse "pragmatism" (a fine design goal, if done well) with "adding random features without considering how they impact the language as a whole." Thus, its authors have found it necessary to correct obvious flaws in both minor and major releases, with the result that the recent PHP5 breaks with the past to an unprecedented degree while still leaving many fundamental flaws un-addressed. I don't know if this is because they didn't recognize those flaws, or more likely, because they were willing to impose "requires a lot of pain to upgrade" but not "requires a complete re-write."

Ian Bicking wrote that "Python could have been PHP" (in popularity for web development). If I were a PHP developer, I'd be pretty disenchanted with how the language has evolved; I don't think it's impossible that Python could have a second chance.

Comments

Anonymous said…
I'm a PHP developer, and have been for three years, but I have to agree with some of your comments.

magic quotes, and register globals should have never been added as a "feature" and is just a pain to have to code work around today, to get the script's to work with it on and off.

I also agree with PHP5 breaking most PHP4 script's, that's what, in my opinion, will hold back PHP5 becoming main stream, we won't have much luck with it until popular script's are updated to work with PHP5, and server's by popular demand will need to upgrade. Until then we won't see much changes to these problems.

I love how python works, but really haven't taken the time how actually learn it, only downside is that mod_python isn't installed on many server's.
Jonathan Ellis said…
Spyce will run as a CGI/FastCGI script, Justin. :)
Anonymous said…
I probably should have done more looking... thanks!
Anonymous said…
Magic quotes and register globals were features designed to lower the bar more, for newbie developers who didn't understand databases, or HTTP as well as for seasoned professionals to write code quicker by making certain assumptions. You can write secure code with both of those settings if you're careful and know what you're doing. These two extremes: easy for newbies, and short cut for seasoned developers don't mix.

Unfortunately, delivering web apps for use by others cannot make those assumptions.

You really don't have to worry if a user has register globals on or off. After all, you the app developer should be using the global arrays anyway. So, it's really just magic quotes which can be a pain. And is it a pain to detect it and do an ini_set? That's just a couple lines in a global include.

Ok, next subject: arrays. There is no pretense on what arrays are, see here:

http://us2.php.net/manual/en/language.types.array.php

And the manual notes that they are maps, and are optimized so that they can be treated as lists, hash tables, queues, stacks, etc.

I would venture so far to say that PHP arrays are extremely powerful, flexible, and straight forward. Moreover, I trust that the many PHP engine developers - many of which hold degrees in comp sci and know of The Big O and data structures, have in fact optimized the arrays for the best speed possible. As far as I can tell, using arrays heavily in PEAR::SOAP is that the performance is great.

Last but not least, PHP5. There are incompatibilities everywhere in software development. There is a compatible mode for PHP5, and going through your code and fixing reference changes is a do-it-once and your done exercise. You bit the bullet for the day / week, and then you're good to go and ready to take full advantage of all the new features. It's a small price to pay, and gradually people are making that change.

I have no qualms against Python, but flaming another language wihout due course, now that just sucks.
Anonymous said…
Been working with PHP recently (sadly version 4) and couldn't agree more with your observations.
Anonymous said…
Couldn't agree more, Jonathan. I have really tried to like PHP several times now, but the features have been adopted so haphazard that I go crazy with it. Many are duplicated and the API is nonstandard to itself. The database layer(s!) are one of the best examples of this type of evolution.
Anonymous said…
I have to use PHP at work, and it does indeed suck. I could lengthen your list of gripes by a factor of 100!

But as my friend is fond of arguing, my main beef with PHP is that (like MySQL) it does exactly what it's supposed to do, it just shouldn't be used for a lot of stuff it's used for. It's a fast and easy-to-use web scripting language, not a strictly typed scalable enterprise language. :-)

Too many people choose PHP for the wrong projects!
Anonymous said…
Another anonymous commentator said, "I trust that the many PHP engine developers - many of which hold degrees in comp sci and know of The Big O and data structures, have in fact optimized the arrays for the best speed possible."

Holding a degree in computer science does not make you magically able to alter the fundamental properties of fundamental data structures.

If PHP's "arrays" are implemented as balanced trees, their performance will be O(lg n) for all operations, compared to O(1) accesses on real arrays, or O(1) prepends on real lists. If they're implemented as hash tables, then however good the hashing function, there will inevitably be many degenerate cases where insertion and lookup complexity rises to O(n). This is called "not scaling well".

However they're implemented, memory usage on simple arrays will ALWAYS be considerably higher than it would have been for a specialised array type. You've got great performance on your code? Then either you have incredible resources at your disposal, or you only have half a dozen unique visitors in a year.

PHP simply doesn't scale as well as other alternatives. That's not bashing PHP; the world needs a simplistic language that newbies can put together a homepage in, and PHP handles hobbyist sites beautifully. But claiming it's ideal for every kind of programming is stupid. Let's just say there's a reason Doom 3 and Longhorn are not written in PHP...
Anonymous said…
All this bashing from someone with little experience in php. Funny you dont mention your experience with coldfusion.

Coldfusion is a notoriously bad framework that allows you to do stupid easy things quickly and then takes forever to do anything real. Talk about arrays not being implemented properly, coldfusion doesnt know what arrays are. A sort on two dimensional arrays sorts a single dimension only. It was obviously written by and for folks that have no programming experience or knowledge.

The reason I bring this up is you bash php, which you admit to steering clear of and yet you dont bash the much horribly worse language that you admit to using. So your argument boils down to "I dont know this very well, so it sucks."

Php is head and tails above most scripting languages. Yes, it has quirks, but they are logical and easy to work around, unlike most baby languages, where you spend all your time fighting the language/framework.
Jonathan Ellis said…
I developed in coldfusion for about a year because I was paid to do so. What's your excuse for using PHP so long that you've apparently become allergic to the obvious?
Anonymous said…
Is that your way of agreeing with me without saying it? You only used cf because you were paid to?

The obvious here is that you have limited experience with php and the flaws in php you put forth are trivial to work around.

CF sucks 10 times worse than php in exactly the things you bashed php for. That to me makes php a MUCH better choice over atleast cf.

The fact that you cant understand that obvious point makes your whole post suspect.
Jonathan Ellis said…
Grasping at "coldfusion sucks" as a straw man because I mentioned it along with 4 other web technologies is pretty weak. Nowhere did I say that CF was good technology; neither would I be writing CGI in C these days.

But PHP is a real train wreck, the sort, as I mentioned, that doesn't require long experience to recognize if you have a broader experience by which to judge it.
Anonymous said…
"Grasping at "coldfusion sucks" as a straw man because I mentioned it along with 4 other web technologies is pretty weak. Nowhere did I say that CF was good technology; neither would I be writing CGI in C these days."

That is why PHP is so popular. It is better (and cheaper) the CF -- and not as ancient as CGI.....No other technologies or web based scripting languages have really stepped in and claimed the ground that PHP covers. I.E. -- easy enough for the beginner to get their arms around and start using, but powerful enough to grow.

Granted, I agree with most of what you said -- but I fail to see any real alternatives in this arena.
Anonymous said…
I use PHP quite extensively in my (day) job as a programmer at a radio station, and find the arrays to be immensely useful compared to other languages, even other web-based scripting languages. The fact that exceeding array indices is virtually impossible in PHP is immensely helpful, since it greatly simplifies the logic of the program, delegating bounds-checking to the preprocessor. Indexed iteration through an array is the only time I've accidentally overstepped the bounds, to my memory. I must also point out that large datasets rarely occur in PHP scripts; I cannot recall ever requiring an array of a size where the big-O efficiency was an issue; that sort of computation I generally leave to the backend data storage engines, which are already optimized for large datasets anyway. I do agree that the function libraries are designed in a vastly unstructured way, but this hardly bothers me; perhaps this is only because I have a good memory for function names. Software engineers who point out superficial problems with a given language (like inconsistent function names) always seemed like pansies to me. The loose-typing of variables has never caused me too much grief (I just have a small library of type-validation code I've written for PHP as an include file--it works miracles), but the ability to dynamically create variables ex nihilo is a large source of subtle bugs arising from typos, and this is one of my major gripes about the language. Magic quotes doesn't seem too horrible either; if you control your server, they are a nice shortcut. If you do not, simply encapsulate query string variables in a set of functions to properly escape or unescape them; you'd have to do it anyway every time you stored them in the database, so it's not any extra work at all, really. It is odd that your article complains of the time wasted on these things, which all have very quick remedies, when it ignores the time which would be wasted debugging array index problems, creating customized datastructures of great complexity where nested PHP associative arrays are much simpler, and other such things. Granted, if you actually MUST use large amounts of data in arrays, I can see the problem of inefficiency . . . but why would you be using PHP for such things anyway? No language is meant for all purposes. In the end, I find your arguments against PHP (the language) to be valid, but misdirected and, in some cases, trivially worked around. Your arguments about the management of the PHP project, however (regarding changes in APIs, initialization files, and other things), all have great merit; these sorts of problems are generally part-and-parcel to most open source / free software projects.
Anonymous said…
Once I was complaining about PHP to a colleague who then informed me that he had the unfortunate position of writing a lot of VB Script and I should be thankful for how lucky I was to be able to use PHP.

As for the PHP environment inconsistencies, this is a non-issue. 1) you can detect and correct the problems at runtime, and/or 2) you can change php.ini or modify php flags in apache when setting up a domain. It only takes 5 minutes. Compared to the hundreds of hours of programming I do, complaining about flags in php.ini is petty. Every other environment I have ever encountered has similar configuration issues -- be it flags to a C compiler, classpaths, or whatever.

As for the incompatibilties between PHP4 and PHP5, I have never seen this actually be a significant problem with any project. I have never seen code that actually depended on copy-on-set. All I have ever seen is &= statements to prevent it from happening, which are now just redundant code.

What is the internal structure of an array() ? I don't care -- it may as well be a linked list, because for any data set large enough to matter, I use a database.

The fact that PHP is an accretion of random features has two sides -- one its bad because everything is in a huge shared namespace and sometimes the argument style is inconsistent. but its also good because it means that PHP has a lot of features! Instead of worrying about how things are organized, a lot of work has been put into cramming PHP to the brim with every possible feature. That makes it easy to use -- no hunting for some module to import, its all just there.

Let me add that I *love* python, C, perl, mathematica and a bunch of other languages. Each of them have their moments -- just don't misuse them. I don't write web pages in C, and I don't write real-time interactive programs in PHP.

Finally, there are some really deep problems with PHP that also fall in its scope of pratical use (i.e. for web pages), but those problems are bigger than just PHP -- things related transaction processing on large scale and complex websites going from the browser all the way into the database. AFAIK the various "enterprise" Java products (JSP et al) come the closest to dealing with them properly.
Anonymous said…
I write lots of PHP code and I find annoyances:
* messy standard library. inconsistent arguments require often manual lookups.
* classes require use of $this-> for every method/var.

but some of your points are not valid or exagerrated:
* register_globals doesn't matter in well-designed code and it takes one line to remove magic_quotes.
* My PHP4 code just works on PHP5. Switch can be painful, but doesn't have to be. It depends on coding style.
* PHP, and its arrays, are fast. Fast enough for their purpose. PHP arrays flexible and easy to use. Programming speed is often more important (and expensive) than server speed.
Anonymous said…
Writing portable code is not that hard if you know what you are doing. I assume that if you had problems with register_globals is because you were not using the superglobals in the first place, or HTTP_SERVER_VARS, or well...you kept the default install. I've been using superglobal arrays even back in the days when the default was ON.

I don't see how the magic_quotes represents an obstacle to writing portable code. There's plenty of functions to help you out: stripslashes(), ereg_replace(), set_magic_quotes_runtime(), etc
Just write a globally included script that deals with all submitted vars accordingly by processing the superglobals according to whatever the setting is. Not impossible, really.

Also, if you RTFM you'd know right away that foreach operates on a copy. And if all your complaints are because you want to use foreach() and you can't because it makes a copy first, then use a for() and stop whining. Babies are NOT dying.

don't get me wrong: I am not saying PHP is great. I am just saying that if you had the magic_quotes and the register_globals problem, is because you kept the default install. Ever since that setting was there, everybody I know set it to off when the default was on back in the 4.1 days or whatever.

If an user bothered learning how to properly install PHP instead of keeping the defaults like a moron, he'd have developed 10 lines of code and include them globally and never have the register_globals or magic_quotes problem again.
Anonymous said…
sorry, forgot one thing: I didn't mean to flame the post nor anything, I am just saying those reasons are not valid enough to say that PHP sucks.

Yes, I think it sucks, but those are not the reasons.
Anonymous said…
I've developed in PHP for about 5 years, on a number of hobbyist sites and several commercial sites. I tend to agree that the issues brought up in the post, but disagree with the apparent conclusion -- that PHP should be consigned to "teh suck" bin and used only by newbies. It has its advantages: huge libraries / open modules, the flip side of the poor orthogonality is a veritable everything-and-the-kitchen-sink feature set, the syntax hits a right point between the familiarity of C-derived stuff and flexibility of Perl (and avoiding, for the most part, the WTF? moments of Perl), large support community, choice of development styles. It's comfortable. Though I also see the appeal of Python, or Ruby.

The better title would have been "What Sucks About PHP." See Mark-Jason Dominus' "Why I Hate Advocacy" for hints.
Anonymous said…
The magic quotes and register globals issue is old, old, old.. And if your going to be naive about the particulars of a language then things are going to break aren't they..?

Im really fed up with peoples problems with PHP. Ive been programming for 20 years (C/C++) on Windows (flame, yawn), I have used Perl, which I quite like but it has its problems, elitism being a big one, ASP and PHP. I dont get on with Java, my preference.

PHP is good for web sites, thats what it is for. Yes, a lot of new programmers start off with it, it is easy to pick up. yes it is still maturing, and yes it will evolve and change.

Don't get me wrong, i DONT use it for everything, i use it when it suits the the job in hand.

How long are people going to bring up old issues? Is it that people are scared of the ease of use of this language and the influx of programmers it is bringing in? if it sucks so much you have nothing to worry about.

paul dot simmonds at gmail dot com
Anonymous said…
before this all becomes another flamed egos-war, I just want to tell you that you should have spent a little more time developing php before start complaining about it. There's so many things you can easily do with php that these pure beginner problems mean nothing
Anonymous said…
php is absolutely fine. the choice of making it good and solid, or leaving it to feel like you're hacking in stuff rather than coding nice and clean, is entirely up to you. you can grab all of your programming concepts knowledge and apply it successfully in php to a good extent. it's practical, rapid to develop, and if you do it right, you can just leave it there and it will run without stopping. you can slag off just about any platform out there.
Anonymous said…
The problem I have with PHP that I can't work out how to fix is typos in variable names. If I type $choice one time, and $chioce the second time, but I wanted them to be the same variable, how can I get PHP to tell me about this?
Anonymous said…
I agree with much of what you've said, although I must take issue with one thing. You complain (justifiably) about cruft-by-accretion. How do you deal with that? You drop it in a major version hop. Which is what they did with the jump to PHP5 - threw out their brain-dead object model and brought in a better one. So I don't agree with your complaints against that move. -- Jon Dowland
Jonathan Ellis said…
My point was that with only a little thought in the early days, major breakage in PHP5 wouldn't have been necessary. (And even so they left some of the fundamental flaws alone.)
Anonymous said…
With regards to your comment of "I don't have any problems working around PHP's limitations so you must be wrong," Mr. Ellis, I must respectfully disagree. At least as regards the workarounds (not the fundamental design decisions of PHP's implementation itself, such as the argument over arrays versus hash tables), I would never consider something like avoiding register_globals or magic quotes or references to $this to be "flaws" in the language. I would consider them quirks. Indeed, some of these are pure syntactical issues, and nothing more than a matter of taste! While it may be tempting to initially respond that this is merely a matter of semantics, I find it not to be the case. A flaw is a fundamental problem with a language; other arguments in this thread may count as flaws, but none of those for which workarounds have been presented are flaws to my mind at all. They are features of the language that must be taken into account, when worrying about portability, just like C++'s nonstandard data types must be taken into account. In C++, you can never know the size of an integer or a long when writing (portable) code; it always must be discovered at runtime, since C++ sets no standard data sizes, only required minimum storage sizes. Yet C++ is a highly portable language, within its purview; if set data type sizes had been built in from the beginning, we'd never have pointers of 64 bits, after all; they'd be sixteen or smaller! Nonetheless, assuming that an "unsigned char" is one byte makes for hypothetically unportable code, though in reality this will always be fine, since it is such an established convention that no compiler writer would ever alter the size of the char data type nowadays. Bah, my mind wanders again. Anyway, the quirks mentioned are akin to, say, Visual Basic's automatic 1-based array indexing feature; it could be forced to index arrays at 0 with the "Option Base 0" directive, but this provided portability problems. Regardless, Visual Basic 6 was virtually the best language out there for what it was meant to do: rapidly develop business applications, whether simple or complex, where efficiency of execution time was not a major consideration; only morons would try to build applications in VB 6 which were computationally intensive, but to build a simple program for your secretary to track appointments or the like, no other language could compete.
I think what you have here is a similar idea of PHP as many had about VB 6; the superficial design quirks and flaws are blinding you to the power of the language, when applied in the right arena. When people tried to write huge, complicated, data-intensive systems in VB 6, they found it to be woefully inadequate; this should have been obvious at the outset! A language for which a function to add two numbers equates to 42 machine instructions is not designed for that, whereas C++ (with about six to twelve machine instructions, depending on architecture) most certainly is, as long as you know what you're doing. Similarly, array efficiency is only important if my PHP site is geting millions of hits a day, and if that were the case I would either stick with PHP but design a multi-tiered and distributed web-serving and data-management system, or write a C-based CGI application using some off-the-shelf CGI libraries to simplify my life. (The former is, incidentally, not as hard as you'd suspect, really; many large web businesses are somehow married to the fact that a $500,000 server will solve their latency problems, when a trivial array of a dozen or so older web servers would do the trick for less than three thousand dollars in hardware costs and setup; a distributed network of antiquated Sun Microsystems SPARC Ultra 1s, with clock speeds of 350 MHz (keep in mind they are RISC) will do amazing things, let me tell you, and they run about $50 apiece on eBay these days.) Well, I guess the point of all this rambling is this: end results are all that matter; I would rather have an efficient system in terms of time and money than an elegant one, and PHP is very fast to develop in (saving development and code maintenance costs) and is not significantly less efficient than other languages in time or space, when deployed in a reasonable manner and with a backend data architecture designed well. What irks me about the astonishing desire to make everything elegant, as opposed to quick to write or powerful, is the end result; you get encapsulation of data objects like in the .NET architecture. If I create some highly abstract "data connection" between half a dozen foreign key relationship fields in a database, and then the system gives me my dataset, I can guarantee that the SQL it generates will be hortribly unoptimized for any nontrivial query. If, instead, I use the simple DataReader class .NET provides, and supply my own SQL, I have an application whose SQL is harder to port, but which will run hundreds of times faster, making hardware costs minimal and latency very short. Encapsulation and other clean degisn principles are usually good, but I detest them when they make their way into the cores of complicated systems, since they are rarely ever efficient when applied to their logical conclusions. Considering the powerful refactoring tools available today, there is no excuse for writing methods to get and set variables inside classes that are private to other classes anyway, but are used in time-criticalm subsystems . . . if you REALLY must have encapsulated methods, refactor them in later. A good IDE can do it in a quarter second. I suppose, though, that refactoring applies less to PHP, since its object-oriented model is not very full-fledged in the first place, and since I am not aware of any good refactoring systems for the language. Nonetheless, the basic point remains valid; when you are worried about efficiency, use efficient language constructs (and to Hell with fluffy software engineering practices when time is really critical; the rest of the program can be software-engineered to your heart's content) and languages, or compensate in good hardware design (which is NOT the same as expensive hardware).
I do apologize for my rambling, but yesterday was my six-month anniversary, and so it was a late night out celebrating. Also, I should get an account here; these anonymous posts are confusing to follow clearly. Adieu!
Anonymous said…
One other thing, though; the idea that changing the php.ini settings is a valid way to overcome the portability problems of magic_quotes and register_globals and the like is astonishingly wrong. The original poster had the right idea about these as portability issues of some consequence, since not everyone hosts their own servers, and therefore not everyone has access to the initialization files and directive. It is best, if you are truly mindful of portability, to encapsulate these features out by simple functions (see? I'm not a total anti-encapsulation Nazi :-) ), or to presume they are always off in some cases where being on provides extra functionality, not different functionality from when they are off. While I maintain that these checks are not a fundamental problem, or even anything a programmer should be overly concerned about since a function call takes three seconds to type (and would be necessary anyway when dealing with escaping database field data; see my first (long) post about PHP in the radio station), the fact that you can "edit the options yourself" is not a valid solution to portability. On this, myself and the original poster certainly agree.
Anonymous said…
I've posted a response to your rant elsewhere:
http://www.daholygoat.com/jaws/html/index.php?gadget=Blog&action=SingleView&id=8
Anonymous said…
I find your entire article rather ignorant and somewhat school-girlish. How can you possibly be even remotely qualified to give any kind of adequate opinion on something you piddled with for a few days.

I've been developing using PHP as my primary language for over 6 years. I would totally agree that there are some annoying issues with it (as with all languages) and that the majority of the code I see out there makes me sick. However, like all languages, you need to use it for some time, get used to it's little nuances and expectations. And of course you need to adapt to new ways of doing things that you used to do in other languages. Some thing are easier, some are more difficult.

PHP, more that the other languages I've used, has been extremely flexible and has allowed me to be creative while allowing me to create very robust and complex systems.

Bottom line: An idiot is going to write idiot code regardless of what language he's using.
Anonymous said…
Hey Ellis, it could also mean that you are inexperienced and see a problem where there isn't one, or that you are overrating a design annoyance.


All languages have design flaws/annoyances somewhere along the road. Some people can see more contingencies ahead and do a system design that contemplates them, and others just complain about magic quotes in their pajamas while having chocolate icecream.

To me, when someone says "language X sucks" is a sign that they are language Y advocates, and discussions like that often lead nowhere.

Popular posts from this blog

Why schema definition belongs in the database

Earlier, I wrote about how ORM developers shouldn't try to re-invent SQL . It doesn't need to be done, and you're not likely to end up with an actual improvement. SQL may be designed by committee, but it's also been refined from thousands if not millions of man-years of database experience. The same applies to DDL. (Data Definition Langage -- the part of the SQL standard that deals with CREATE and ALTER.) Unfortunately, a number of Python ORMs are trying to replace DDL with a homegrown Python API. This is a Bad Thing. There are at least four reasons why: Standards compliance Completeness Maintainability Beauty Standards compliance SQL DDL is a standard. That means if you want something more sophisticated than Emacs, you can choose any of half a dozen modeling tools like ERwin or ER/Studio to generate and edit your DDL. The Python data definition APIs, by contrast, aren't even compatibile with other Python tools. You can't take a table definition

Python at Mozy.com

At my day job, I write code for a company called Berkeley Data Systems. (They found me through this blog, actually. It's been a good place to work.) Our first product is free online backup at mozy.com . Our second beta release was yesterday; the obvious problems have been fixed, so I feel reasonably good about blogging about it. Our back end, which is the most algorithmically complex part -- as opposed to fighting-Microsoft-APIs complex, as we have to in our desktop client -- is 90% in python with one C extension for speed. We (well, they, since I wasn't at the company at that point) initially chose Python for speed of development, and it's definitely fulfilled that expectation. (It's also lived up to its reputation for readability, in that the Python code has had 3 different developers -- in serial -- with very quick ramp-ups in each case. Python's succinctness and and one-obvious-way-to-do-it philosophy played a big part in this.) If you try it out, pleas

A review of 6 Python IDEs

(March 2006: you may also be interested the updated review I did for PyCon -- http://spyced.blogspot.com/2006/02/pycon-python-ide-review.html .) For September's meeting, the Utah Python User Group hosted an IDE shootout. 5 presenters reviewed 6 IDEs: PyDev 0.9.8.1 Eric3 3.7.1 Boa Constructor 0.4.4 BlackAdder 1.1 Komodo 3.1 Wing IDE 2.0.3 (The windows version was tested for all but Eric3, which was tested on Linux. Eric3 is based on Qt, which basically means you can't run it on Windows unless you've shelled out $$$ for a commerical Qt license, since there is no GPL version of Qt for Windows. Yes, there's Qt Free , but that's not exactly production-ready software.) Perhaps the most notable IDEs not included are SPE and DrPython. Alas, nobody had time to review these, but if you're looking for a free IDE perhaps you should include these in your search, because PyDev was the only one of the 3 free ones that we'd consider using. And if you aren