I Like PHP
beust.com
beust.com
And this is why everybody else hates PHP. It tempts you to write bad code, and so most people working in the language end up doing so. I have to periodically stop myself when I'm writing PHP and make sure I'm not falling into bad habits. It's possible to write good code in PHP, and I know some people who do, but the pull to write sphpghetti is too strong for most. And there is no real corresponding benefit (aside from "noobs who don't care about code quality can still write programs") arising from the design choices that cause this.
I've done a little C and Java web stuff where my code printed HTML output - ugly. CFML and PHP mingle HTML and code together - also ugly, but better. I can't fathom any way NOT to mix them but would love to have some resources to see what I'm missing. I know there needs to be something better. Thanks.
Feels like you have to know Symfony 1 to understand what 2 is trying to do really. I wouldn't recommend it as a good intro to MVC.
I prefer Kohana + Mustache (KOStache is the module). Mustache is a logic-less templating language available in many languages. Kohana is my PHP MVC framework for choice.
http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC...
That said, there is a long-standing tension between keeping logic out of templates, and giving templates more flexibility. Different frameworks take different positions on how to draw the line. PHP can be seen as an extreme position towards giving templates as much power as possible.
Considering PHP is more-or-less designed to be a templating language, I'd say it is. Partly.
On the other hand, PHP is a pretty good templating language. People should just learn to separate business logic from presentation logic.
That wasn't how the language was originally intended to be written, and that is not how hordes of people use it. But it can be done. Really.
This is very different from other languages such as ruby where templating uses the ERB module, which is a subset of the ruby language.
UPDATE: Here's a stackoverflow link with a zillion more examples and resources about this: http://stackoverflow.com/questions/62617
- Designers and developers will have a hard time working on the same file, especially the designers who don’t necessarily understand the templating rules language, and can easily break the whole thing when trying to modify the file.
- Also, when provided with a new version of the template text (say, a new version of the HTML from the designers), it’ll be hard to incorporate the modifications into the original template with all the template rules scattered inside it.
Regarding how to generate dynamic markup and not mixing the markup with templating logic, I'll cite approaches like Apache Wicket [2] (although you still need to add a couple of attributes to the markup) and server-side jQuery like select and transform templating, such as what is done in Enlive [3] and Moulder [4] (a pet project of mine)
[1] http://jawher.net/2011/01/06/on-templating-and-a-shameless-p...
[2] http://wicket.apache.org/learn/examples/helloworld.html
-accepts uncritically gobs of code dredged up via Google
-considers something "robust" if it doesn't break old code, when the rest of us hate it because we have to live with register_globals and other horrors
-considers "universal support" of craptastic versions of mod_php to be a good thing (some, but not all, major shared hosting messes use FastCGI)
-modifies files in production and thinks that's okay
It makes those of us who do know what we're doing and focus on disciplined code look bad, because the article author is what most people think of when talking about "PHP programmers".
In fact, i reject any other explaination. Sticks fingers in ears. Lalalalala, it's satire, nobody is this incompetent. Lalalalala, can't hear you.
This is absolutely satire. I don't think anyone can troll much harder than "PHP is exactly like C".
I'm not sure why running old code on an old server that has support for the old code is considered a good thing about PHP. I love BASIC because I can boot up a C64 and the code I wrote 20 years ago still works today!
What's wrong with that? `git pull` to update everything to the latest HEAD, `git co -- HEAD~1` to roll back the latest update, `git diff` to see the latest differences, etc...
This repo doesn't have to be the development repo, just a specialized non-bare repo that's used just for production. It works great for simple sites that don't require extensive deployment infrastructure.
So, yeah. ;-) Still a ways off, though.
Agreed - as a PHP programmer (mainly in Zend Framework), who is now learning Python... I hate register_globals. With a fiery passion.
More importantly, as someone who hosts several photographer websites, I have a bone to pick with http://bludomain.com/ - congrats on your eighth birthday. Have you updated your code since you were born? It's a travesty that involves turning on almost every deprecated option in a php.ini. :\
Cedric wrote the book on unit testing (literally! [1]). He uses PHP at times when he doesn't need the reliability unit testing gives you and can't justify the extra time it takes.
Given that he works at Google, I suspect his "in production" doesn't actually mean big, real sites.
And I don't care if it's a "big, real" site or not, making mods to a live site is (almost) never good practice. Fix it offline, test it, push.
You've got to keep in mind what PHP (currently) stands for: "PHP: Hypertext Preprocessor". Use it for that, and it's great, but try to make it do more and you run into trouble. IMO, PHP should be used in precisely those situations where nobody gives a shit if the code you write is any good or not, and by my reading, this was a valid point in the article.
The way I like to think of it, PHP is like Bash scripting for the web: an indispensable tool that's supported almost everywhere, useful for a quick and dirty (and sure, ugly) drop-in solution, but not a language you should "seriously develop" in. Once a project is complex enough that you need to think about how to organize your PHP files (esp. if it's real back-end PHP, not just HTML pages with functions) or manage dependencies and build processes, you've probably crossed a line and should be considering other solutions.
But on the other side of the coin, you shouldn't be thinking "Rails app" every time you need to add a hit counter and a "current time" display to a static web page, I don't care how much nicer code comes out in Ruby than PHP (and I love Ruby in comparison to PHP)...I'm getting the sense that many people here (nothing that you said, chc, indicates that, but many other comments on this thread seem to) would do exactly that, though, which is disturbing.
This might be an unpopular opinion, but I truly believe that once in a while hastily flung together spaghetti code is exactly what's called for in certain situations, and PHP excels at making that very easy to whip together and push out the door.
And this, right here, is how you end up with some godawful clusterfuck of unmaintainable, throwaway spaghetti code that has become some poor fool's nightmare in a couple years. If it's worth writing, it's worth writing well. Otherwise, don't even fucking bother. Maybe this is what separates C from PHP. When Ritchie was creating C, do you think he had any idea it was going to be running the world's infrastructure in 20 years? Do you think he ever wanted to just hack it up real quick with some spaghetti code to get it working for his boss's current project? Sure he did, but instead he did the right thing. I can't imagine that Rasmus Lerdorf had more pressing concerns than the guys that were building the Unix operating system, and yet he decided it would be ok to take all kinds of shortcuts and hacky workarounds and poorly thought out design decisions when he was writing PHP. All of which have somehow permeated the language to such a point that you now have people actually defending bad code and critiquing the use of frameworks and admittedly "nicer" code!
> ...thinking "Rails app" every time you need to add a hit counter and a "current time" display ... I don't care how much nicer code comes out in Ruby than PHP ...I'm getting the sense that many people here ... would do exactly that... which is disturbing.
See, I don't find that disturbing at all. I find it reassuring. The two "simple" examples you give are a hit counter and current time. Sure, it's easy to write some PHP to increment a counter every time a page request is made. But what if it was hit from the same IP twice? And wouldn't you really like to know how long they stayed, and which links they clicked? Or maybe what country were they from and what page referred them? Hmm, maybe you shouldn't be writing a hit counter from scratch after all. At least displaying the time should be pretty simple. But wait, what if the user is in a different time zone? Did you account for daylight savings? What if the user wants a 12 hour clock instead of 24? Oh well, just hack something together real quick and I'm sure there will be plenty of time to fix it later on...
No one bashes PHP because it can't do these things, or that it isn't easy. People bash PHP because there are objectively better languages and platforms out there and objectively bad decisions made by those guiding the PHP language.
If you want to defend PHP in any meaningful way then you can't just list things that can be done easily in almost every semi-modern web ecosystem, but actually compare it to the other alternatives and identify when it's the right choice. It's harder but it leads to a blog post that might actually benefit readers.
Did you ever read Python's documentation? Or Ruby's? Or Java's?
Show me one popular web programming language which has a full page, up to date, with examples and user comments and version incompatibility info, per function.
Of course, it's just one point and I otherwise agree with your comment, but it's one hell of an advantage.
Also, I never used a popular Python library for which I haven't found good resources.
My favorite Python library, called NLTK, which has no equivalent in PHP or Ruby or any other platform for that matter, comes with a freaking book that's available for free.
http://twistedmatrix.com/documents/current/api/twisted.html
http://twistedmatrix.com/documents/current/core/howto/index....
http://twistedmatrix.com/trac/wiki/Documentation
It's not as comprehensive and shiny as the core Python docs, but along with the tutorials and examples, it's actually pretty decent.
The one thing I miss in Python is the inability to click "view source" in my web browser to see how a core Python library is implemented. PHP also has this problem. (Code is the best documentation. Learn to read it.)
The only thing I wish they had was a way to pipe it through a highlighter like perltidy with html out. That'd probably just lead to holy wars on formatting/colours though.
For eg. https://metacpan.org/source/DRAEGTUN/Builder-0.05/lib/Builde...
[0] http://rtfd.org
Hmm, that said, that's still exactly what I find on the official Python site (e.g. http://docs.python.org/library/stdtypes.html#string-methods - PHP beats this by lightyears with a single page with examples and comments per function). Which 3rd party thing should I be looking for? (genuinely interested btw - the docs is one thing i dislike about python, and maybe unrightfully so, apparently)
1. Please explain why you need more explanation of these very basic functions
2. PHP's doc comments are unadulterated garbage
3. When things are worth documenting, they are: http://docs.python.org/py3k/library/collections.html
4. if you truly think string methods are insufficiently documented, it is very easy to contribute to the documentation.
The REASON PHP needs a page per function is the sheer number of poorly handled edge cases, version incompatibilities, and gotchas.
I can't speak for Ruby or Java because I haven't even looked at their documentation sites.
User comments? PHP user comments are crap, IMHO - so many people writing so much horrible code in those comments.
I understand where a lot of PHP supporters are coming from because I was once there - I spent four years with the language and thought it was the most beautiful thing that existed. Until Python, Scheme, Erlang, and Haskell invaded my life.
PHP will always be an amateur programming language - which is it's strength, kind of like BASIC, a great stepping stone but nothing more.
1. Python doc has full up to date documentation for everything shipped with the standard library (which dwarfs PHPs grab bag of globally scoped functions)
2. The comments in PHP documentation are frequently out of date, misleading, or flat out wrong. Among the people I work with (who are working on PHP web apps, full time) everybody routinely advises the PHP noobs to ignore the comments.
3. The standard library functions shipped with most languages don't require a full page with multiple examples to explain how they work.
Don't get me wrong, the documentation for PHP is excellent, but it's a small win for a language that has so many real --language level-- issues.
Yes. it's rather fucking good.
> Show me one popular web programming language which has a full page, up to date, with examples and user comments and version incompatibility info, per function.
Have you ever read Python's documentation? In the last ten years?
Python's docs have a complete and readable description of the language[0] including its data model and the various core protocols[1], it has a number of quality howtos and guides[2] a complete documentation of how to use C-level APIs[3][4], a pretty good and complete tutorial for beginners[5], a complete, well written and exhaustive changelog with examples[6] drilling down to C API changes[7] and most stdlib modules are extensively documented with examples and links to to the actual source code for the module[8] and versioning information[9], with the whole documentation being heavily hyperlinked and permalinked (every section, subsectio, sub-sub-section, class, method, function or constant getting its very own anchor) linking to its own source[10]. And just in case you want to contribute, or even just want the documentation offline, it's included in the source tree and trivially compiled to not only an HTML version, but a PDF (via latex), plain text or EPUB one as well[11]. Hell, the documentation is so extensive there's even documentation on documenting[12].
Oh, and the documentation is available for every single version of Python past, present or future (for which it could be found anyway, as far as older versions of the language are concerned), including bugfix releases[13]. And then it goes the extra mile by letting you run examples to ensure nobody broke them[14].
As to "full page per function", I really don't think you need that. And the PHP doc comments are closer to youtube comments than to anything worth reading, I simply can not see them as anything but liabilities.
[0] http://docs.python.org/py3k/reference/index.html
[1] http://docs.python.org/py3k/reference/datamodel.html
[2] http://docs.python.org/py3k/howto/index.html
[3] http://docs.python.org/py3k/c-api/index.html
[4] http://docs.python.org/py3k/extending/index.html
[5] http://docs.python.org/py3k/tutorial/index.html
[6] http://docs.python.org/py3k/whatsnew/3.2.html
[7] http://docs.python.org/py3k/whatsnew/3.2.html#build-and-c-ap...
[8] http://docs.python.org/py3k/library/collections.html]
[9] http://docs.python.org/py3k/library/collections.html#collect...
[10] http://docs.python.org/py3k/_sources/library/heapq.txt
[11] http://hg.python.org/cpython-fullhistory/file/tip/Doc
[12] http://docs.python.org/documenting/index.html
[13] http://www.python.org/doc/versions/
[14] http://sphinx.pocoo.org/ext/doctest.html
(the lack of markup in HN comments is getting seriously annoying)
>>> print abs.__doc__
abs(number) -> number
Return the absolute value of the argument.
>>> print xrange.__doc__
xrange([start,] stop[, step]) -> xrange object
Like range(), but instead of returning a list, returns an object that
generates the numbers in the range on demand. For looping, this is
slightly faster than range() and more memory efficient. > pydoc unittest
Help on module unittest:
NAME
unittest
FILE
/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/unittest.py
MODULE DOCS
http://docs.python.org/library/unittest
DESCRIPTION
Python unit testing framework, based on Erich Gamma's JUnit and Kent Beck's
Smalltalk testing framework.
This module contains the core framework classes that form the basis of
specific test cases and suites (TestCase, TestSuite etc.), and also a
text-based utility class for running the tests and reporting the results
(TextTestRunner).
[snip] In [1]: abs?
Type: builtin_function_or_method
Base Class: <type 'builtin_function_or_method'>
String Form: <built-in function abs>
Namespace: Python builtin
Docstring:
abs(number) -> number
Return the absolute value of the argument. In [1]: import json
In [2]: json.dumps??
Type: function
Base Class: <type 'function'>
String Form:<function dumps at 0x101f0bc08>
Namespace: Interactive
File: /usr/local/Cellar/python/2.7.2/lib/python2.7/json/__init__.py
Definition: json.dumps(obj, skipkeys=False, ensure_ascii=True, check_circular=True, allow_nan=True, cls=None, indent=None, separators=None, encoding='utf-8', default=None, **kw)
Source:
def dumps(obj, skipkeys=False, ensure_ascii=True, check_circular=True,
allow_nan=True, cls=None, indent=None, separators=None,
encoding='utf-8', default=None, **kw):
""" [snip (excellent) docstring] """
# cached encoder
if (not skipkeys and ensure_ascii and
check_circular and allow_nan and
cls is None and indent is None and separators is None and
encoding == 'utf-8' and default is None and not kw):
return _default_encoder.encode(obj)
#snip rest of funcHa-ha-ha. You're kidding, right?
Check strlen: http://www.php.net/manual/en/function.strlen.php
Comments:
1. Comment about how PHP converts types. "Conclusion: The values are converted to string before check the lenght."
2. Comment from a novice user who posted a solution to the problem of subtracting the number of spaces in string from its length.
3. Comment about someone who thought that there was a bug in strlen, but it actually was a documented difference in behavior between two minor versions of PHP.
4. Comment about counting characters in UTF-8 encoded string by decoding it to some other one-byte encoding.
5. Comment about counting characters in UTF-8. Actually, the whole new function.
6. Reminder that \r\n are actually two bytes! "If I had thought of this starting out, I would have saved myself several hours of trouble trying to get php to cut a message to the same length that my auxiliary javascript validation imposed on it."
7. Benchmarks for different UTF-8 strlen implementations.
8. Complaint about another comment, which suggested the function to count characters in UTF-8 strings that didn't work. And the "proper" solution using regular expressions.
...
For example: http://msdn.microsoft.com/en-us/library/w4hkze5k.aspx
or
http://msdn.microsoft.com/en-us/library/system.object.member...
You get the syntax (including VB, C++, and F# where availalbe), remarks, examples, version information, platforms, comments, and related content.
I mean, just look at that first URL!
Depends entirely on your metric. It's far too easy to introduce subtle bugs, especially security oriented ones, in PHP. If I had a dollar for every XSS, remote file inclusion, CSRF, arbitrary file read, etc vulnerability I found in a "good" PHP app, I'd be a very wealthy man. Some things are mitigated by using a good framework, but in most cases people get them horribly, horribly wrong.
While testing apps, PHP immediately throws up red flags -- it's simply not likely to be done right. It can be, but it's very rare.
One very illustrative example: arbitrary code execution. I've lost count of the number of arbitrary code execution vulnerabilities I've found in PHP applications. In contrast, I recall very vividly the last arbitrary code execution vulnerability I found in a Python application: I uploaded a PHP script to the server, which was also running mod_php. ;-)
The problem here is simple: most web servers that run PHP are configured with a rule that says "If a file ends in .php, execute it as PHP." This is useful for new users: it allows them to run and execute separate PHP scripts very easily. But it's also a potential security vulnerability if an attacker can upload a PHP file to your server.
If you're using a framework, you typically have a fixed number of scripts that should be executable and you can configure your web server appropriately. However, that requires a VPS or dedicated server.
Edit: If you're interested in an actual language-level difference between PHP and Ruby/Python that affects security, PHP scripts accepted null bytes as part of filesystem paths until recently (PHP 5.3.4, which added protection against it, was released at the end of 2010).
Rails is a DSL based on Ruby to build web applications that has hooks into a rich library that helps with that. PHP is a language designed to build web applications (although it can be abused to write any type of application)
Thus, in your career you tend see more PHP apps that were badly-implemented.
But by now I am mature enough to understand that if you hire bad programmers you get bad code irrespective of the language its written in. You can use any tool you want, if you use it badly the result is going to be bad. These are days of Python and Ruby fanboyism so very obviously everything is going to look ugly in front of it. Code bases in other languages will be declared legacy and the same thing will be translated to the new shiny language and called the 'modernized' code bases. Your RDBMS use cases will be shoe horned to NoSQL databases and declared designed for the web. This will go on and on for anther few years...
Until we get to see page long blog posts another few years from now describing how many bad Python + Django examples can be found on the net. Or how bad Python and Ruby Legacy codebases are. How framework dependency with Django, Rails or Twisted sucks. Or how someone had to spend huge engineering effort migrating from Python 2 series to 3 series. Or how they had to rewrite a large part of SQL logic to work with NoSQL databases.
This trend repeats every few years, every few years a set of tools get trolled badly.
Now which languages make it easier to write more good code? Everyone talks about the lack of good PHP code and the response is "well there's plenty of bad python code out there!". What we will never see are any examples of PHP code held up as being great a few years from now.
Yes, every few years a set of tools get trolled badly. The same tools that were considered sub par by professionals at the time.
* C is fast and has tight resource control
* C is portable
* C has a transitive (==) operator
...
I love his other points about PHP (as I too like PHP), but I felt this was one of those bold statements that was a little sensational and attention grabbing at best. I too find it pretty far fetched.
Like Facebook? Or Wordpress? Or Digg?
PHP aint perfect, but it's demonstrably suitable for medium to large projects.
There's not a single other company in the world (sans probably Google) that has to deal with performance problems on that level of scale. At that point, I can't imagine anything surviving out-of-the-box. Something has to give, even the language they're using (they're using a subset of PHP that they can run through a custom compiler to C++ machine code, to squeeze every possible CPU cycle out of the servers they have).
http://www.computerhistory.org/collections/accession/1026307...
[1] https://github.com/facebook/lex-pass [2] http://www.vimeo.com/6699769
There's not necessarily any connection between developing external Facebook applications and working on Facebook code itself.
By far the part of PHP that shines for small projects and causes havoc in large is the way includes work. It's possible to be disciplined about this, but it's not common. I remember many times searching in vain for some function or another that was included somewhere, somehow. Sometimes even in code that I wrote entirely!
Facebook and Wordpress and Digg being in PHP isn't a decision that was made with a large architecture in mind, it was done because the people who wrote those projects knew PHP (And in Wordpress's case, because the people who use it need it in PHP).
I'll have the same problem in Java. I'll need to find out where I implemented some logic, and have to start digging through classes and following my own breadcrumbs until I find it sometimes.
Just because I commented my code poorly, or put logic in the wrong place isn't the fault of Java, it's my own, and the languages, Java and PHP, in my opinion, are easy and fun to work with for the most part.
File A includes File B includes File C includes File A by about 10000 files.
It was for a very scary trying to change a core library during this time because it was almost impossible to figure out where all it was included and impossible to test all the code that touched it. Additionally, we were basically loading up our entire init stack on every page load and async request because as soon as you loaded up one file all the circular dependencies would load up the entire stack. This had a big performance overhead prior to our switch to HipHop.
To this end we developed a new include system for library files that forces developers to be sane. Every module in the our library files must explicitly include everything that they need and it forbids circular dependencies. If module A requires module B, module B cannot require module A.
Making this change took a long time (in some places we are still untangling the code), but our core code is now infinitely more manageable and most importantly testable.
Do you have a static analyzer or something like it that enforces the no-circular-dependencies rule, or is it just a procedural thing?
http://phabricator.org/ has a very similar system if you are curious. epriestley made some nice updates to it in there as well.
Where's the "Wordpress" of any other programming language?
As examples I hold up PHP, most PHP applications, MySQL, Matt Wright's script archives (a series of security holes masquerading as useful Perl scripts that were popular a decade ago), and so on.
The correlation is hardly absolute. For instance SQLite is both excellently well designed and also designed for easy install. However it holds often enough to strain coincidence.
My suspicion is that part of it is that something that is designed to be trivial to use tends to have a low barrier to entry to get involved with. This leads to getting contributers with more enthusiasm than skill.
http://flow3.typo3.org/download/ This is still in alpha but has good source code regardless.
I'll take that bet.
Unless you're doing very CPU intensive computations where every millisecond counts, the difference between most languages won't be that great in the big picture.
In all the bad ways, and none of the good ones.
If you wanted to connect to a MySQL, you have to do it all by yourself, you need to create a database, tables, PKs, connect to database, execute RAW mysql queries, and so on. Form validation ? Yeah right. Back then the include_once() or require() were amazing for separating code. But all in all that mades us learn how things work internally, how HTTP requests work, how SQL works, even why CSRF or XSS and SQL injections are executed.
Yes, the code was shitty, it was all over the place, but we learned how a web app works internally.
And yet, most developers I know who coded PHP back then are amazing developers today in any web language or framework. Why ?
Because most of them learned doing things the hard way. We had to understand how HTTP requests works, how SQL works, etc..etc.. because we didn't have the magic of rails, or any helper for any framework.
In these 12 years, web development as grown, a lot, and for the better, I'm currently learning Rails, and I've already done a project with Django and Node.JS . I liked them a lot and they are amazingly well done, I just wished PHP was more OO like ruby or python.
However, I laugh at these new Rail/Django developers that joke about PHP code. Most of them start coding jumping immediately into a framework. I bet that most of then couldn't create a simple MVC framework, ORM from scratch, hell, even a simple security CSRF would be a pain without "gem install <whatever>".
You see kids, PHP was like our first GF or our first car, where we tried stuff, made us cry (in a sense), and helped us grow and mature as developers, for those who wanted to grow that is. Now you have lots of languages for web dev, but back then PHP was the thing.
I still believe that PHP is a very cool language if done correctly, I wished tho, that it should be rewritten to be more OO.
But if one thing I learned from all of these years is that, it's the developer who makes quality code, not the language. Unless that is, you are using a framework who basically demands you to do things the way it wants, and puts a lot for magic so you don't bother with "boring" stuff. But in the end of the day it's not your code, it's theirs.
So my advice for new dev is, forget frameworks, and learn the hardcore way, then pickup a framework you love and go with it, either PHP, Ruby, Python or whatever.
The reason you and I and all the others like us put in so much effort in solving problems in PHP like CSRF, XSS and SQLI was because we were passionate enough to learn about that and then implement solutions for it.
Developers who don't care about security measures like that - they're the ones who store plaintext passwords, still - won't care either way, no matter if they're using Rails or PHP. Frameworks like Rails solves it for them, but if it weren't for Rails, their apps would have all these security problems, and they would only be addressed once disaster strikes.
Those that do care will be passionate about their work. They are the ones that read up on XSS and CSRF out of interest, not necessity. I'm sure they look at the generated HTML source once in a while, and then wonder why they add that token there. Using Rails, newbies are exposed to the solutions from the start, encouraging them to learn about it. As a PHP newbie, you're never exposed to the problem or the solution, until you start reading about security on your own or you get into trouble.
Spend time becoming a good programmer, and you'll be better off in the long run. If you don't want to spend that time, go find another profession...
I think this feature is definitely useful, but you can virtually do the same thing in other languages with templating engines.
When people criticise the PHP language I think they really miss the point: it is the PHP platform that is really powerful because of:
1. The shared nothing architecture (it really helps you scale).
2. The rapid development cycle.
3. The portability (Apache, IIS, nginx, persistent in-memory interpreters via PHP-FPM...).
4. The huge amount of native C extensions providing amazing functionality.
Sure the language has warts, but who cares when the platform is this powerful?
In the case of web applications all tend to scale equally well as you can just add another web server. Its the database that causes the scale issues.
With a lightweight PHP framework and a sensibly written app, you can stick to one machine for much longer than you can with Rails, and after that, it will require a fraction of the number of app servers. Beyond that, app processing time is generally much lower without all of that cruft, so you don't need to do as much caching, etc. to get a snappy webpage.
Don't get me wrong though, throwing a bigger hardware box at a problem is a totally viable solution to most problems, up-to a point.
tl;dr: Too many gotchyas for a beginner. I need discipline imposed on me when I'm learning, ymmv.
Doing a tested change and then a pushing to production is a 4 command overhead using git as lazily as possible with maybe an additional 5 minutes spent during initial project setup. You're doing the same coding work, you're just helping to ensure it's not going to create any completely useless work spent undoing mistakes. It's an ounce of prevention, pound of cure argument in my mind.
This all depends on what kind of site it is, of course, but in the context of what he's saying, it makes sense.
Still surprised I got voted down for that, since C and Java are still correct.
In fact, it's what I hated about Java web development the most... You had to compile, package, and deploy every time you made a tiny change. It was a nightmare.
The Play framework uses its own copy of the Eclipse compiler to compile everything on the fly while it is running in development mode...so as you as you save your changes, you can reload your browser and see them immediately.
What worries me about PHP is that innovative ideas don't appear to be coming from the PHP community. They come from Python, or Ruby, or Erlang, or Java projects and are copied by PHP developers afterwards. I worry there's a risk that PHP is being left behind as the developers who solve new and challenging problems turn to other languages.
Furthermore -- and this is just my sense of how things are where I live -- while it's possible (and not even difficult) to write quality PHP code, it seems to be difficult to find developers who care about quality. My manager complains about this constantly and I'm inclined to believe him since, when I was a freelance developer, I saw tons of PHP code that was simply and unambiguously terrible. Conversely, a developer who wants to write quality code in PHP has to look pretty hard to find a PHP shop that recognizes quality and values it. I suppose that these issues aren't tied to a particular language, but they seem more pronounced with PHP.
Most web apps are ultimately more like shell scripts or console applications than desktop/mobile applications. It's no coincidence that most of the former are written in C or C-like scripting languages, and most of the latter are written in OO languages running on .NET or Java. Your basic operations are "print some stuff", "read from a file or database" and various sorting, slicing and text-processing tasks inbetween, all of which are done well by PHP, Perl, C and so forth. ActiveRecord, TableDataGateway etc. are great patterns for data access, but sometimes mysql_query("SELECT foo FROM bar WHERE x = y") is just so much simpler that it becomes the better option.
The lack of OO makes PHP's documentation much more browseable, and makes code more readable in certain situations. If I look at your code and I see a function I don't know, I just google it. If I see a method invocation on an object, I need to figure out the type of the object (not easy in a dynamic language) and google the combination of class and method name, which often fails to return a result (has anyone ever managed to find anything useful in the Zend Framework docs?). PHP isn't the only data point for this argument - I think it's probably why Drupal handily beats ZF, Symfony etc. in terms of popularity, despite the superior OO architecture of the latter. You can google pretty much any API function and get an accurate result, which you just can't do with ZF (which lacks documentation at the method level, and what documentation that exists is buried in some Doxygen-based site which is made impervious to search by the use of frames). I'm also reminded of Linus's argument against OO in the Linux kernel - when you're all about the patch files, you need clear function names to understand what's going on without massive amounts of context. Drupal's rate of contributions probably exceeds that of other frameworks for similar reasons.
Of course, this bias against OO is also what makes PHP a bad choice for certain things, and this is why plenty of devs hate it. I honestly don't know if, in the final analysis, this makes PHP a good or bad choice. It probably depends too much on the problem you're trying to solve for there to be a simple answer.
For those who can't ride a bicycle, tricycles are great.
Once you understand how to use a framework/language like RoR, I don't see how PHP is more useful (unless you have size constraints). ActiveRecord::Base.connection.execute("SELECT foo from bar where x = y") is just as simple as mysql_query("SELECT foo FROM bar WHERE x = y"), and you get the benefit of abstracting away the database in database.yml so you can run it in different environments.
x.length vs strlen($x)
x.gsub('foo', 'bar') vs str_replace('foo', 'bar', $x)
x.strip vs trim($x)
x.upcase vs strtoupper($x)
All four of the PHP functions use a different form: strX, str_X, X, and strtoX. Some of this could be solved with consistent function names, like always using str_X, but then that makes me wonder why one wouldn't just want to have all string functions available as object-oriented methods on strings. Python takes a different tactic, and has a non-object-oriented len() method, but this isn't just used to get the length of a string, it will also get you the length of a list, tuple, or dictionary.
Python takes a different tactic, and has a
non-object-oriented len() method
In Python len() is just a standard protocol for getting the length of something, but len() itself is calling obj.__len__() if it is defined. You can even override or replace it in an object instance, returning whatever you want.
You can argue that these protocols are a bad idea, or maybe a useless one since Ruby does just fine without such hardcoded conventions, but since it relies on runtime adhoc polymorphism, it is as object oriented as it gets.
I guess this is another example of why using the term "object-oriented" at all can be unhelpful, as it may mean so many different things to different people depending on the particular situation.
The attraction of PHP is that it never tells you that you're writing code that doesn't work. The result is a lot of code that doesn't work. This is bad, not good.
Any editor worth its salt can manipulate a cross-reference of the project's symbols. Learning how to do this has saved me days of time figuring out OO-heavy projects. I prefer ctags(1) and Vim.
> But just like C, PHP is lousy for the medium to large. Any software project with a duration in months or greater that is entirely in PHP is going to be painful.
Yeah, C is terrible for medium to large projects like, say, Linux.
Explains it. PHP is fine if you jump in, write a few lines, and then don't ever have to maintain it yourself. Woe to the guy who does have to maintain it.
I would never use PHP for anything big/complex, my post was mostly in response to the universal sneering and mocking that PHP always gets. I think it's unjustified.
Since I only modify my web sites a few times a year, I am pretty sure that I would be much more reluctant making these modifications on a RoR app than a PHP one.
It definitely is deeply flawed for many reasons, which is why I'm still looking for my "white unicorn" language: one with a C-like syntax, no fancy templating or ORM magic (just let me print() html), foss, easy to deploy, and with an established community and searchable "recipes" online.
Lots of languages fit some of those criteria, but I haven't found one that fits them all.
ASP.NET MVC, which came out 2 years ago, is much closer to RoR and other similar frameworks, and is a better abstraction in my opinion.
I wouldn't write this kind of Perl, but Perl is not going to get in your way. "use CGI; print html(body(p("OH HAI")))".
When you realize that this sucks and you can't maintain it, you'll be able to gradually improve your code. First, you can run your CGI from Plack instead of Apache. Then, you can start using features from a Plack-based framework, like URL mapping. Next, you can move your "print this HTML" into template classes. Then, you can convert these to using TT (or similar), and your app code won't notice. You can start writing unit tests. You can gradually migrate your raw DBI calls to DBIx::Class by using $schema->dbh_do.
You won't have to do it all at once and you won't have to break any code when you do. Perl will grow as you do. Or, you can stick to CGI forever. It doesn't care :)
It's a great language for starting small and building up "complexity" as you learn more about programming.
"Sometimes, I don’t even bother editing the files locally and then transferring them: I ssh to my server and modify the files live."
1) It's old. You're alternatives to PHP 12 years ago are all bad. The most popular alternative was perl CGI scripts.
2) Since it's templated, it feels more like markup . Someone with absolutely no programming background can go: HTML -> HTML with a javascript "onclick" handler pasted from the web -> HTML with a bit of PHP pasted from the web -> writing my first original PHP code
The problem with people "defending" PHP is that they often only use PHP for a very specific purpose, and describe PHP from that perspective.
Hacking quick and dirty procedural scripts, writing something like WordPress plugins or developing "enterprise" applications with frameworks like Symfony or Zend are entirely different ways of using PHP, usually done by entirely different kind of developers.
The unmaintainable crap PHP is infamous for occurs when less than mediocre developers only familiar with one approach apply those limited skills to a project that requires a completely different approach.
What the author describes is not "how PHP is supposed to work". It's just one of many ways PHP can work. (And certainly not my way of using it.)
As at least one other commenter has said, there are disciplined and skilled PHP programmers. If only they were the majority! Sadly, for the PHP ecosystem, a few good apples don't unspoil the bunch.
Here are a few ways PHP's bad culture manifests itself.
1. Cargo culting
The web is filled with questionable recipes for doing this or that in PHP. I've observed a strong tendency of PHP programmers to approach every possible addition of functionality like this: 1) Google search; 2) find source code that supposedly does what's needed; 3) paste that source code in without understanding it or thoughtfully evaluating its appropriateness.
I'm all for learning by reading other people's code. I'm even OK with pasting code when you understand it fully. But cargo culting is bad, and it seems rampant in the PHP world.
http://en.wikipedia.org/wiki/Cargo_cult_programming
2. Lack of architecture
PHP applications often lack a coherent architecture. It's a typical mistake of new programmers--one that I made many times--to think just enough about architecture to accomplish the task immediately at hand. Naturally, this comes back to bite you when you want to extend your code's capabilities. I see this all the time in PHP applications.
Consider Wordpress. Its API is a random, ad-hoc mess of global functions. Things that should logically be exposed as objects aren't (like posts, for example). The API for retrieving content is different depending on whether you're in the mysterious "Loop" or not. And so on. A more detailed analysis of the lack of architecture in Wordpress can be found here:
http://www.phpvs.net/2009/12/08/an-exercise-in-wordpress-int...
3. Frankenstein coding
Similar to cargo culting, Frankenstein coding is when you cobble together an application from a bunch of off-the-shelf plugins or modules. This is a common practice in the Drupal world specifically, but it applies to a greater or lesser extent in much of the PHP ecosystem.
There are two major problems with this approach. First, the chunks of functionality you download are not likely to match your needs perfectly, so you're forced to make due with software that's almost what you want. Second, the code quality of these modules is often abysmal, and that means security flaws, among other problems.
Sadly, many PHP developers seem perfectly content with this. Even worse, they do this for clients, who get a semi-functional end product at bargain basement prices. That practice gives me a cheap, sleezy vibe, and it doesn't help my impression of the overall PHP ecosystem.
The language itself is so-so in my opinion--not good enough to be my go-to language, but not so terrible I'd refuse to work with it. But somehow, probably due to the language's accessibility, the PHP ecosystem seems to have been swamped by coders who know just enough to get by. And that's my real problem with PHP.
"the chunks of functionality you download are not likely to match your needs perfectly, so you're forced to make due with software that's almost what you want"
Drupal starts you off with 80% of the product functionally complete (!), for free, and leaves you with the spit and polish jar to squeak out the other 20. I find that this 80/20 rule is true for even very complex products. The lazy developer will never do that remaining 20%; this says nothing about Drupal.
You can name a function according to a convention and reach into any part of Drupal, or a contributed module, to pull that specific string that you need. I'll be blasphemous and say that not having to instantiate half a dozen objects just to dive through their properties to achieve the same result -- as you would likely have to in a "proper," purely OO CMS -- is very refreshing. The result is the same and the code is readable.
"Code quality is often abysmal."
True for one out of ten new modules that I encounter; and you are free not to use those modules. The heavy weights: CCK, Views, etc. are excellent.
I agree with that statement 100%. I don't think Drupal forces you to build a half-finished site with ten security holes. My problem is that lots of people do anyway. I don't necessarily blame Drupal for this phenomenon. I just think it's emblematic of a culture of quick and dirty coding that ultimately makes life harder for professionals and our clients.
However, I have a real love/hate relationship with wordpress plugins. Writing plugins is very easy, and there is sufficient documentation within wordpress itself to describe most functions. However, there are a LOT of plugins I've come across that are written terribly. I would love to express my dislike of them, however I've taken on the "If you cant write better, then don't criticize" mentality.
Maybe one day I'll feel confident enough in my skills as a coder to name and shame these scripts, but for now I'm concentrating on becoming a better developer, and writing good PHP.
The loop functions operate on (global) variables that are not explicitly passed into them. Therefore, without consulting their source, one cannot know what data they're touching. It's not obvious how and when these global variables get set and modified (which is one of the classic reasons global variables are considered Evil). Presumably, the variable are are set by the_loop(), but the opacity here is bad style.
On top of that, the fact that you must have these globals set to use the Loop's formatting functions makes it much less practical to use them in novel ways--i.e. in contexts other than the Loop. Sure, if you want that same data somewhere other than the Loop, there are other functions you can use. This is the typical reply I've heard in defense of the Loop. But that's a fairly poor defense: It's admitting that the API is so wonky, the WP devs had to create a bevy of functions that all do roughly the same thing to patch over each other's weaknesses. Why should there be a different way to get some post data in the main content area versus anywhere else?
BTW, I'm not just nit-picking Wordpress about the Loop. I'm talking about it because it's a well-known and very illustrative example of what I perceive to be a broader pattern of poor architecture throughout Wordpress.
Unfortunately there is also a counter-culture of elitism and condescension. I'm constantly encountering PHP devs who look down their nose at their fellow developers and assume that anyone who doesn't write sites exactly the same way they do is ignorant and full of failure.
That's the feeling I took from the article. The author _knows_ all the best practices, but sometimes he just wants to get shit done and PHP lets him do it.
That being said, there is such a thing as a wrong architecture. (And for non-trivial projects, the absence of architecture is clearly wrong as well.) The choice between several good designs is partly subjective, but some designs are objectively bad. So I think criticism (not condescension) is warranted at times. Wordpress being a good example.
Why? There's no deployment issues. There's no waiting for my app server to restart, no delay while a change is detected, etc. You edit a file, click refresh.
Flame away.
Edit For example, I am thinking of how various templating languages, including Jinja2 (for Python) default to auto-escaping strings you're echoing, but with PHP, you by default have to explicitly think about it and call `htmlentities($x, ENT_QUOTES, 'UTF-8')` all the time.
This can be said about any platform, regardless of the language.
Why are the updates even necessary? If you are still on Rails 2.3.8, you aren’t getting hacked just because you didn’t move to Rails 3 yet. But the situation with Wordpress & its ecosystem seems waaay less secure by default.
> This can be said about any platform, regardless of the language.
Not to the same degree, no sir.
A fair comparison would be Drupal, Joomla, vBullentin - anything of that nature - which all regularly release updates.
> * I have yet to see this kind of universal support for any other language than PHP. Not even Ruby on Rails, let alone Java, is available on mainstream providers, thereby validating the claim I made five years ago that Ruby on Rails won’t become mainstream (I regularly receive emails about this article asking me this question, and I keep responding “Nope, still not mainstream”).*
If your provider doesn't support Ruby, you need to get yourself a $20/month Linode box. If Linode and a $20/month price point isn't mainstream, I don't know what is.
I'm using a fairly "non-noob" ISP (ssh access, crontab, etc...) and they still don't give me access to much more than PHP. I can install Java but I can't even run it as a CGI because of the HTTP request memory constraints they impose. This is pretty standard, I don't blame them for doing this, and I would go with a VPS if actually needed all this.
Same for Ruby on Rails, obviously.
To my downvoter, here's a list of "mainstream" providers, at the Godaddy-level, and language support:
Dreamhost: RoR, PHP, Perl, Python [1]
Godaddy @ $8/month: PHP, Perl, Python, RoR [2]
a2Hosting @ $3/month: PHP, Perl, Ruby, Python
That seems pretty mainstream to me.
[1] http://beta.dreamhost.com/web-hosting/ [2] http://www.godaddy.com/hosting/web-hosting.aspx [3] http://www.a2hosting.com/services/web-hosting/
I work for an ISP and in about three years nobody had asked us about anything¹ more complicated than a simple PHP hosting with FTP access. (We don't really advertise hosting solutions, though, as this is not our main business.)
If you want your ISP to support something like Java or Rails — ask them today. They probably won't offer it now (or - who knows - they may surprise you!), but unless they're a type of company where individual client feedback gets lost, they'll note your request.
___
¹) Except for a colocated hosting, to be precise. But that's completely another case.
I have a friend with a webcomic and an art gallery page. She doesn't need ruby on rails and a 20 dollar a month host. PHP is a nice solution for her.
That's why PHP is still around.
True. And if nothing else, you can run Python on Google App Engine for free.
Except that PHP is terrible for systems programming?
I'm just starting to code one of my current projects, but in PHP. Should I consider ruby instead?
$x = "0"; if(!$x){ echo "0 is false"; }
If you understand why it's crazy that PHP prints "0 is false" when you execute that, you're probably better off jumping ship now. If you don't, you'll probably appreciate the low barrier to entry for PHP more than any benefit you'd gain.
$x = 0;
if(!empty($x)){
echo '"0" is empty';
}Of course, input type validation is still important, and if a variable input by the user is supposed to be numeric, that is why there is the is_numeric() function to validate the type of a variable.
But once I've used is_numeric() and know that the string is numeric why should I bother with an explicit strtoint call? I feel that this feature of PHP if used correctly takes away complexity and repetition related to converting strings to integers.
In a realistic project the framework for your app should have a layer between user input and your code anyway. At this layer it will be validating that input from the user is of the correct type anyway, and once that variable passes the is_numeric() test the layer can easily cast that input string to an int so that it is the right type for JSON encoded objects or any other output from PHP for other languages that needs to have specific types.
Once again, if PHP is used properly, with a decent code architecture this feature of PHP is not a problem.
Don't get me wrong, I think conflating strings and numbers is a bad idea, but if you're going to conflate strings and numbers, then having separate operators is the right thing to do.
"==" returns true if the left argument is numerically equal to the right argument.
"eq" returns true if the left argument is stringwise equal to the right argument.
see 'perldoc perlop' under the heading "Equality Operators"
I thought this is what the triple equals is for?
As someone who made a good living for many years by building stuff with PHP... I couldn't get away from it fast enough. Rails+Heroku is the new PHP, if you want a batteries-included web framework and easy hosting.
Not rhetorical: does anyone here use PHP for starting new projects?
What about hundreds or thousands of inconsistently named built-in functions?
C doesn't really have built-in functions, just a standard library that you don't have to load if you don't like it.
PHP has so many functions that it's almost impossible to write it without googling php.net, etc.
Not that this matters so much, Google is fast and omnipresent, but in that sense they are definitively not alike.
(Sorry if the level of levity is considered inappropriate, but humour is a level 4 defence mechanism and the only way I can remain sane in the face of such things)
Just picking a few of the "big" ones:
dreamhost.com: supports RoR
hostgator.com: supports RoR
bluehost.com: supports ROR
hostmonster.com: supports RoR
godaddy.com: partially supports RoR (fastcgi)
I guess that is simply not true anymore
Model.find_by_sql("raw select query")
ActiveRecord::Base.connection.execute("raw sql")
Are we also not allowed to talk about RoR when it comes to a discussion about PHP alternatives?
I guess it is true if you really stretch your imagination, but does it mean anything?
I suppose it's fine when many of then newer programmers don't even know or understand what's going on underneath anyway...
oh and btw, my point has pretty much been proven.
<?php echo htmlspecialchars($value, ENT_QUOTES);?>
PHP namespaces aren't any better: http://pornel.net/phpns
You also say that you either like both PHP and C, or you like neither. Well what about Lua, Python... or any other embed-able language? Most Python programmers would say they don't like PHP but love C, because the languages work well together, same with PERL as well. You could say that you either like both C++ and PHP or you like none. Maybe, because PHP can compile to C++ to become extremely fast, which is why Facebook and Yahoo both use PHP because it can be fast and it is well documented. It should not be compared to C though.
(Note: I contradict myself, PHP by itself is slow. PHP is not fast whatsoever. C++ is a low level language which is the only reason why it's fast and I think it's awesome that PHP can compile to C++. I'm in no way against PHP and I'm not encouraging people to stray away from the language. I was just pointing a simple error in this post.)
If anything, C has a much more academic pedigree, being born in an industrial research lab and having /gasp/ an specification.
Uh... could you explain how you arrived to this assertion? Because as far as I can see, PHP definitely is not academic. The bloody thing started as a hodge-podge collection of Perl scripts, and to this day it still does not have anything even remotely close to a formal grammar. A language in which `foo()[1];` is a syntax error even though `$a = foo(); $a[1];` is valid code most definitely is not academic.