Live data from Hacker News

Some surprising quotes from Rasmus Lerdorf (php creator)

en.wikiquote.org

91–100 of 112 posts

Re: Some surprising quotes from Rasmus Lerdorf (php creator)

#91
post #35

Earlier quoted context omitted.

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 u…

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.

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.)

Re: Some surprising quotes from Rasmus Lerdorf (php creator)

#92
post #43

Earlier quoted context omitted.

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 Hello Martin 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 webpag…

> 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…

> 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.

Re: Some surprising quotes from Rasmus Lerdorf (php creator)

#93

Earlier quoted context omitted.

> 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…

> 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 t…

> 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)

Re: Some surprising quotes from Rasmus Lerdorf (php creator)

#94
post #62
post #38

Earlier quoted context omitted.

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.

Even if you're right, the point is that it degrades the site for everybody if you engage in it.

Re: Some surprising quotes from Rasmus Lerdorf (php creator)

#95

Earlier quoted context omitted.

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 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…

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.

Re: Some surprising quotes from Rasmus Lerdorf (php creator)

#96

Earlier quoted context omitted.

> 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 t…

> 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 cri…

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.

Re: Some surprising quotes from Rasmus Lerdorf (php creator)

#97

Earlier quoted context omitted.

> 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…

> 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.

But so is JSP, ASP, Mason, etc.

Re: Some surprising quotes from Rasmus Lerdorf (php creator)

#98

Earlier quoted context omitted.

> 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.

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).

Re: Some surprising quotes from Rasmus Lerdorf (php creator)

#99

Earlier quoted context omitted.

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.)

Re: Some surprising quotes from Rasmus Lerdorf (php creator)

#100

Earlier quoted context omitted.

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).

[deleted]
Post reply on HN