Some surprising quotes from Rasmus Lerdorf (php creator)(en.wikiquote.org)
en.wikiquote.org
Some surprising quotes from Rasmus Lerdorf (php creator)
http://en.wikiquote.org/wiki/Rasmus_Lerdorf
15 comments
But it's not intrinsically good; every one of PHP's advantages is offered by other languages, without all the downsides. PHP's poor design and implementation has probably cost the world millions of lost man-hours; loss that could have been avoided by choosing a better-designed solution.
It's certainly an accomplishment to create popular software, but this popular software is not necessarily something that should be used. The popularity is a function of choices made by uneducated users.
(IE 6 is very popular, after all, but it's definitely not the best web browser around.)
It's certainly an accomplishment to create popular software, but this popular software is not necessarily something that should be used. The popularity is a function of choices made by uneducated users.
(IE 6 is very popular, after all, but it's definitely not the best web browser around.)
I don't think you understand PHP's greatest strength. It's all about the right tool for the right job for the right man.
PHP was invented so that designers could add a <p>Hello <b>Martin</b></p> and think it was cool that their homepage showed different names based on who you were. For most people basic functionality and the ability to connect to a database is more than enough. You can probably write up more than 90% of all webpages without using closuers, lambdas, recursive functions, object oriented programming and what have you. And the people who write these webpages don't care about programming at all, they just want the job done. These quotes from Rasmus shows where he's coming from.
You can of course argue that people shouldn't launch webpages if they don't know what they're doing, the terrible safety concerns of letting idiots code stuff for the web, etc. but it would be like scoffing at people who don't drive an extra souped up Ferrari Enzo - very arrogant. Some pople just want to get from A to B. These are the people who use PHP. And incidentally they are also the people down in the trenches actually building all the little sites that make the world go round.
PHP was invented so that designers could add a <p>Hello <b>Martin</b></p> and think it was cool that their homepage showed different names based on who you were. For most people basic functionality and the ability to connect to a database is more than enough. You can probably write up more than 90% of all webpages without using closuers, lambdas, recursive functions, object oriented programming and what have you. And the people who write these webpages don't care about programming at all, they just want the job done. These quotes from Rasmus shows where he's coming from.
You can of course argue that people shouldn't launch webpages if they don't know what they're doing, the terrible safety concerns of letting idiots code stuff for the web, etc. but it would be like scoffing at people who don't drive an extra souped up Ferrari Enzo - very arrogant. Some pople just want to get from A to B. These are the people who use PHP. And incidentally they are also the people down in the trenches actually building all the little sites that make the world go round.
> It's all about the right tool for the right job for the right man.
Oh, come on. Give me an instance where PHP is the right tool.
This argument is so overused that I don't even know what it means anymore.
And no, shared hosting doesn't count. My personal hosting plan costs something like $10 a month and I can choose between PHP, Python, Perl and Ruby (with Ruby it is more difficult, since I have to ask the sysadmin to add a couple of Mongrel instances for me). But mod_perl and mod_wsgi are there by default.
> <p>Hello <b>Martin</b></p>
Dude, that doesn't have any PHP code in it. To make this dynamic, you still have to have some way of authenticating and storing info about users. And you'll also want some way to edit those users.
Do you know how easy it is to create a simple CMS in Django, with authentication, and a functional admin? ... it takes only a couple of hours to a beginner that never worked with Python or Django before (yes, I saw one in action).
When PHP appeared, it made sense since Perl was the only game in town, and it was a bitch. But things have evolved a lot since then (even for Perl). For me, PHP doesn't make any sense.
Oh, come on. Give me an instance where PHP is the right tool.
This argument is so overused that I don't even know what it means anymore.
And no, shared hosting doesn't count. My personal hosting plan costs something like $10 a month and I can choose between PHP, Python, Perl and Ruby (with Ruby it is more difficult, since I have to ask the sysadmin to add a couple of Mongrel instances for me). But mod_perl and mod_wsgi are there by default.
> <p>Hello <b>Martin</b></p>
Dude, that doesn't have any PHP code in it. To make this dynamic, you still have to have some way of authenticating and storing info about users. And you'll also want some way to edit those users.
Do you know how easy it is to create a simple CMS in Django, with authentication, and a functional admin? ... it takes only a couple of hours to a beginner that never worked with Python or Django before (yes, I saw one in action).
When PHP appeared, it made sense since Perl was the only game in town, and it was a bitch. But things have evolved a lot since then (even for Perl). For me, PHP doesn't make any sense.
> <p>Hello <b>Martin</b></p>
Dude, that doesn't have any PHP code in it. To make this dynamic, you still have to have some way of authenticating and storing info about users. And you'll also want some way to edit those users.
Dude, he was saying they could add personalization to the page.
Dude, that doesn't have any PHP code in it. To make this dynamic, you still have to have some way of authenticating and storing info about users. And you'll also want some way to edit those users.
Dude, he was saying they could add personalization to the page.
> Do you know how easy it is to create a simple CMS in Django, with authentication, and a functional admin?
Frameworks have their place. PHP has a number of frameworks that can also make this claim. I would say raw PHP fits nicely where frameworks don't.
And <p>Hello <b><?php echo $_SESSION['first_name']; ?></b>!</p>. Populate SESSION however you like, whether it's from a database or a simple form submission.
Frameworks have their place. PHP has a number of frameworks that can also make this claim. I would say raw PHP fits nicely where frameworks don't.
And <p>Hello <b><?php echo $_SESSION['first_name']; ?></b>!</p>. Populate SESSION however you like, whether it's from a database or a simple form submission.
> Oh, come on. Give me an instance where PHP is the right tool.
Even today, if you have a lot of HTML, and you want to add just a little bit of dynamic functionality to it, PHP is easy and fast.
Even today, if you have a lot of HTML, and you want to add just a little bit of dynamic functionality to it, PHP is easy and fast.
But so is JSP, ASP, Mason, etc.
ASP, I'll agree; it occupies the "PHP" slot in Win32. JSP and Mason are far less likely to be available on a given server, and JSP requires a separate server to be running in addition to the webserver (tomcat or whatever).
With the declining popularity of Apache as the frontend server, I think PHP will have this problem in the future. Eventually everything will just be a FasgCGI handler. (PHP does FastCGI just fine, but so does Python/WSGI, Ruby/Rack, Perl/Plack, etc.)
[deleted]
>PHP's poor design and implementation has probably cost the world millions of lost man-hours; loss that could have been avoided by choosing a better-designed solution.
Could you give some examples of this?
I'm not a huge fan of PHP, but it generally works, as folks like FaceBook have proven.
Could you give some examples of this?
I'm not a huge fan of PHP, but it generally works, as folks like FaceBook have proven.
I think their object model is a good example. Introduced OOP in version 4 but they implemented it in a way that was unusable. They put it right in version 5 but that broke older code -- and it was still weird. It was only in the latest release that it became possible that you could get the right class name in a static method of a class that was inherited by another. Everything they do, they do wrong[1] and it takes them years to get it into approximative acceptable shape.
The only thing that saves them is that most php users have no clue of what they are doing, have not training of any sorts, and no nothing but php and maybe perl, vb or whatever.
[1] Okay, I'm exaggerating and the latest iteration is no longer the menace it once used to be.
The only thing that saves them is that most php users have no clue of what they are doing, have not training of any sorts, and no nothing but php and maybe perl, vb or whatever.
[1] Okay, I'm exaggerating and the latest iteration is no longer the menace it once used to be.
It greatly depends on what you compare PHP to, but to highlight a handful of disadvantages,
* PHP is considered extremely weak performance-wise
* There is poor to no support of multithreading
* There is no eventing system
* As a web framework, it sins in mixing code & design (opposed to e.g. Django-Python or Ruby on Rails)
(If the term "framework" seems unfit, think of "web-targeted toolkits")
* PHP is considered extremely weak performance-wise
* There is poor to no support of multithreading
* There is no eventing system
* As a web framework, it sins in mixing code & design (opposed to e.g. Django-Python or Ruby on Rails)
(If the term "framework" seems unfit, think of "web-targeted toolkits")
> PHP is considered extremely weak performance-wise
I don't know, it seems a lot of the very high trafficked sites (Facebook, Yahoo) run PHP. Yes benchmarks do show PHP doing poorly, but when was the last time anyone used PHP to crunch numbers? It's apparently fast at what it needs to be fast for.
> There is poor to no support of multithreading
That is not a flaw. PHP is a share nothing architecture; each request is completely independent. This is a good match for the stateless nature of HTTP. Multithreading isn't at all appropriate for PHP and I can't think of a scenario where it would be needed.
> There is no eventing system
PHP is a programming language not a framework. I'd make more of a comment about the various PHP frameworks but "eventing system" seems kind of vague. Maybe you can clarify this a bit and then I'll comment.
> As a web framework, it sins in mixing code & design (opposed to e.g. Django-Python or Ruby on Rails)
Nobody mixes in code & design in PHP anymore -- you won't find it terribly common among the various PHP frameworks. I do use it from time to time as a debugging aid and my compiling template engine uses it as the compilation target.
I don't know, it seems a lot of the very high trafficked sites (Facebook, Yahoo) run PHP. Yes benchmarks do show PHP doing poorly, but when was the last time anyone used PHP to crunch numbers? It's apparently fast at what it needs to be fast for.
> There is poor to no support of multithreading
That is not a flaw. PHP is a share nothing architecture; each request is completely independent. This is a good match for the stateless nature of HTTP. Multithreading isn't at all appropriate for PHP and I can't think of a scenario where it would be needed.
> There is no eventing system
PHP is a programming language not a framework. I'd make more of a comment about the various PHP frameworks but "eventing system" seems kind of vague. Maybe you can clarify this a bit and then I'll comment.
> As a web framework, it sins in mixing code & design (opposed to e.g. Django-Python or Ruby on Rails)
Nobody mixes in code & design in PHP anymore -- you won't find it terribly common among the various PHP frameworks. I do use it from time to time as a debugging aid and my compiling template engine uses it as the compilation target.
> I don't know, it seems a lot of the very high trafficked sites (Facebook, Yahoo) run PHP
I'm completely for PHP as a simple and accessible language. The previous author wanted to hear about the shortcomings of PHP and I tried to provide some. PHP sites such as Wikipedia probably need more servers (since every request is a separate process). They might be saving a lot of manpower by using PHP, so it might be an OK tradeoff.
By the way, Facebook uses Erlang for its performance-critical parts (such as chat).
> PHP is a share nothing architecture; each request is completely independent.
You could still use an agent-like messaging system for shared-nothing multithreaded/multiprocessed environment.
> I'd make more of a comment about the various PHP frameworks but "eventing system" seems kind of vague. Maybe you can clarify this a bit and then I'll comment.
e.g. When using cURL you must poll the handler until the request is complete. Obviously you'd need multithreading to achieve a better control flow in such a scenario.
> Nobody mixes in code & design in PHP anymore
I've written and debugged some wordpress plugins, and I can't say I came to the same conclusion as you...
I'm completely for PHP as a simple and accessible language. The previous author wanted to hear about the shortcomings of PHP and I tried to provide some. PHP sites such as Wikipedia probably need more servers (since every request is a separate process). They might be saving a lot of manpower by using PHP, so it might be an OK tradeoff.
By the way, Facebook uses Erlang for its performance-critical parts (such as chat).
> PHP is a share nothing architecture; each request is completely independent.
You could still use an agent-like messaging system for shared-nothing multithreaded/multiprocessed environment.
> I'd make more of a comment about the various PHP frameworks but "eventing system" seems kind of vague. Maybe you can clarify this a bit and then I'll comment.
e.g. When using cURL you must poll the handler until the request is complete. Obviously you'd need multithreading to achieve a better control flow in such a scenario.
> Nobody mixes in code & design in PHP anymore
I've written and debugged some wordpress plugins, and I can't say I came to the same conclusion as you...
> PHP sites such as Wikipedia probably need more servers (since every request is a separate process).
Citation needed. But every request isn't a separate PHP process; PHP is linked into Apache. Apache starts up a pool of processes and reuses them for requests. It's all highly efficient.
> By the way, Facebook uses Erlang for its performance-critical parts (such as chat).
Actually, it's not so much the performance critical parts but the parts where PHP's share-nothing architecture isn't appropriate. I doubt they're using a front-end web server for chat either.
> You could still use an agent-like messaging system for shared-nothing multithreaded/multiprocessed environment.
If you had the need, I suppose you could. Although I'm not sure what point you're trying to make here.
> When using cURL you must poll the handler until the request is complete. Obviously you'd need multithreading to achieve a better control flow in such a scenario.
You don't really need multithreading. JavaScript has callbacks for everything, for example, but isn't multithreaded. So this isn't so much a problem with PHP as it is a lack of design of cURL. But then cURL is a C library.
> I've written and debugged some wordpress plugins, and I can't say I came to the same conclusion as you...
Wordpress is old and not well designed. (Much like PHP itself)
Citation needed. But every request isn't a separate PHP process; PHP is linked into Apache. Apache starts up a pool of processes and reuses them for requests. It's all highly efficient.
> By the way, Facebook uses Erlang for its performance-critical parts (such as chat).
Actually, it's not so much the performance critical parts but the parts where PHP's share-nothing architecture isn't appropriate. I doubt they're using a front-end web server for chat either.
> You could still use an agent-like messaging system for shared-nothing multithreaded/multiprocessed environment.
If you had the need, I suppose you could. Although I'm not sure what point you're trying to make here.
> When using cURL you must poll the handler until the request is complete. Obviously you'd need multithreading to achieve a better control flow in such a scenario.
You don't really need multithreading. JavaScript has callbacks for everything, for example, but isn't multithreaded. So this isn't so much a problem with PHP as it is a lack of design of cURL. But then cURL is a C library.
> I've written and debugged some wordpress plugins, and I can't say I came to the same conclusion as you...
Wordpress is old and not well designed. (Much like PHP itself)
Apache starts up a pool of processes and reuses them for requests. It's all highly efficient.
It's highly efficient if you have a small number of requests at any given time; It's not as efficient for peak hours.
If you had the need, I suppose you could. Although I'm not sure what point you're trying to make here.
There are several use-cases I can think of, the simplest being more than one blocking request for rendering your page, and using multi-process to reduce the latency to the maximal block time instead of the sum of all block times.
You don't really need multithreading. JavaScript has callbacks for everything, for example, but isn't multithreaded. So this isn't so much a problem with PHP as it is a lack of design of cURL. But then cURL is a C library.
Javascript on server environments needs solutions such as node.js. On the client side, well, most UI apps have a single UI thread and delegate jobs to worker threads. In javascript, these are usually done via XMLHttpRequests.
It's highly efficient if you have a small number of requests at any given time; It's not as efficient for peak hours.
If you had the need, I suppose you could. Although I'm not sure what point you're trying to make here.
There are several use-cases I can think of, the simplest being more than one blocking request for rendering your page, and using multi-process to reduce the latency to the maximal block time instead of the sum of all block times.
You don't really need multithreading. JavaScript has callbacks for everything, for example, but isn't multithreaded. So this isn't so much a problem with PHP as it is a lack of design of cURL. But then cURL is a C library.
Javascript on server environments needs solutions such as node.js. On the client side, well, most UI apps have a single UI thread and delegate jobs to worker threads. In javascript, these are usually done via XMLHttpRequests.
> It's not as efficient for peak hours.
Actually it's quite fine during peak hours. You could, however, say it's a waste of resources during the lull times. But I'm not using those resources for anything else anyway; the entire purpose of the server is to service web requests. If a bunch of processes are sitting there wasting memory being idle, that's not a problem.
> There are several use-cases I can think of, the simplest being more than one blocking request for rendering your page
That's a fair case but I haven't personally encountered it yet. A good example, however, would be building a mashup page of content from a bunch of different web services.
Actually it's quite fine during peak hours. You could, however, say it's a waste of resources during the lull times. But I'm not using those resources for anything else anyway; the entire purpose of the server is to service web requests. If a bunch of processes are sitting there wasting memory being idle, that's not a problem.
> There are several use-cases I can think of, the simplest being more than one blocking request for rendering your page
That's a fair case but I haven't personally encountered it yet. A good example, however, would be building a mashup page of content from a bunch of different web services.
You don't really need multithreading.
It's true; many languages allow you to handle concurrent downloads by letting the OS call a function when the socket with the data is readable. (This is part of an "event loop".)
Many language implementations call this threading, however, because it is. You don't need one heavyweight OS thread for every thread of control in your application; many applications that make heavy use of IO easily handle thousands of threads inside one OS thread. It's a very useful abstraction.
It's true; many languages allow you to handle concurrent downloads by letting the OS call a function when the socket with the data is readable. (This is part of an "event loop".)
Many language implementations call this threading, however, because it is. You don't need one heavyweight OS thread for every thread of control in your application; many applications that make heavy use of IO easily handle thousands of threads inside one OS thread. It's a very useful abstraction.
Multithreading isn't at all appropriate for PHP and I can't think of a scenario where it would be needed.
Not blocking the entire PHP process while waiting for database results, waiting for a file to download, waiting for memcached to respond, etc.
I would (and do) use an event loop for this sort of things, but lightweight threads are technically a better abstraction. Web apps would use a lot less memory (and hardware) if people were not so afraid of threads.
(This happens a lot; a bad implementation of something taints the whole category. pthreads, Java threads, Perl ithreads, etc., are broken, so all threading is bad. C++'s object model is bad, so all object oriented programming is bad. It's sad.)
BTW: some good thread implementations include Haskell's and Perl's Coro.
Not blocking the entire PHP process while waiting for database results, waiting for a file to download, waiting for memcached to respond, etc.
I would (and do) use an event loop for this sort of things, but lightweight threads are technically a better abstraction. Web apps would use a lot less memory (and hardware) if people were not so afraid of threads.
(This happens a lot; a bad implementation of something taints the whole category. pthreads, Java threads, Perl ithreads, etc., are broken, so all threading is bad. C++'s object model is bad, so all object oriented programming is bad. It's sad.)
BTW: some good thread implementations include Haskell's and Perl's Coro.
> Not blocking the entire PHP process while waiting for database results, waiting for a file to download, waiting for memcached to respond, etc.
The thing is, I need those database results -- I can't do anything else until I have them. I received a single request from the user and I'm spitting out a single HTML response back. That's what PHP is all about. And mulithreading as optimization itself wouldn't improve performance because I'd be taking away CPU from other requests that are running concurrently.
> Web apps would use a lot less memory (and hardware) if people were not so afraid of threads.
Fundamentally I don't disagree; there's a lot of cool work going with event-based web servers. However, I think those designs are great for very specific tasks like chat servers and but require too much fiddling when doing traditional stateless web work. However, it may indeed be the future.
The thing is, I need those database results -- I can't do anything else until I have them. I received a single request from the user and I'm spitting out a single HTML response back. That's what PHP is all about. And mulithreading as optimization itself wouldn't improve performance because I'd be taking away CPU from other requests that are running concurrently.
> Web apps would use a lot less memory (and hardware) if people were not so afraid of threads.
Fundamentally I don't disagree; there's a lot of cool work going with event-based web servers. However, I think those designs are great for very specific tasks like chat servers and but require too much fiddling when doing traditional stateless web work. However, it may indeed be the future.
The thing is, I need those database results -- I can't do anything else until I have them.
You could start requesting the database results for a user that is now waiting in the tcp connect queue, cutting latency significantly.
Most people handle this with load balancing between processes, but your blocked-for-DB-results-process is sitting idle using system resources, like memory.
If you only have one user using your site at a time, then this isn't a concern. But for everyone else, blocked processes are wasteful.
but require too much fiddling when doing traditional stateless web work
Well, yeah, because you don't have threads. When you do, everything is handled by libraries for you; you can think you're blocking, but actually not block the process.
You could start requesting the database results for a user that is now waiting in the tcp connect queue, cutting latency significantly.
Most people handle this with load balancing between processes, but your blocked-for-DB-results-process is sitting idle using system resources, like memory.
If you only have one user using your site at a time, then this isn't a concern. But for everyone else, blocked processes are wasteful.
but require too much fiddling when doing traditional stateless web work
Well, yeah, because you don't have threads. When you do, everything is handled by libraries for you; you can think you're blocking, but actually not block the process.
> You could start requesting the database results for a user that is now waiting in the tcp connect queue, cutting latency significantly.
That's already how it works. If one process is blocked waiting for results, another process will get it's turn. Apache is one process per HTTP connection (when not running threaded).
> but your blocked-for-DB-results-process is sitting idle using system resources, like memory.
Either way it will need to use system resources. I can't throw away the resources of the user waiting for results, I need that once the results come in! Processes really don't take up that much memory and typically you're reusing a small number of them over and over anyway.
> If you only have one user using your site at a time, then this isn't a concern.
If somebody is blocked then someone else's request gets a turn at the CPU. Blocking a single process is completely inconsequential to multi-process web server serving multiple users.
That's already how it works. If one process is blocked waiting for results, another process will get it's turn. Apache is one process per HTTP connection (when not running threaded).
> but your blocked-for-DB-results-process is sitting idle using system resources, like memory.
Either way it will need to use system resources. I can't throw away the resources of the user waiting for results, I need that once the results come in! Processes really don't take up that much memory and typically you're reusing a small number of them over and over anyway.
> If you only have one user using your site at a time, then this isn't a concern.
If somebody is blocked then someone else's request gets a turn at the CPU. Blocking a single process is completely inconsequential to multi-process web server serving multiple users.
Processes really don't take up that much memory and typically you're reusing a small number of them over and over anyway.
They take up several orders of magnitude more memory than lightweight threads. I did some benchmarks a few months ago showing this; check searchyc if you care. Edit: here you are: http://news.ycombinator.com/item?id=794409
Anyway, when you start thinking about "web applications" instead of "web pages", lightweight threads make a lot more sense. And, you'll find that treating a web application like it's just a bunch of web pages leads to many problems down the road. (Performance is the least of your worries.)
Finally, "I definitely don't need to know about this abstraction because my favorite language doesn't have it" is dangerous thinking.
They take up several orders of magnitude more memory than lightweight threads. I did some benchmarks a few months ago showing this; check searchyc if you care. Edit: here you are: http://news.ycombinator.com/item?id=794409
Anyway, when you start thinking about "web applications" instead of "web pages", lightweight threads make a lot more sense. And, you'll find that treating a web application like it's just a bunch of web pages leads to many problems down the road. (Performance is the least of your worries.)
Finally, "I definitely don't need to know about this abstraction because my favorite language doesn't have it" is dangerous thinking.
> They take up several orders of magnitude more memory than lightweight threads.
Premature optimization; when a 1st grader can count to the number of processes you need for large scale web application optimizing it any more is a waste of time and effort.
> You'll find that treating a web application like it's just a bunch of web pages leads to many problems down the road.
Really? I find it refreshingly helpful. Instead of your large application being a large application, it actually just a series of very small applications. If a page crashes, it's pretty much no harm at all. If your whole application crashes, you're screwed. You want to add some functionality, just add it on.
> Finally, "I definitely don't need to know about this abstraction because my favorite language doesn't have it" is dangerous thinking.
"Oooh shiny" is also dangerous thinking. Is it really better to waste your time using up as many threads as possible or actually solving real problems for a few hundred processes?
Sidebar: Why is always you, Jonathan Rockway? Just how many posts do you make on Hacker news in a day? :)
Premature optimization; when a 1st grader can count to the number of processes you need for large scale web application optimizing it any more is a waste of time and effort.
> You'll find that treating a web application like it's just a bunch of web pages leads to many problems down the road.
Really? I find it refreshingly helpful. Instead of your large application being a large application, it actually just a series of very small applications. If a page crashes, it's pretty much no harm at all. If your whole application crashes, you're screwed. You want to add some functionality, just add it on.
> Finally, "I definitely don't need to know about this abstraction because my favorite language doesn't have it" is dangerous thinking.
"Oooh shiny" is also dangerous thinking. Is it really better to waste your time using up as many threads as possible or actually solving real problems for a few hundred processes?
Sidebar: Why is always you, Jonathan Rockway? Just how many posts do you make on Hacker news in a day? :)
[deleted]
I wonder what you're comparing PHP to. PHP is faster than Ruby and about the same speed as Python. Threading is not a pressing need in the sort of environment PHP typically runs - multiprocess web servers. Python and Ruby, when used for web apps also manage just fine with 'little to no support of multithreading'. And as someone else pointed out, it's not a framework to begin with (although there are PHP frameworks). The language is not without its warts and limitations but I don't think they're the ones you've listed.
Let's put the term "framework" aside. The Wikipedia article states it is "a basic conceptual structure used to solve or address complex issues, usually a set of tools, materials or components". I believe a scripting language that is pre-designed for website design could be considered a framework, but it's not that important whether there is a consensus.
I'd like to see your source for the performance claim. To my own I can bring e.g.
http://xodian.net/serendipity/index.php?/archives/27-Benchma...
http://blog.dhananjaynene.com/2008/07/performance-comparison...
I found threading a great shortcoming of PHP. I had web services that required data from several sources and was in need of querying in parallel. there are about 370,000 results for +php +multithreading on Google so I assume it's more than just myself.
I'd like to see your source for the performance claim. To my own I can bring e.g.
http://xodian.net/serendipity/index.php?/archives/27-Benchma...
http://blog.dhananjaynene.com/2008/07/performance-comparison...
I found threading a great shortcoming of PHP. I had web services that required data from several sources and was in need of querying in parallel. there are about 370,000 results for +php +multithreading on Google so I assume it's more than just myself.
The benchmarks you're linking are pretty limited (especially the first one that tests just instantiation and method dispatch). Also synthetic but somewhat more comprehensive -
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
As I said, if threading is a problem in PHP, it's as much of a problem in Ruby and Python. Common workaround is async message queueing with a great number of solutions available for all of these languages. There's a parallel curl available in recent versions of PHP that covers the simple 'multiple data services' case reasonably well.
http://shootout.alioth.debian.org/u32/benchmark.php?test=all...
As I said, if threading is a problem in PHP, it's as much of a problem in Ruby and Python. Common workaround is async message queueing with a great number of solutions available for all of these languages. There's a parallel curl available in recent versions of PHP that covers the simple 'multiple data services' case reasonably well.
You're referring to mcurl. It's an absolute necessity unless you want to shell out extra PHP processes. Still, you have to poll it and the code is not friendly.
Ruby is no gem either (I've always wanted to say that), with the one advantage of having dedicated high-level programmers as advocates within the community.
I haven't seen anything close to RoR or Django in PHP. Nor did I see a Twisted or node.js variant.
Ruby is no gem either (I've always wanted to say that), with the one advantage of having dedicated high-level programmers as advocates within the community.
I haven't seen anything close to RoR or Django in PHP. Nor did I see a Twisted or node.js variant.
Crawling is a problem that is fundamentally different from serving up dynamic websites. I've written a php based crawler framework, it simply uses a database as a central synchronization area and a bunch of parallel scripts to do the crawling.
I could have done the same using curl but for technical reasons chose to do it this way. It's definitely a work around kind of solution though.
I hope to replace the whole thing with a clojure/jvm based solution.
I could have done the same using curl but for technical reasons chose to do it this way. It's definitely a work around kind of solution though.
I hope to replace the whole thing with a clojure/jvm based solution.
"PHP is considered extremely weak performance-wise"
Compared to what? Assembler?
There are valid criticisms to be made of PHP, but poor performance is not one of them.
Compared to what? Assembler?
There are valid criticisms to be made of PHP, but poor performance is not one of them.
Php is pretty fast in its way actually because a lot of the stuff is just plain wrappers for C functions. Use PHP right and do as much as possible with the built in functions and it's pretty fast -- build complex OO junkworks and it'll slow down a little.
I'd be happy to learn, but you'd have to expand the one-liner.
I am involved with two very high volume sites, one is written in Java using tomcat as the server and it needs 3 servers to handle between 650K and 1.5M uniques daily, server load is ok but fairly high, the other is a PHP based service that serves up 1.8 million pages on a good day to 50K uniques, the server load on that box is a relaxed 0.6.
When used properly PHP is performing quite well. Note that this is without any front-end caching, each page gets generated anew.
When used properly PHP is performing quite well. Note that this is without any front-end caching, each page gets generated anew.
Are these two sites doing equivalent work? Without knowing what kind of work these sites are doing, this isn't really a useful comparison.
Yes, absolutely.
Otherwise I wouldn't have used them as examples. They are basically implementations of the same kind of site but on different platforms, the one more successful than the other.
In terms of raw performance I'd say the java environment is a little bit faster, but not by much.
In terms of programmer performance I'd say the PHP environment is a lot faster than the java environment.
The java I would qualify as more maintainable though, but it is less stable in production than PHP (we see the occasional freeze on java, the apache/PHP stuff seems to run itself for year after year without any issues).
Both use mysql db backends.
Otherwise I wouldn't have used them as examples. They are basically implementations of the same kind of site but on different platforms, the one more successful than the other.
In terms of raw performance I'd say the java environment is a little bit faster, but not by much.
In terms of programmer performance I'd say the PHP environment is a lot faster than the java environment.
The java I would qualify as more maintainable though, but it is less stable in production than PHP (we see the occasional freeze on java, the apache/PHP stuff seems to run itself for year after year without any issues).
Both use mysql db backends.
I wonder whether it's not so much Java, but the excessive "architecture" around the language. My software uses the Jetty web server, a minimal framework, and JRuby for application code. It's very very fast, stable, not particular heavy on memory consumption, and I get good programmer productivity with the Ruby language. Importantly, I get to use all the shiny Java libraries instead of battling with Ruby gems.
I have come to the conclusion that the JVM combined with the vast number of libraries is great, but the Java ecosystem is not terribly optimal and over complicated.
I have come to the conclusion that the JVM combined with the vast number of libraries is great, but the Java ecosystem is not terribly optimal and over complicated.
One day someone will come up with a 'runnable war file' that contains the whole web application+container and does not require unpacking or other manipulation, entirely stand-alone.
Would it actually be that hard to put everything in a single jar file and generate a class to boot it? Is it more than tracing dependencies and setting up the servlet configuration? Admittedly I have avoided the whole Java infrastructure, but using Jetty as an embedded web server has been painless.
PHP is not a framework.
While one could argue for PHP being a "language" upon which frameworks are built, it really is just a framework. A low level framework that is. Frameworks built on top of it are just higher-level more abstract frameworks.
I come from 4+ years of using it professionally and most of the higher level frameworks I'm talking about (Kohana, Zend, CodeIgniter, etc...) really only exist to overcome a lot of PHP's more abstract weaknesses (even though they can't really do much about the interpreter implementation).
I can easily say that something written in Python, Scheme, or whatever-you-choose will run a lot better, take less time to build, and be easier to manage down the road.
The primary problem in this industry is that the majority of web application programmers grew upon PHP and are running their own IP Consulting shops or startups by now and have zero experience with other languages, therefore making them much less interested in trying to adopt a different web development paradigm when an aspiring web developer with Python/Erlang/Scheme/Ruby skills under their belt try to build something with that tool chain in their employ.
The less knowledge and/or experience with other languages you have, the more rooted in what you are comfortable with you are. Education is a good thing, that is what I love about Hacker News; the people here experiment with new languages and trying out new technologies for their projects/products - which is much more progressive than the enterprise situation.
I come from 4+ years of using it professionally and most of the higher level frameworks I'm talking about (Kohana, Zend, CodeIgniter, etc...) really only exist to overcome a lot of PHP's more abstract weaknesses (even though they can't really do much about the interpreter implementation).
I can easily say that something written in Python, Scheme, or whatever-you-choose will run a lot better, take less time to build, and be easier to manage down the road.
The primary problem in this industry is that the majority of web application programmers grew upon PHP and are running their own IP Consulting shops or startups by now and have zero experience with other languages, therefore making them much less interested in trying to adopt a different web development paradigm when an aspiring web developer with Python/Erlang/Scheme/Ruby skills under their belt try to build something with that tool chain in their employ.
The less knowledge and/or experience with other languages you have, the more rooted in what you are comfortable with you are. Education is a good thing, that is what I love about Hacker News; the people here experiment with new languages and trying out new technologies for their projects/products - which is much more progressive than the enterprise situation.
This essay from Rasmus is interesting:
http://toys.lerdorf.com/archives/38-The-no-framework-PHP-MVC...
In a way php is a framework.
In a way php is a framework.
You have some points, but I think they're not very strong. PHP seems fast enough for many popular and large websites, I'm not sure how important multithreading is to most web applications out there, same with events, and the last criticism is in the PHP community thought of as a feature. PHP easily suffices as a quick, simple templating language when you don't feel like you need to bring in Smarty or some other thing specific to templating.
Could you give some examples of this?
This has been described in detail thousands of times. Google it.
This has been described in detail thousands of times. Google it.
How do you get anything done? You seem so hung up on the tools versus creating stuff with tools. I guess it makes sense because you're the maintainer of a web framework ... for perl ... a language saddled with a checkered history of generating some pretty unmaintainable shit. And my guess is that you will respond saying "you can write maintainable code in perl!" And, of course, one would counter that you can do the same with PHP. Which boils this whole discussion down to being about the developers and the quality of developers, and less about the quality of the languages.
So why are there so many crappy PHP developers? Because anyone can make it do something approximating what they are envisioning it doing, no matter the skill level. That seems pretty powerful to me. And, in the end, it's really about the results instead of how one necessarily got to those results. You can't make money if you don't deliver a product. And if history is any indication, only a tiny fraction of the masses care about quality. The dominance of Wal-mart and MySpace are proof of this. My guess about your guess is those millions of lost man-hours have been made up with the millions of hours beating competing products to market due to the rapid nature of PHP development. I mean if we are throwing around unverifiable assumptions, let's do it, let's get crazy with it.
"A determined soul will do more with a rusty monkey wrench than a loafer will accomplish with all the tools in a machine shop." - Robert Hughes
So why are there so many crappy PHP developers? Because anyone can make it do something approximating what they are envisioning it doing, no matter the skill level. That seems pretty powerful to me. And, in the end, it's really about the results instead of how one necessarily got to those results. You can't make money if you don't deliver a product. And if history is any indication, only a tiny fraction of the masses care about quality. The dominance of Wal-mart and MySpace are proof of this. My guess about your guess is those millions of lost man-hours have been made up with the millions of hours beating competing products to market due to the rapid nature of PHP development. I mean if we are throwing around unverifiable assumptions, let's do it, let's get crazy with it.
"A determined soul will do more with a rusty monkey wrench than a loafer will accomplish with all the tools in a machine shop." - Robert Hughes
You undermine your argument by making it personally aggressive.
jrockway is a PHP troll. There is most certainly a history here that goes way back.
Personally aggressive? Maybe. Deservedly? Probably.
Personally aggressive? Maybe. Deservedly? Probably.
Even if you're right, the point is that it degrades the site for everybody if you engage in it.
I am not a PHP troll, I just point out its technical weaknesses when people claim that it is technically superior to other solutions.
That may be true today but PHP is old in web terms, when PHP began to become popular it was at a time when it had little competition that offered the same ability to build dynamic web pages with relative ease. PHP spent enough time at the top of the web dev heap to build up a substantial network effect. The comparative advantages of other technologies, large though they may by, are not yet enough to push PHP from the top spot.
Exactly. My career started back then, and there really wasn't a lot out there:
* CGI (mostly done with Perl).
* mod_perl (a huge ungainly mess)
* ASP (no thanks, not a Microsoft guy)
* Various proprietary things
* Various niche players (my own mod_dtcl [later Apache Rivet] was faster and IMO, nicer than PHP, but never got more than a modest amount of traction).
By the time I even started writing mod_dtcl, PHP was already pretty widely used, and we were using it in production at the company I worked for, and it was certainly better/faster than doing things in Perl CGI's.
These days, I really, really, really don't like having anything to do with PHP after having dealt with too many unholy messes, but I can't deny that it got some critical things right at the right time.
* CGI (mostly done with Perl).
* mod_perl (a huge ungainly mess)
* ASP (no thanks, not a Microsoft guy)
* Various proprietary things
* Various niche players (my own mod_dtcl [later Apache Rivet] was faster and IMO, nicer than PHP, but never got more than a modest amount of traction).
By the time I even started writing mod_dtcl, PHP was already pretty widely used, and we were using it in production at the company I worked for, and it was certainly better/faster than doing things in Perl CGI's.
These days, I really, really, really don't like having anything to do with PHP after having dealt with too many unholy messes, but I can't deny that it got some critical things right at the right time.
every one of PHP's advantages is offered by other languages
Speed in a shared hosting environment. I've read about developers running multiple commercial sites from a single Dreamhost account e.g. http://www.pseudocoder.com/archives/2009/01/04/how-much-mone... . That's not realistic with Java, RoR, or Perl.
Speed in a shared hosting environment. I've read about developers running multiple commercial sites from a single Dreamhost account e.g. http://www.pseudocoder.com/archives/2009/01/04/how-much-mone... . That's not realistic with Java, RoR, or Perl.
Note that Dreamhost recently moved from using mod_php to running PHP as a FastCGI server (per website/account).
So I assume PHP no longer has the performance advantage of integrating closely with Apache.
In fact, since Dreamhost now offers Passenger (AKA mod_rails) as a solution for running Rails and Django) PHP might be at a disadvantage. Especially when paired with a large framework (zend,codeigniter,cake, etc.)
So I assume PHP no longer has the performance advantage of integrating closely with Apache.
In fact, since Dreamhost now offers Passenger (AKA mod_rails) as a solution for running Rails and Django) PHP might be at a disadvantage. Especially when paired with a large framework (zend,codeigniter,cake, etc.)
I think you could make the somewhat tautological case that IE 6 is not bad enough to make many people use something else or that php is good enough to make many people choose it.
Defining good is always tricky, but being chosen by many people when other good choices are available is not a bad test for certain definitions of good.
Choices may not always be %100 rational. They are usually not random.
Defining good is always tricky, but being chosen by many people when other good choices are available is not a bad test for certain definitions of good.
Choices may not always be %100 rational. They are usually not random.
But IE6 is bad enough to make people use something else, and PHP is not good enough to make many people choose it. Who purposely downloads and installs IE6 these days when you have Chrome/Firefox/IE8 available? And who writes a new webapp in PHP?
Most people seem to miss the role that time plays in language choice. PHP's very far from the best choice for webapps now, but it was the best choice when it was invented in 1995, and even for a while afterwards (such as when FaceBook was created in 2004).
Most people seem to miss the role that time plays in language choice. PHP's very far from the best choice for webapps now, but it was the best choice when it was invented in 1995, and even for a while afterwards (such as when FaceBook was created in 2004).
Many people write new webapps in php.
Nobody purposely downloads IE6. That isn't the point though. If they buy a computer (maybe this isn't true anymore) and go to Google using it they don't go "something's wrong." They just keep using it.
Nobody purposely downloads IE6. That isn't the point though. If they buy a computer (maybe this isn't true anymore) and go to Google using it they don't go "something's wrong." They just keep using it.
I wonder how many IE6 users actually choose their browser?
I like it when language designers are "cool". My favorite language is Python, but I like Larry Wall's quirky personality better than Guido's, and Rasmus' is great. ;)
He's always been pretty open about his "just get the job done" approach. That's exactly what PHP is too. Not beautiful, well designed etc., but gets the job done in most cases.
This is a mail he showed at a talk - http://lerdorf.com/fanmail.txt
I'm sure he enjoys it when people get worked up about PHP :)
This is a mail he showed at a talk - http://lerdorf.com/fanmail.txt
I'm sure he enjoys it when people get worked up about PHP :)
That email is confusing. "From: damien taylor" in 2003 yet signed "Walter Bagdasarian", which unusual-seeming name belongs to a guy who was convicted in 2009 of threatening Obama. Odd.
It fits, he got arrested for posting an idiot comment about Obama on the Yahoo message boards.
Used to be you had to do something before you got charged.
Threatening seems so much like thoughtcrime.
Threatening seems so much like thoughtcrime.
Making threats has been a "something" that's considered a crime for... well, a long time. Typically the law requires that the threat be at least somewhat believable in order to be successfully prosecuted, but there are certain types of threats which are criminal regardless of ability to be carried out (e.g., threatening to plant a bomb in a public square is a crime, even if you have no way of building or planting the bomb).
A message on a yahoo board seems to be a bit of a stretch though.
Threats made against the President are handled rather specially, by people who aren't inclined to view online message boards as trivial.
[deleted]
To be fair, some ("I still am really bad at writing parsers.") seem to be more signs of humility than confessions of incompetence.
Read PHP's parser.
The parser in PHP 3 and up was written by Zeev Suraski and Andi Gutmans: http://en.wikipedia.org/wiki/PHP
The original parser was written by Lerdorf (source: your wikipedia link).
But I don't think any of them have anything to be proud of: http://www.steike.com/code/php-must-die/
But I don't think any of them have anything to be proud of: http://www.steike.com/code/php-must-die/
swoosh
Those quotes aren't surprising. Someone with the attitude shown in those quotes would create a language exactly like PHP. And that language would be hated by most of the people who actually enjoy coding.
Most of them aren't that surprising if you've used PHP. ;-)
This makes me love PHP more. If that was possible.
He just gets it. If you want to spend your days drawing UML, writing documentation and unit tests. That is dandy, but you're in PHPLand now. This is our land, and we dont care about no freakin' memory leaks.
He just gets it. If you want to spend your days drawing UML, writing documentation and unit tests. That is dandy, but you're in PHPLand now. This is our land, and we dont care about no freakin' memory leaks.
Do you have any concept of just how much time and money hacked-together PHP has cost?
Do you know how many aggregate human lifetimes are wasted on the simple act of regularly upgrading PHPBB, WordPress, MediaWiki, et al?
It's mindboggling. It's sad. It's penny wise, pound foolish.
Do you know how many aggregate human lifetimes are wasted on the simple act of regularly upgrading PHPBB, WordPress, MediaWiki, et al?
It's mindboggling. It's sad. It's penny wise, pound foolish.
Yet Wordpress is still the most widely used blog software ever. PHPBB and it's ilk still run the forum game. Wikipedia has yet be unseated.
If it's cost > it's profit, why is it still used so widely?
I recently replaced a C#/.NET app with a PHP version and saved a company close to a million a year in licensing, servers, staffing and development costs. Not to mention it took my team a third of the time to develop as the original application, yet performed better and had more functionality. There was a significant gap in LoC as well.
If it's cost > it's profit, why is it still used so widely?
I recently replaced a C#/.NET app with a PHP version and saved a company close to a million a year in licensing, servers, staffing and development costs. Not to mention it took my team a third of the time to develop as the original application, yet performed better and had more functionality. There was a significant gap in LoC as well.
Yet Wordpress is still the most widely used blog software ever. PHPBB and it's ilk still run the forum game. Wikipedia has yet be unseated.
If it's cost > it's profit, why is it still used so widely?
Network effects, data lock-in, asynchronous information exchange in markets. Just because something is rationally better doesn't mean that the market actors are rational.
That said, companies like EA, Apple, and Amazon license Jive Forums (which is not cheap), Confluence, et al for a reason.
I recently replaced a C#/.NET app with a PHP version and saved a company close to a million a year in licensing, servers, staffing and development costs. Not to mention it took my team a third of the time to develop as the original application, yet performed better and had more functionality. There was a significant gap in LoC as well.
Your anecdote is a personal anecdote, coming from the person most likely to have a particularly jaded view of both the short and long-term costs involved.
If it's cost > it's profit, why is it still used so widely?
Network effects, data lock-in, asynchronous information exchange in markets. Just because something is rationally better doesn't mean that the market actors are rational.
That said, companies like EA, Apple, and Amazon license Jive Forums (which is not cheap), Confluence, et al for a reason.
I recently replaced a C#/.NET app with a PHP version and saved a company close to a million a year in licensing, servers, staffing and development costs. Not to mention it took my team a third of the time to develop as the original application, yet performed better and had more functionality. There was a significant gap in LoC as well.
Your anecdote is a personal anecdote, coming from the person most likely to have a particularly jaded view of both the short and long-term costs involved.
We dropped PHPBB and moved to Jive Forums several years ago, as the costs of weekly updates and surprisingly regular break-ins easily outweighed the cost of licensing Jive's software. However, moving away from the forum required data migration, which was difficult and time consuming.
And that's not a personal anecdote? You aren't particularly jaded? I don't understand why I would have a jaded view of the short and long term costs involved. You'll have to explain. I'm not a PHP developer, btw. I consult across a wide variety of technologies and have done so for the last 15+ years. I would have certainly been better paid for that particular gig had I stuck with C#.
It would make sense that Apple and Amazon use Jive since all of their web properties are largely Java based, why step outside of a core competency?
And that's not a personal anecdote? You aren't particularly jaded? I don't understand why I would have a jaded view of the short and long term costs involved. You'll have to explain. I'm not a PHP developer, btw. I consult across a wide variety of technologies and have done so for the last 15+ years. I would have certainly been better paid for that particular gig had I stuck with C#.
It would make sense that Apple and Amazon use Jive since all of their web properties are largely Java based, why step outside of a core competency?
And just to be clear, I would never recommend any PHP forum software (just ask the exasperated folks @ Massify), mostly because I think they are functionally retarded and security is a joke. But that has little to do with PHP than it does with the way they are written.
I think you make a valid point.
Maintaining PHP apps can be a pain and the language isn't the prettiest to work with.
However, PHP has created a world where millions of people can create basic web applications, which has led to the creation of tens of millions of new sites and applications, some of those which have changed the world.
PHP has allowed more people to code, which has allowed the world to test many more ideas, many of which have created tremendous value that I think far outweigh the costs.
Maintaining PHP apps can be a pain and the language isn't the prettiest to work with.
However, PHP has created a world where millions of people can create basic web applications, which has led to the creation of tens of millions of new sites and applications, some of those which have changed the world.
PHP has allowed more people to code, which has allowed the world to test many more ideas, many of which have created tremendous value that I think far outweigh the costs.
This sounds like a false dichotomy:
- A world that has PHP and enabled web developers.
- A world without PHP in which only Java EE-enabled engineers can write webapps.
I think that's a demonstrably false assessment. A language as poorly designed and implemented as PHP isn't necessary to be accessible to "millions of people" -- in fact, does the opposite in enabling them to make serious and expensive mistakes.
- A world that has PHP and enabled web developers.
- A world without PHP in which only Java EE-enabled engineers can write webapps.
I think that's a demonstrably false assessment. A language as poorly designed and implemented as PHP isn't necessary to be accessible to "millions of people" -- in fact, does the opposite in enabling them to make serious and expensive mistakes.
Yet the fact of the matter is that's how the cards fell - we had the well-designed, well-implemented languages and frameworks that failed utterly to find any foothold with amateurs and beginners, and only found refuge with the Java EE-enabled engineers.
And then we had PHP.
I'm inclined to side with the parent poster - yes, PHP has a lot of problems when you attempt to make it overly complex, but on the other hand it has introduced many people to programming who would otherwise never have even attempted (or even be able to), and driven ubiquitous web scripting forward single-handedly. Heck, even today, think about someone trying to run a blog - anyone reasonably experienced with a computer can buy hosting and install WordPress with almost no work... try that with anything written in Python?
PHP has a very low barrier to entry, and IMHO a lot of the hate directed at it is frankly jealousy. We are jealous, as professionals, that it is deadly simple to replicate some of our hard work, and that the people doing it are amateurs. This is the same reason people heap hate on VB.
I'm inclined to compare PHP to MySpace - yes, MySpace pages aren't pretty, in fact a lot are downright atrocious. You can make some specious claims about how MySpace-inspired "web design" has made the internet a worse place, somehow, but it would be a pretty thin argument. At the end of the day, both PHP and MySpace opened up a world of possibility to a lot of users who didn't have it before; picking at it really is just being pretentious and elitist.
And then we had PHP.
I'm inclined to side with the parent poster - yes, PHP has a lot of problems when you attempt to make it overly complex, but on the other hand it has introduced many people to programming who would otherwise never have even attempted (or even be able to), and driven ubiquitous web scripting forward single-handedly. Heck, even today, think about someone trying to run a blog - anyone reasonably experienced with a computer can buy hosting and install WordPress with almost no work... try that with anything written in Python?
PHP has a very low barrier to entry, and IMHO a lot of the hate directed at it is frankly jealousy. We are jealous, as professionals, that it is deadly simple to replicate some of our hard work, and that the people doing it are amateurs. This is the same reason people heap hate on VB.
I'm inclined to compare PHP to MySpace - yes, MySpace pages aren't pretty, in fact a lot are downright atrocious. You can make some specious claims about how MySpace-inspired "web design" has made the internet a worse place, somehow, but it would be a pretty thin argument. At the end of the day, both PHP and MySpace opened up a world of possibility to a lot of users who didn't have it before; picking at it really is just being pretentious and elitist.
Yet the fact of the matter is that's how the cards fell - we had the well-designed, well-implemented languages and frameworks that failed utterly to find any foothold with amateurs and beginners, and only found refuge with the Java EE-enabled engineers.
When did we have all that? In 1995, when PHP was started, I remember having Perl, shell scripts, and C server-side CGIs.
I don't recall significantly better viable alternatives becoming available until quite some time later.
When did we have all that? In 1995, when PHP was started, I remember having Perl, shell scripts, and C server-side CGIs.
I don't recall significantly better viable alternatives becoming available until quite some time later.
I don't think you're looking holistically at the environment of building a dynamic website with no experience at all programming, which is what I think this conversation is about.
If you can, put aside all that you know about language design, frameworks, and software engineering, and try to think from the perspective of a person just wanting to "get something up". Say you want an online store. An online store requires a shopping cart. You ask google how to do this, and google tells you: How to build a shopping cart with PHP. For whatever reason, php was chosen by the internet gods to be the beneficiary of a positive feedback loop: beginners use php, find it easy to use, write tutorials. Tutorials attract google, which means the community is likely to be less of the programmer type (programmers would already know how to do these things in python) and more of hobbyists/internet entreprenuers with little technical skill. Because this community is comprised of less technical people, they are more understanding of the shortcomings of n00bs. They turn away less "stupid" questions, write more tutorials and abstract more of the academic attributes of programming that "make it work". By virtue of attracting so many people, inevitably, there will be some truly capable practitioners that will go on to have success. Derek Sivers of CD Baby fame is one I can think of.
The point i'm really trying to drive home is that the accessibility of a language isn't just about being easy to learn, but about having a welcoming community and environment that helps new users.
If you can, put aside all that you know about language design, frameworks, and software engineering, and try to think from the perspective of a person just wanting to "get something up". Say you want an online store. An online store requires a shopping cart. You ask google how to do this, and google tells you: How to build a shopping cart with PHP. For whatever reason, php was chosen by the internet gods to be the beneficiary of a positive feedback loop: beginners use php, find it easy to use, write tutorials. Tutorials attract google, which means the community is likely to be less of the programmer type (programmers would already know how to do these things in python) and more of hobbyists/internet entreprenuers with little technical skill. Because this community is comprised of less technical people, they are more understanding of the shortcomings of n00bs. They turn away less "stupid" questions, write more tutorials and abstract more of the academic attributes of programming that "make it work". By virtue of attracting so many people, inevitably, there will be some truly capable practitioners that will go on to have success. Derek Sivers of CD Baby fame is one I can think of.
The point i'm really trying to drive home is that the accessibility of a language isn't just about being easy to learn, but about having a welcoming community and environment that helps new users.
>Do you have any concept of just how much time and money hacked-together PHP has cost?
I don't think it's fair to blame bad programming on the language itself.
>Do you know how many aggregate human lifetimes are wasted on the simple act of regularly upgrading PHPBB, WordPress, MediaWiki, et al?
Software written in other languages doesn't require upgrading?
I don't think it's fair to blame bad programming on the language itself.
>Do you know how many aggregate human lifetimes are wasted on the simple act of regularly upgrading PHPBB, WordPress, MediaWiki, et al?
Software written in other languages doesn't require upgrading?
On the other hand, think of all the jobs and employment created as a byproduct of all this "waste"! I daresay php has created wealth.
http://en.wikipedia.org/wiki/Broken_windows_fallacy
Think of all the cool stuff they could have been inventing had they not needed to look up the name of strfind(?), and whether it takes the needle or the haystack first.
Think of all the cool stuff they could have been inventing had they not needed to look up the name of strfind(?), and whether it takes the needle or the haystack first.
So what. Tell me you never use the man pages for the standard C library.
There's a whole generation of programmers out there that couldn't hack their way out of a wet paper back without the help of an IDE telling them what function parameters go where.
And in C I also still can't remember if the fwrite call takes (buffer, sizeof(element), nelements, fp) or (buffer, nelements, sizeof(element), fp).
This is all about religion, the PHP church has a large number of followers and it's 'bible' contains some arguably wrong pages, so those in other churches will go out of their way to shake their heads at all the fools in the PHP church when it's clear to everyone else that their religion is broken.
Meanwhile the PHP guys will simply get the job done and take home the loot.
I can program in lots of languages but for quick & dirty stuff (and don't tell me everything you write is of world class importance) it is very well suited, if you're disciplined you can take it to considerable heights before you run out of steam.
There's a whole generation of programmers out there that couldn't hack their way out of a wet paper back without the help of an IDE telling them what function parameters go where.
And in C I also still can't remember if the fwrite call takes (buffer, sizeof(element), nelements, fp) or (buffer, nelements, sizeof(element), fp).
This is all about religion, the PHP church has a large number of followers and it's 'bible' contains some arguably wrong pages, so those in other churches will go out of their way to shake their heads at all the fools in the PHP church when it's clear to everyone else that their religion is broken.
Meanwhile the PHP guys will simply get the job done and take home the loot.
I can program in lots of languages but for quick & dirty stuff (and don't tell me everything you write is of world class importance) it is very well suited, if you're disciplined you can take it to considerable heights before you run out of steam.
I have to use the man pages for most languages when I'm learning them. PHP is fairly unique among languages I've worked with (and that doesn't include C) in that I have to keep using the man pages even after I've become fairly fluent with it.
In Python, by contrast, that fwrite call is just:
(And actually...of late, everything I write is of world class importance, but that's an artifact of my current project and the fact that it's sorta taken over my life. I used to write quick & dirty stuff much more often, and I usually used Django for it.)
In Python, by contrast, that fwrite call is just:
fp.write(text)
(And actually...of late, everything I write is of world class importance, but that's an artifact of my current project and the fact that it's sorta taken over my life. I used to write quick & dirty stuff much more often, and I usually used Django for it.)
Same here, but I can't deny that PHP made me more money than all those other sexy languages combined.
I'd argue that being in a market that people wanted made you money, not PHP. I dunno what the timescale of your successes was - I think PHP actually was the best option for webapps between about 1998 and 2004 - but there are better technologies available now.
Java and C++ made me money, PHP made me bupkis. Python at least is fun.
Java and C++ made me money, PHP made me bupkis. Python at least is fun.
Building camarades.com, now ww.com in march '98. The webcam software was in C++.
This is all about religion, the PHP church has a large number of followers and it's 'bible' contains some arguably wrong pages, so those in other churches will go out of their way to shake their heads at all the fools in the PHP church when it's clear to everyone else that their religion is broken.
This "we get it done, everyone else doesn't, ergo X is better despite its flaws" logical faux pax drives me up the bloody wall.
This "we get it done, everyone else doesn't, ergo X is better despite its flaws" logical faux pax drives me up the bloody wall.
Where did you read 'x is better' ?
That's not what I wrote. It's simply good enough.
A toolbox analogy:
We all know that brand 'x' is 'the best' possible tool available.
So why doesn't everybody use brand 'x' ?
Well, because some people have gotten used to brand 'y' and it is good enough for them.
What's better doesn't enter in to it. There is a minimum level of performance required for the job and both tools meet those requirements, so both are valid tools to solve the problem with.
Which one is the 'better' one is a matter of perspective, and in that sense there are as many truths as there are observers.
That's not what I wrote. It's simply good enough.
A toolbox analogy:
We all know that brand 'x' is 'the best' possible tool available.
So why doesn't everybody use brand 'x' ?
Well, because some people have gotten used to brand 'y' and it is good enough for them.
What's better doesn't enter in to it. There is a minimum level of performance required for the job and both tools meet those requirements, so both are valid tools to solve the problem with.
Which one is the 'better' one is a matter of perspective, and in that sense there are as many truths as there are observers.
you should unit test your php
I can't tell if you're being sarcastic or not.
At least he's not trying to kid anyone.
To add to the noise here: all people bashing here, please remember webdev landscape around the time PHP got started (or around the time it got to version 3, which looked somewhat a real language).
I started using PHP as a switch over from Perl (which had some powerul but cumbersome templating engines, and boiled down to much more boilerplate than PHP for the same task) or C-based CGI (that was not fun).
So, I see PHP as an enabler to webdev to the masses. It was really hard to do "dynamic web pages", as these were called back in the days, in anything else, and it was a breeze in PHP. I believe this is why many people started doing it, which in turn resulted in developing better frameworks for better languages (like Rails, Django, etc.).
Comparison with IE6 has been drawn. IE6 was the best browser in its day. The trouble is, it stayed dominant for far too long. The same could be said for PHP. If it was massively replaced by other alternatives by, say, the time PHP5 came out (which IMHO looks as the first PHP version that considered itself as a serious language; php<3 were gross hacks, php3 was nice, php4 was service pack to php3), then many woes now attributed to it would never have existed.
I personally use Django nowadays for any new projects I do, having done stuff in PHP before. I have a hate/hate relationship with PHP, I consider it a very bad language as languages go, but it's still invaluable for quick hacks, in which boilerplate for other system takes more to generate than writing the 10 or so lines of PHP.
I started using PHP as a switch over from Perl (which had some powerul but cumbersome templating engines, and boiled down to much more boilerplate than PHP for the same task) or C-based CGI (that was not fun).
So, I see PHP as an enabler to webdev to the masses. It was really hard to do "dynamic web pages", as these were called back in the days, in anything else, and it was a breeze in PHP. I believe this is why many people started doing it, which in turn resulted in developing better frameworks for better languages (like Rails, Django, etc.).
Comparison with IE6 has been drawn. IE6 was the best browser in its day. The trouble is, it stayed dominant for far too long. The same could be said for PHP. If it was massively replaced by other alternatives by, say, the time PHP5 came out (which IMHO looks as the first PHP version that considered itself as a serious language; php<3 were gross hacks, php3 was nice, php4 was service pack to php3), then many woes now attributed to it would never have existed.
I personally use Django nowadays for any new projects I do, having done stuff in PHP before. I have a hate/hate relationship with PHP, I consider it a very bad language as languages go, but it's still invaluable for quick hacks, in which boilerplate for other system takes more to generate than writing the 10 or so lines of PHP.
If we write for our peers, and you are a highly qualified academic, then your market is small. But if you just want to get the job done, you have many peers, and your market is enormous. And, at times, every one of us just wants to get the job done; and at times, each of us is so distracted or tired that our effective intelligence drops.
For market success, the ideal place to be is just smart enough to be able to understand the ivory tower issues that the solution needs; but dumb enough to relate to the everyman and agree with him ("Or walk with kings - nor lose the common touch"). Or perhaps it's idealistic vs. pragmatic - regardless, you need both.
For market success, the ideal place to be is just smart enough to be able to understand the ivory tower issues that the solution needs; but dumb enough to relate to the everyman and agree with him ("Or walk with kings - nor lose the common touch"). Or perhaps it's idealistic vs. pragmatic - regardless, you need both.
He also reportedly said,"Humans can't write thread-safe code. It's simply beyond us". (Can't find the source). I have heard him say at a conference that, PHP is for week-end warriors.
I've heard Joel Spolsky say that. https://stackoverflow.fogbugz.com/default.asp?W29083
I don't like PHP as a language and so it's not surprising that he admits to a shoddy, poor effort.
But I, too, dislike programming; languages are kludgey. (Ok, LISP and its derivatives aren't, but that's not solving the problem as much as reducing the problem set to one that can be solved.)
I like building things, and if to do that, I have to program, so be it. But I constantly feel like I'm building a house with Scotch tape.
But I, too, dislike programming; languages are kludgey. (Ok, LISP and its derivatives aren't, but that's not solving the problem as much as reducing the problem set to one that can be solved.)
I like building things, and if to do that, I have to program, so be it. But I constantly feel like I'm building a house with Scotch tape.
recent reddit submission & discussion on Rasmus:
http://www.reddit.com/r/programming/comments/anmgx/i_hope_no...
and the HN thread: http://news.ycombinator.com/item?id=1043400
and the HN thread: http://news.ycombinator.com/item?id=1043400
Let PHP be a lesson in what happens when you don't think before you code.
Not surprising at all.
When you're in the audience and he's keynoting, it doesn't feel like "Hee hee, lazy programmers are good programmers." It feels like "This is stupid and by extension, so are you, and why am I even talking to you about this?"
I don't think he's a happy person, either.
I don't think he's a happy person, either.
On top of all that, he actually remains a pretty cool and down to earth guy, as far as I can tell from reading his online stuff and hearing him speak a few times, which makes the snarky comments here seem even more juvenile.