

Ask HN: Why not PHP? - oldmanstan

Forgive me for the naive question, but: why is PHP considered so inferior to Ruby/Python?<p>And, as a beginner, do you recommend going with PHP to start with, or straight into Ruby/Python?
======
byoung2
_why is PHP considered so inferior to 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.

~~~
nwmcsween
Only vastly different programming language paradigms are comparable to
different languages. PHP, Ruby and Python are all relatively the same the only
real issue is being part of the 'community' of each language, if you are you
understand what to use, where things are going and what not to use otherwise
time is spent researching.

------
wanderr
I must be a lunatic because despite all its warts, I love PHP. There are a
fair number of gotchas with PHP, but I think the docs are generally great,
mostly thorough and usually easy to find what you are looking for, everything
is in one central place and user comments/examples can be incredibly helpful.
I'm able to write fast, efficient code in PHP quickly. It's not going to win a
race against C any time soon, but for what it is it's pretty quick, and of
course there are a large number of extensions available for it that are
written in C. I'm sure it's not the same for everyone, but the amount of time
it takes me to write code in PHP is significantly less than any other language
I've messed with.

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

------
neilk
The standard gripes about PHP:

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

~~~
bl4k
_"until relatively recently"_

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_

~~~
ahi
As far as I'm concerned, php5 was still broken until 5.3.
[http://php.net/manual/en/language.oop5.late-static-
bindings....](http://php.net/manual/en/language.oop5.late-static-bindings.php)

~~~
wanderr
We just got bit on the ass by this one yesterday. (still deployed on 5.2)

------
tef_
here is a quick outline of some issues in php through the years:

<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....](http://php.net/manual/en/language.oop5.late-static-bindings.php)
\- 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...](http://www.phpcompiler.org/doc/phc-0.2.0.3/representingphp.html#CONCRETETREE)
\- 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...](http://blog.php-security.org/archives/61-Retired-from-
securityphp.net.html) 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

------
jeroen
This thread about Mailchimp using PHP might be interesting to read:
<http://news.ycombinator.com/item?id=1818954>

------
kapilkaisare
I heard at a seminar once that PHP is easy to write horrible code and get away
with it. I think that's true.

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.

------
julius_geezer
Unfortunately, the question is harder to answer when put naively. How is a
beginner supposed to evaluate what somebody says about closures, lambdas, type
checking?

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?

------
cjensenius
You will receive as many different answers to this question as there are
people. Focus on patterns of software development, techniques, and less on the
specific language. It will get you further.

------
Locke1689
Security: depending on the framework PHP makes it easier to do the wrong
thing. Your web development language and framework should make it much
_harder_ to be insecure than to be secure. For netsec the other day I was
writing a deliberately insecure page so my students could practice session
stealing and I actually caught myself almost creating a SQL injection
vulnerability.

No one is perfect but some are better than others.

------
jaddison
Think of a simple problem to solve... and then solve it in a few different
languages. This way, you figure out what you like, because everyone is
different.

You might even be more focused in your learning and select specific frameworks
for each language - great exposure for you.

------
d0m
I think the best way for you to answer that is to try them all :)

------
runT1ME
Python may be the best language to learn if you've _never_ done any coding
before. Clean syntax, straight to the point, etc.

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.

~~~
Daishiman
Python is used by Google, Youtube, NASA, and Reddit. It scales, it's
faster,uses less RAM, and is much saner than PHP.

~~~
runT1ME
Woah. Do you know _what_ Google, youtube, and Nasa use it for? Not for
powering their applications. You might as well say Google and youtube use
_bash_ scripting, it'd be just as accurate.

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.

~~~
Daishiman
"Python is fast enough for our site and allows us to produce maintainable
features in record times, with a minimum of developers," said Cuong Do,
Software Architect, YouTube.com.

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

~~~
runT1ME
Wow, you're talking about Stackless, something a lot different.

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

~~~
Daishiman
Evidently you haven't read or used WSGI, Tornado, or Twisted in any
significant form. So Python sucks at multithreading, which doesn't mean that
there aren't some very good workarounds, and that multiprocessing works as
good as any other place.

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.

