Ask HN: Why not PHP?
Forgive me for the naive question, but: why is PHP considered so inferior to Ruby/Python?
And, as a beginner, do you recommend going with PHP to start with, or straight into Ruby/Python?
And, as a beginner, do you recommend going with PHP to start with, or straight into Ruby/Python?
When I studied English in college, I discovered that the English language is a very poor choice for writing poetry because it is a very rhyme-poor language. For that, look to French or Italian. English is such a mess of a language, with irregular forms and inconsistent pronunciation. But if you're not writing poetry, English is your best bet, because more people speak it than any other language. You're going to find more books written in English and people who read them, and more people who speak your language.
PHP is the English of the programming world. Python and Ruby have cleaner syntax and consistent programming conventions, but more people speak PHP. There are lots of resources for PHP and lots more developers who know PHP.
If you find yourself in a remote fishing village in China, you're more likely to find one person there who speaks English and knows PHP than one who speaks Italian and knows Ruby.
On the other hand, I have to say, I always felt french to be a better language for songs and writing.
Note: While the vast majority of my work these days is done in PHP, previously I worked almost entirely in C++. I've also used/dabbled in Perl, COBOL, BASIC, VBA, Java, Javascript, Python, AS3, Lisp. I've also looked at some Ruby code, maybe changed 3 lines of it in my entire life. ;)
- PHP's syntax is very random. There are over 5000 builtins and no consistency among them.
- PHP lacks (or lacked until relatively recently) many programming niceties such as objects, types, closures, lambdas, and namespaces. To do anything interesting, PHP developers rely on globals or dubious innovations such as using a string as a function name.
- PHP relies on a web-serving model where the program invocation is done in milliseconds. Even if you can (with difficulty) use PHP libraries in command line programs, it's very inefficient for anything like a long-running daemon process.
- Although it is almost always built into a web server, PHP doesn't make it easy for you to do anything useful with web requests -- such as custom authentication in a separate phase from content generation.
- Since it's a web templating language at heart, PHP practically begs you to do the wrong thing and mix presentation and data. To solve this, many shops use a templating language on top of PHP, which does feel kind of silly.
- Due to its ubiquity, PHP is the choice of script kiddies who can't program. The comments on the PHP.net documentation site are mind-numbingly naive sometimes. So even experienced programmers feel dirty using PHP.
That said:
- Among comparable languages, and for typical web serving tasks, PHP is fast. Really fast.
- It's probably already installed on your platform of choice.
- Within the web-serving paradigm, it has almost everything you would ever want.
- Its model of programming is really brain-dead, but it also can keep you out of trouble since you're forced to do everything in a REST-compatible manner.
- It's also the choice of websites like Yahoo, Flickr, Facebook, and Wikipedia, so you know it is battle-tested.
Compared to WHAT? Ruby and Perl? Cause I hope you're not saying it's C fast, or even java or C# fast...
if by recently you mean 6 years. almost everything else you said is also wrong.
op - use what you are most comfortable with and don't force yourself into whatever is cool or latest groupthink
(Edit: ok you got me.:
* PHP's syntax is very random
you are confusing syntax with the standard lib, which was inherited from C func for func (which if you come from an OO stdlib can seem 'random' - but it makes elegant sense in the old unix world where CamelCase object names didn't exist)
* PHP lacks (or lacked until relatively recently) many programming niceties such as objects, types, closures, lambdas, and namespaces
see php5 - 2004.
* Even if you can (with difficulty) use PHP libraries in command line programs
tons of daemon scripts run php - you are talking about a php3/4 problem (set_script_timeout etc.) see mailchimp post
* Although it is almost always built into a web server, PHP doesn't make it easy for you to do anything useful with web requests
this is what PHP excels at. want a function to retrieve the hostname from a URL? done. want to send a HTTP header? done. want to parse basic auth? done.
php.net/parse_url
$_SERVER
php.net/header
PHP was probably the first http/web aware language, you picked its strength as a weakness.
* Since it's a web templating language at heart, PHP practically begs you to do the wrong thing and mix presentation and data.
you can say that of any language, implementation-dependent. python and ruby also print to stdout which is just the web process as well. you think this because you have seen more php scripts that mix presentation and logic.
* Due to its ubiquity, PHP is the choice of script kiddies who can't program.
sigh
"relatively recently"
The key features of PHP 5.3.0 include:
* Support for namespaces
* Late Static Bindings
* Lambda Functions and Closures
PHP has a sort of support for types, but while you can say that a function accepts a certain kind of object, you can't express that a particular function takes an int or a string. That's really pathetic. It's fine if you don't want a language with types -- many great languages don't have them -- but only PHP thinks that stupid half measures are acceptable.
PHP has had objects for some time, but it arguably didn't work well enough until their second try.
It's true that PHP makes it very easy to get at elements of the web request, but what I meant was that it is trapped in the content-generation phase. The Apache API is very sophisticated and gives you full control over the HTTP response cycle, but PHP throws all that way, and turns Apache into a dumb teletype. So every PHP script that needs to do authorization is written in this silly inside out way; first you start to deliver content, and then you check if you're allowed to actually do so. Whereas the right thing is to check authentication and authorization first, and then never even call your content script if the user's credentials didn't check out. Apache nicely separates this out with their Authentication, Authorization, and Content phases, but nobody told PHP. Other web frameworks don't have this problem either (I've used some web servlet engines written in Java, and they too avoid the brain-damage of doing it all in the content-generation phase.)
As for daemon scripts, I have no direct knowledge, but there aren't a lot of people who would suggest it's a great language for a daemon. Even fork() can be problematic in PHP. I wrote a system that tried to use it that way and we ran into all sorts of reliability problems (none of which I've ever encountered writing similar programs in Perl).
I may be more behind the times than others, since I happen to have worked on three different PHP projects that all started around 2003-4 or earlier (and are still chugging along). After being bitten in the ass by various broken features over the years, most of them have adopted a very limited subset of PHP (some even refuse to use objects, to this day), and I can see why.
I mean, PHP can be confused by something as simple as loading libraries from different script files. Rasmus' official advice to us was to have one "loader" script that included all the libraries in one shot. I find it hard to respect a language that has difficulties with things like this.
this is why you can't do $a = foo(1,2,3)[0] in php.
also why this won't happen any time soon.
I also think there's a fundamental problem with this question. I think one must make the comparison between web development frameworks, rather than saying PHP/Ruby/Python - you need to say Symfony (or PHP framework X - I just happen to like Symfony), Rails or Django (or Spring or Grails or whatever).
In that case: the comparison is simple and personal. Go to the Symfony tutorial, go do the Django tutorial, go do the Rails tutorial. See which one clicks the best.
I personally find PHP enjoyable to use because I've used it for a while and I'm used to it's idiosynchracies. I've used it for web development but I've also used it for command line daemon processes that have run, without fail, for the past 3 years.
I've never had cause to benchmark those processes in terms of performance with any other language because I've never run into performance problems, but your mileage may vary.
In short: I think PHP gets a lot of bad press - but PHP also gets a lot of things done.
This is one thing that really annoys me about PHP...for example there is stripslashes() to remove slashes but strip_tags() to remove html tags. Why couldn't they be consistent about using the underscore or not using it. Another one is array_push($array,$var) which takes the array as the first argument and the $var to push as the second, whereas array_search($var,$array) has it in reverse.
http://phpxmlrpc.sourceforge.net/#security early and naive implementations of xml parsers in php used eval, and as such were terribly insecure and hacked en masse
http://php.net/manual/en/security.magicquotes.php -- man, if only we wrapped string on a ini file setting, it wouldn't prevent injection attacks at all, really all it means is that the standard library isn't portable any more as the semantics and return values can change on a site basis.
http://php.net/manual/en/security.globals.php 'you know what would be good if we could trash variables from the browser' 'we've turned it off now, good thing that people won't turn it back on for older scripts, and it will affect every script'
http://php.net/manual/en/language.oop5.late-static-bindings.... - a dynamic language with an early bound oo implementation? sure we'll fix it, we'll just make the keyword for dynamic dispatch 'static'
http://php.net/manual/en/language.namespaces.php - the namespace character is the string escape character. I mean that will never backfire if people don't use 'variable functions', or using a string to lookup a function http://us.php.net/manual/en/functions.variable-functions.php lets hope we never have to put old code that uses this into a namespace.
http://php.net/manual/en/control-structures.goto.php man, should we implement a subset of goto or, should we do named breaks. nah goto is far more awesome.
http://use.perl.org/~Aristotle/journal/33448 - how do we fix a security vulnerability? why checking to see if an int is bigger than INT_MAX
www.trl.ibm.com/people/mich/pub/200901_popl2009phpsem.pdf - the implementation and semantics of php don't match up. it doesn't do what it says on the tin.
http://en.wikipedia.org/wiki/PHP_accelerator - php by default doesn't cache bytecode, unlike, nearly everything ever, for commercial reasons, as zend sell one as a product.
http://www.phpcompiler.org/doc/phc-0.2.0.3/representingphp.h... - the grammar is terribly broken, so much so it is nearly impossible to do obvious and useful things like foo(1,2,3)[0]
http://blog.php-security.org/archives/61-Retired-from-securi... the development team is toxic and reluctant to provide actual solutions for security
there are many php builtins which have vague return values which change indeterminately between releases and arguments, which forces you to use == over === for some comparisons unless you want your code to break unexpectedly.
the moral is: for everything they've fixed, they've often fixed by duct taping over the original errant feature. the standard library needs to be wrapped to be consistent. security or performance isn't a priority for the open source versions.
this won't bite most web applications as many of them are simple templates around a database.
with larger applications or frameworks, php struggles
Having said that, I think you're more likely to see bad code coming from really, really bad programmers who started out with PHP 4. This, and the fact that my first PHP codebase came from a setup where register_globals was enabled which allowed for strange variables to pop out of thin air, made my experience with PHP one I am happy to leave behind.
I would be surprised if the code quality of recent PHP projects is as bad as the older ones. From memory, I can advise you to stay clear of Joomla and phpBB - although circumstances may have changed.
Learn OO in PHP first, then pick a framework over a CMS to cut your teeth on, and you should have a good start.
EDIT: And please, oh please, whatever you do, don't mix your business logic with print/echo instructions.
I would recommend learning Python. Python for Windows is a very handy environment; you can fool around with Google App Engine if you care to, or run Django or whatever locally.
I would recommend rephrasing your questions along these lines: I am a beginner interested in starting with web applications. What languages and frameworks do you think most promising to learn on, and where can I find good examples to illustrate the principles?
No one is perfect but some are better than others.
You might even be more focused in your learning and select specific frameworks for each language - great exposure for you.
However, I'd say Ruby fills the RAD a bit better than Python, and Python is is not a language that scales, so aside from little scripts it's not exactly a language that's conquered a niche.
Go with Ruby or Java if you plan on making something useful right away.
And Reddit is having a ton of scaling problems. The thing can't even support multicore . I'ts 2010 and you're telling me a langauge that can't handle multicore properly scales?
Oh. and don't mistake my python smack talk for defending PHP. PHP is the devil. I'm just not a fan of python.
"Python enabled us to create EVE Online, a massive multiplayer game, in record time. The EVE Online server cluster runs over 50,000 simultaneous players in a shared space simulation, most of which is created in Python. The flexibilities of Python have enabled us to quickly improve the game experience based on player feedback" said Hilmar Veigar Petursson of CCP Games.
So, yeah, you're completely wrong on all counts. And if you think multicore is the only way to do multiprocessing, you should probably go back to Operating Systems 101, or study the actual reasons why Python is or is not good for multiprocessing. The correct answer would have been the GIL and multiprocessing limited only to blocking IO calls.
At any rate, if you had actually used this for a real scaling problem, you would have realized that you spend 95% of your time waiting for IO on most web processes, so the choice of language is almost irrelevant so long as RAM usage doesn't get exceedingly high.
>he correct answer would have been the GIL and multiprocessing limited only to blocking IO calls.
I'm familiar with the GIL, however I don't think you are.
> you would have realized that you spend 95% of your time waiting for IO on most web processes
hahahaha. This is funny, because I know why you think this. See, because Python doesn't do multi threading, you spawn up a seperate process for every web hit. Then of course you have to hit your cache servers or DB, hence waiting on IO.
See, when you graduate to big kid programming you'll realize that 1997 called and they want their architecture back, and instead it's much better to have a mature platform that handle multiple concurrent web requests from one VM, hence they can share a cache, so no, I don't work on apps that spend 95% of the time in IO because if that is the case you're doing it wrong.
Btw, if you HAD tried to use Python on any significant way, you would have known that WSGI on Apache recycles the VM for multiple requests, which is the reason why it's suggested to do static file serving outside of Apache within the same server.
And, oh yeah, I have yet to hear from anyone except people doing CPU-intensive processing have the programming language be the bottleneck. Congratulations if your system is CPU or network-limited, in which case I'd hope that you're writing something in a lower-level language to handle the situation, but in 99% of large site installations, even if you cache all your IO, it's still going to be the big bottleneck of your system. Seriously, opening a remote socket and sending shit through it is almost always a bigger issue than pushing HTML.
Finally, it still doesn't change the fact that some of the biggest web sites are running Python in the back end and they couldn't be happier.