Hacker News Reader

Comment by Osmose | Hacker News Reader

I'm going to be unfair and quote just two words from the article:

> empowered amateur

PHP is a gateway drug to web development. And that's awesome.

With almost every other popular web development language I've heard of[1], there's this grey area between "my app works on my local machine" and "my app works on the server" that is really hard to grok as a beginner. There's a reason entire businesses are built on the idea of making this easy.

With PHP? You get an apache box with PHP, you put the files up, and you're done.

For a professional web developer? PHP is probably nuts. I've purposefully left out things like PHP frameworks, setting up a database, or doing any sort've advanced web development. And yes, it is possible to create a large, successful, stable web app with PHP. It seems kind've hard given the legitimate criticism in the article.

But, honestly? Once you've started doing web development, you should be able to improve your own skills without the community pushing you. It's the people who are just starting out who need all the help they can get.

[1] Which isn't at all exhaustive. I'd love to hear about alternatives that are beginner-friendly.

View on HN

I agree with you and I'm really surprised in 15 years, or how over old PHP is, THERE IS NOT ONE SINGLE ALTERNATIVE!!

Why? For PHP I sign up for one of the million LAMP ISPs, I upload a .php file with .php embedded in HTML and I'm done.

Where's the Ruby version of this? The Python version? The JavaScript version? The Perl version? THEY DON'T EXIST. You wanna use Perl or Python. You either have to use slow slow cgi or you have to RUN YOUR OWN SERVER. (virtually or otherwise)

PHP sucks, I hate it. I don't code in it unless I absolutely have to. But it's not the language that makes it popular. It's the combination of pre-installed + no setup + plus faster than cgi + works on a shared host + inline templating that's made it popular.

mod_perl? mod_python? As far as I understand them they're not useful on shared web servers so they don't fit the niche PHP is filling. Node? Ruby? They are the server rather than a plugin for apache. Again, not filling the same niche.

Someone with some chutzpah needs to step up and bring the EXACT SAME COMBINATION OF FEATURES except with a different language to the Web. They can be rich writing books and running conferences.

Ok, now, I suspect most would want this to be in Python or Ruby but I'd argue if you really want it to succeed make it JavaScript. Because most PHP programmers have to learn JavaScript as well for their webpages. Less to learn = more likely to succeed.

But honestly, if anyone could get any of those languages to fill the niche PHP is providing it would be a huge boon over today.

> Where's the Ruby version of this? The Python version? The JavaScript version?

heroku ? you don't even have to upload anything manually, a single command deploys your app.

That's not the same level of beginner friendly.

With PHP, you have a file with a .php file suffix on your server.

That file has code in it. Navigate to that file on your browser. You have a dynamic website.

No installation of external programs is necessary. No terminal. Often, you don't even need an FTP client, since you can use your hosting provider's GUI.

That blinding level of simplicity gets the non-programmer started in under an hour.

To run Heroku (on a Mac), you need to download (1.8GB) and install XCode (or another version of GCC for Mac, but the moment you say GCC, the beginner's eyes glaze over). Once you install XCode, you need to open up terminal (no GUI). Then you install homebrew in order to install the dependencies that Heroku tools require (some JSON libs, if I recall). Once that's installed, you need to install the heroku cli tools. Now you can deploy your heroku app, which requires registering (or, in the case of beginners, generating) ssh keys.

Every single one of those steps is too difficult for the beginner. That is why PHP wins.

Sadly you are right. Ruby has no equivalent and Rails especially is not for beginners.

man, you can use pagodabox and go from dev to prod with one line of code as well.

We don't WANT to replicate PHP's deployment model! It's hard to scale, it's hard to configure, it's hard to secure, it's hard to make work across different web servers. It's convenient for newcomers, sure, but even for something like phpbb the model is strained. We need better deployment tools, not worse forms of deployment.

mod_python was notoriously unstable and is now disgustingly obsolete, it has been replaced by mod_wsgi for some years now (with the additional advantage that apps which work on mod_wsgi will work on many other servers).

The reason you have trouble deploying Python is purely that the hosts you are trying to use CHOOSE not to support it.

You can get really excellent, easy $10/mo Python hosting but if you ask for 'free,' beggars can't be choosers, so you will get whatever they feel like giving you. This is not a function of the underlying technology.

Don't blame other languages if you have not ever figured out how to do anything other than PHP

Well this is why I guess php wins. Because the other communities have complete disregard for what the common newbie considers valuable.

The question is whether something matches php's economic model. If the answer is no, its no.

You can get the hosting for $x/mo is not an answer nor a solution for most people.

Instead of blaming "the other communities" blame the web hosts which decide that they only like to support PHP out of the box. Many other languages can be made easy to deploy on shared hosting, it is up to the host to actually do so. Nobody can force them.

> You can get really excellent, easy $10/mo Python hosting...

Any recommendations? I need one for a small biz (in the US), so this is a serious question. I would pay 2-3x that much for a "really excellent" platform I could build a business site on without having to be the entire sys admin.)

Webfaction[1] is really quite good, and well inside your budget. It's shared hosting, but it's good shared hosting, and they're very Python friendly. One click to create a Django app, and you can easily install your own frameworks and stuff. Depending on what your neighbors are doing you may get varying performance, but what can you do?

If you need more reliability than shared hosting can give you, then you either head into the VPS/IaaS/dedicated space (and need to do your own sys admin stuff), or you head into the GAE/Heroku/PaaS space (and need to pay a lot more).

There are always tradeoffs. :) (And no, I have no reason to recommend them other than being a happy customer. <shameless>...unless you want to use my affiliate link[2] to sign up, of course.</shameless>)

[1]: http://www.webfaction.com

[2]: http://www.webfaction.com?affiliate=chaos

The Perl equivalent to the PHP model (request handler entry point is already your template) is called Mason. It's had a pretty huge customer for about a decade now.

http://www.masonhq.com/?AmazonDotCom

I find it odd how many people keep saying it's that simple to push PHP code to a box and get it working. Sure, if you've got crazy simple requirements it's generally a cinch. Once you do anything remotely non-trivial (want to read from a file? use some third party library, handle errors in a consistent manner) then you start hitting into issues with file permissions, PHP version differences, modules not compiled in by default, etc etc. I've been dealing with PHP for a long time, and getting a local dev setup to match the remote version (or getting code to work on both environments) is just a pain to do.

Also, PHP is not helpful in local development. I think there's a built-in runserver in the newest versions, but for all of history, to develop PHP you had to install (and set up) apache and all your required modules locally.

With python and Django, I use virtualenv+pip to get a consistent environment, manage.py runserver to test locally. I can pretty much start developing everywhere (my desktop, my VPS, my laptop, that same laptop after I reformat it and install some new distro to test) with 3 commands.

I think you're mistaken to assume the beginner even has such a thing as a local development environment. When first learning PHP I wrote all my code on a $10/month web hosts, saving directly to the FTP server.

Only later did I install a local dev (now made very easy with MAMP), learn about version control, PEAR etc.

Yes, this is why PHP is easy for beginners. The standard practice is to edit directly on the server. It's a hard habit for a lot of PHP devs to break. It's very straightforward and direct: Edit a file, hit reload, see the result live.

Something like, e.g., Heroku is awesome, yes, but not only do you need to learn how to debug a thing which you can't really touch in production, not only do you have to master the distinction between "the file I just edited here" and "the file on the remote machine"… but you have to use Git for that. I love Git, but years of watching PHP devs try to figure out Git have taught me just how intuitive it isn't.

Sure, if you've got crazy simple requirements it's generally a cinch. Once you do anything remotely non-trivial (want to read from a file? use some third party library, handle errors in a consistent manner) then you start hitting into issues with file permissions, PHP version differences, modules not compiled in by default, etc etc.

Although PHP suffers from this, I'm not sure it is alone. I suffer a lot of pain setting up Ruby environments (I don't think I've ever managed it the same way twice) and getting everything to play nice. Even Python, a language I am about as familiar with as PHP, has it's annoyances on this front.

I suspect the difference is familiarity; I can deploy a working PHP environment in my sleep, because I've done it so many times.

The other day I had to set up Java/Tomcat - literally the worst experience of my life...

You're thinking like a seasoned pro :) For a newbie there is xampp - a familiar looking windows installer configures the Apache/PHP/MySQL (and others) stack, then it disappears into the backround and, largely, can be forgotten.

This is huge for a new developer.

Think about it this way; if you had a class called "Learn to Write Websites", for absolute beginners, I argue PHP is a good initial choice. Because you don't have to worry about the environment, how to server it, command line, package management - which, say, Ruby would require. You just chuck in a brief overview of how servers work in general, and then get them working on some PHP scripts, with instant results.

I love this!

I like Ruby, of course - it's powerful, has modern standards, and Rails is brilliant. But for a beginner, and even moderate, developer it is a bit of a pain to work with.

This sort of thing (http://pypi.python.org/pypi/virtualenv) is non-trivial for a beginner.

I'm not trying to defend PHP too much here; I like it, but it is a horrible language on many levels (as are other languages).

It also just works, especially for beginners.

I have a feeling you've gotten so used to deploying PHP that you've forgotten all the headaches involved in it. I idle in about 3 irc channels that provide PHP support, and pretty much every day someone comes in with some deployment related problem. Someone will come in complaining that they can't read some file (the user apache is running as can't traverse into that directory), complain about some missing function (did you install gd? -> show how to get phpinfo -> show how to install gd -> show how to modify php.ini to enable it -> show how to restart apache), or just general errors on their server (is your error reporting on? -> figure out what error reporting is locally -> figure out what error reporting is remotely -> explain how to change the setting -> etc.)

I'd consider myself a seasoned PHP dev and it always takes me a few hours to figure out what happened when I get the white screen of death.

XAMPP isn't any sort of solution to this, because not all servers are configured in the same way that XAMPP is (and the fact that they compile in most packages doesn't help).

Developers at a local makerspace did a project last year using PHP, and even though there were tons of very smart guys, mostly everybody we brought onto the project took a whole afternoon to get set up. To me that's unacceptable.

Understanding how to set up virtualenv isn't trivial for a beginner, but that doesn't stop a beginner from jumping into my python projects with no pain. All they need is to get easy_install (which is included in all distros I've seen) and do a git/hg pull (both probably also available from distro). The rest can be handled by a shell script in the repo that grabs pip+virtualenvwrapper, sets up the virtualenv and installs all the required packages. Then you tell them "if you need to work on this project, just type `workon projectname`", and with that they're ready to start hacking.

I have a feeling you've gotten so used to deploying PHP that you've forgotten all the headaches involved in it.

That's precisely my point! :)

and even though there were tons of very smart guys, mostly everybody we brought onto the project took a whole afternoon to get set up. To me that's unacceptable.

As mentioned, I can rattle out a PHP environment in minimal time (basically as long as it takes for the installers to run). But task me to work on a Python project, or Rails, it will take a lot longer.

I think my larger point was that for an absolute beginner PHP offers some key advantages over other languages (even you simple description of jumping into Python involves some major pain points - like using Linux, the command line, package management, what is git/hg?).

The advantage to PHP is purely that it is intended as a web language; Python, Ruby et al require additional steps to get to that stage (or, at least, steps that are not braindead-automated for beginners).

I'm not trying to defend PHP too much here; I like it, but it is a horrible language on many levels (as are other languages).

I started writing a long rant which essentially boiled down to exactly that - PHP may be shit, but so is everything else. I hate all the languages that we're stuck with, and every time I start a project it's more a matter of picking the least shittily inadequate tool for the job than a matter of picking a language that I actually like, because there are none. They quite seriously all suck, very badly in most cases. The pain comes in different places, in varying degrees, but it's always there, whether it's coding pain, tools pain, ops pain, installation pain, documentation pain, etc. I have yet to find a development stack that didn't make me want to scream "fuck!" at least a dozen times over the course of a week of using it.

The real problem with most non-PHP stacks is that they front-load that pain: I have to say "fuck!" and hit Google many more times before I see a page generated from Ruby, Python, Scala, C, Java, or Haskell running on my webserver than I do to see a dynamic PHP page. Is it any surprise people tend to go with PHP pretty often, given that?

I think detractors would be wise to focus a little bit more about what's awesome about PHP, rather than what sucks about it (there's a lot, nobody argues otherwise). Because there's got to be plenty that's great about the language (or perhaps the environment overall) if it attracts people in such large numbers. We should be trying to add that to other languages/environments, not merely looking down on the newbs that still use PHP.

And what "EXACTLY" is the problem with having a devlopment system that mirrors the live production one?

I worked at one place where our hardware guy who wanted the dev test and live systems to come from the same production batch from SUN just to make sure there where no strange MB rev problems.

Ok having identical hardware is high end but seting up a system where your running the same linux distribution an the same version of mysql php etc is not exactly rocket science.

I can attest to PHP deployment being an absolute nightmare. Of course, the difference is that we're not beginners here; far from it, really.

While the beginner will love being able to open up an FTP client (probably one that's a browser extension) to upload a few files they've changed, that's not going to fly for us.

We want proper deployment, source control, and for it to be used properly. We don't want to go anywhere near patching code directly on the live server. Just make sure the fixes are committed, nothing's broken, and run the deployment script of choice.

The requirements for 'simplicity' are completely different. And it's for this reason I think Rails and Django* and the like become attractive prospects for developers who want a more reliable, consistent environment.

* I'd struggle to list a PHP framework here because each one has a different vision of what the 'PHP way' is, probably because there is no 'PHP way'.

I don't understand how deployment, source control and not patching your live code have anything to do with PHP.

Keep your source in a svn or git repo, export the new release branch or bug fix release to a testing box and once you're happy move it over to production. What does any of that have to do with PHP itself?

If you're talking about moving from one version of PHP to another, just compile the new version of php in a different directory from the old version (e.g. /var/lib/php/5.4 ), create a new virtual server definition in apache and point it to the newly compiled php version (e.g. using Apache's mod_fcgid) and test your site. Once you're happy, make that virtual server live to the public and retire the older one.

For all the "script kiddies" writing PHP they don't have to setup a server. Sign up for a $5 a month LAMP web hosting site. Done.

Even those that do run their own server many linux installations have options to install the AMP part of LAMP by default. Again, nothing to do

It's not awesome if the applications so developed by amateurs grows to store PII, financial information or do anything that has any security consequences whatsoever since it is likely to be riddled with "game over" security vulnerabilities.

Unsurprisingly, most PHP applications end up in this state. Cf. http://web.nvd.nist.gov/view/vuln/search-results?query=phpbb... - and phpbb is one of the popular ones with an active community...

Most applications developed by professionals in Big Freaking Enterprise Languages working in regulated industries will also have game over security vulnerabilities. Most applications developed by the cool kids in Ruby/Python working for startups will have game over security vulnerabilities.

The current state of information security: basically, we're screwed.

Agreed. While PHP apps are definitely more likely than others to be vulnerable to systemic SQL injection, XSS, and other vuln classes of that sort, all applications are equally vulnerable to things like command injection, authorization bugs, etc. No one gets that stuff right, and if you can execute code on the system, well, it doesn't really matter if you can't find SQLi.

Why is PHP more likely than others to be vulnerable to SQL injection attacks? Most people (and likely All newbies) will be using PDO which automatically protects them.

It's only a protection if properly used. Bound parameters don't work well for some types of dynamic queries.

How do other dynamic languages (e.g. Ruby, Python) deal with this?

Also, if you've reached the point where PDO is too restrictive for what you want to do, you should be knowledgeable enough to write your own db class that incorporates sql injection protection (since all that largely consists of is escaping strings).

This is why:

http://www.google.com/search?q=php+mysql

Searching for PHP and MySQL yields tons of tutorials, code examples, and documentation related to the now-deprecated mysql interface. When I wrote my first comprehensive PHP application last year I spent half a day trying to determine best practices before finally settling on PDO. Newbies won't go through that effort, and will naively land on mysql rather than PDO or mysqli as likely as not.

There's a lot of tutorials, and that makes PHP bad? Sure the tutorials don't teach what you prefer. This just seems like a silly argument.

It's not a matter of preference: it's a matter of secure or insecure. The mysql extension for PHP doesn't support prepared statements and as such is inherently less secure than any other mechanism for working with MySQL (The mysqli extension and PDO being the two alternatives for PHP). But losvedir's point is that the number of tutorials that use the mysql extension's API far outweighs the number of tutorials that use PDO or mysqli, and that those tutorials are often very poor quality (ie: contain SQLI).

Actually, I agree with you and I think this is often missed as one of the main contributing factors to PHPs bad rep. If I had enough spare time (and a wider personal network of php pros to draw from) I'd love to make something like www.betterphp.org with short tutorials and guides teaching newbies the current best practices. As it is, anyone picking up PHP for the first time is confronted with a minefield of conflicting and out of date information, some of which is dangerous.

PHP has been around forever and Google has a long memory. Unfortunately, for every good blog post/tutorial on PHP development there are 100 or more bad or out of date ones.

PHP sites will have a hell of a lot more of them, though. You're not shielded against CSRF, XSS or SQL injection attacks unless you use a framework - at which point you're back to being a programmer with no "empowered amateur" in sight...

Hell, for most of then you aren't even protected against remote code execution. Google for "PHP arbitrary script execution" and weep.

I posit that one of our modern "Things You Can't Say" is that the widely-held belief that the world would somehow be better if every single average Joe learned to program just might be totally bogus.

As was pointed out by djmdjm below, there are Real Consequences when amateur hour overflows into the real world. In many cases it simply would be better had many of these apps not been made by the unskilled - even if that means they hadn't been made at all.

What's so wrong about a barrier to entry that is effective against those who have not yet figured out what the fuck they are doing? We learned despite such barriers, did we not?

You can put up whatever barrier to entry you like. Invent a certificate for Haskell programmers with Ph.Ds. Require everyone who works on your website to have your certificate. Have fun.

But most of the world will tell you where to stick that certification and will cheerfully walk around your "barrier to entry". Then they will hack together a web page using whatever programmers and tools they can find, certified or not, because web pages are very important in the twenty-first century and even the lousiest, slowest, buggiest PHP site is often more valuable than a paper sign stuck on the wall, an entry in the Yellow Pages that nobody reads anymore, a bunch of people sending individual text messages to friends-of-friends, or a static web page from 1997 with a little animated GIF on it.

I wonder if that's only true because we as a society don't (yet) hold people accountable for the code they write, in the way we hold them accountable for the bridges they build or the cars they manufacture?

I wonder what the costs of, say, the Gawker password database breach were? Or perhaps the Sony DRM rootkit on CDs? (Or Apples unpatched Java bug?)

What if the people who wrote and/or deployed the code knew (before they shipped/installed it) that they were going to be held responsible for the costs of any future failures? My guess is we'd then have training and certification and insurance, and professional organisations rising up to certify people as being skilled enough to qualify for insurance for themselves and/or their companies. Much like "Engineers" (who's titles the software industry loves to assume) or "Pilots".

I can torture the "Pilots" analogy further - much like you can do very little training to get a car license, perhaps you'd be allowed to write software that affects only a few people at once, your family and friends, perhaps a colleague or two, even occasionally a stranger, but never more than 6 or 7 other people at once. If you want to store data for more than 6 or 7 people, you need a different class of license - a mini bus license for a dozen or two, then a full bus license, then a train or passenger jet license...

Who _should_ be held responsible for a website's password database getting compromised? At what stage in the progression from "shared GoDaddy hosted out-of-date-wordpress blog about my cat" to "Gawker network with a million or so login credentials inadequately secured" do we draw the line and say "Here is the line in the sand across which more care needs to be taken, and lines of responsibility drawn up and accepted"?

'Cause _surely_ there _should_ be that line somewhere, right?

Even if hypothetically, such a barrier to entry was desirable, it's not viable to maintain one. It'd be treated as damage, and routed around. It's better in the long term to funnel people through something which teaches them the "right way" from the start, by making that "right way" easier than anything else.

We are not good at this.

Interesting point, and I agree that PHP has some properties that make it easier for beginners to get started with (which doesn't necessarily make it the best language to learn with, but definitely an easy one). I wrote my first few programs in BASIC before I graduated to C. Like BASIC, PHP makes it easy to get something running quickly, and horrible to do anything more complex.

The problem comes in when people don't quickly figure out that the language that they started out in should not remain their primary language for any serious project.

web2py is a good alternative for beginners.

Reply on news.ycombinator.com