Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> PHP must have done something right, no?

Shitloads of people also believe in organised religion or naturopathy, doesn't mean that's a good thing.

> PHP is the best web platform... ever.

So because it's nearly caught up with other languages and you can install stuff easily if you have the prerequisite of knowing about composer? Bullshit.

I'm sure composer is great, but if your main argument is that PHP requires zero previous knowledge you can't really use that.



Honest question: Do you have more than a months professional experience writing modern PHP?

While I love appreciate the Java ecosystem with amazing stuff like Play framework, Scala, Camel (several apache sub projects actually), Python micro frameworks etc there still is something magic about PHP. I still haven't made up my mind but there is something about really fast turnaround time, transparency, and shared nothing from the ground up. Maybe "Just Works" is the word. (Cheap hosting and next to zero installation just to be an argument but I guess Play is even better in this regard.)

(background: I am allowed to be opinionated on this (programming since I was a kid) professionally mostly Java but also PHP (greenfield, maintenance), and since this is also my hobby I have also scripted non-trivial python, tried rails back at 1.0 etc.)


I have years of professional experience writing PHP.

It's much slower to develop in or get up and running than any other language I have experience with.

Now it was faster when I had no experience, absolutely. That's solved with a few hours of reading docs and playing around. Then the other language is likely faster turnaround, easier to setup, etc.

And besides I'm not even convinced that "easy to set up" is a metric you should be using when you are deciding on a language for a non-trivial project.


I'd argue PHP is, for any project of reasonable size, harder to get up and running than say Rails. For any serious development a PHP developer (some experience, did several years of PHP dev) will have to setup a local instance of Apache/ MySQL/ PHP and deal with making sure libraries installed on this dev server match libraries on the production server.

When it comes to deployment for both Rails (in this case) and PHP you can choose between pretty automated providers like Heroku/ PHPFog which make git deployment trivial or you have to deal with server set up and configuration.

So I'm not really sure these days that for anything except the smallest projects PHP just works any more than any other reasonably popular web language?


PHP 5.4 has a local development server, so even that point is moot. But how hard is setting up apache, mysql and PHP?

sudo yum install apache php mysql

done.

And anyway, for a serious project you need a local dev environment that somewhat mirrors live, and then staging (which exactly mirrors live).


And what % of PHP devs alive today will ever be able to develop in modern PHP without dealing with abhorrent hacks and 4.3 code because the entire ecosystem is a giant cesspit of attempts to work on shit old shared hosting that have never been upgraded.

To clarify, I know that PHP 5.4 is getting to the point of a modern language (despite lacking the deliciousness and usefulness of modern interpreted languages like Ruby and Python), and despite that it's still a complete mess of inconsistent standard library and weird not-quite-deprecated extensions, but the attitude it has fostered, that DON'T GIVE A SHIT JUST MAKE SOME STUFF DUUURRRRR has meant that PHP is essentially the bane of everyone's existence.


Agree it's not that hard, I also don't think it's in any way a bad thing to have to learn how to do it (in fact probably a good thing). Just that learning how to do that is no easier than learning to deploy a rails/ django/ etc app so I'm not sure PHP really 'just works' any more than any other popular language.


You're comparing it to frameworks. You don't need a framework to handle URL routing, input parsing, output headers, etc. You save a PHP file and it's a URL; no routing. The query string, POST body, request headers, uploaded files, etc. are already parsed and sitting in variables in your global namespace. Output will automatically go to the web server, with the appropriate headers already set. No downloading or configuring of frameworks, no deploying. It "just works", to the point that an empty .php file with no source code at all is a working URL.

You can have a framework, you can do your own routing, input parsing, output sanitizing, and all the other things Rails/Django do. But unlike Ruby/Python, you don't need to just to get started on the web.


PHP is really a framework. It includes builtin routing, builtin request parsing, builtin templates, etc. All very tightly integrated. And it is definitely not just an interpreter or library.

And a lot of what you are listing as "just works" are misfeatures which break things and make life unnecessarily hard down the road. They are time bombs, because everything will seem OK up front and the problems won't occur to you until they are already serious and chronic.

There IS routing, it is just implicit, magical routing performed by the server by inspecting a filesystem (e.g. the same filesystem where you have code, databases, password files, configs, etc.) Exposing my internal project organization publicly as a grody looking URL scheme that will become enshrined in all my links? Oh boy!

I don't WANT everything magically parsed by default, regardless of whether I need it for this request. This must happen when and how I specify or the tool is useless to me. Also: it is not a POST body, it is a request body. What do you call the body of a PUT? (And this kind of mis-education is another PHP misfeature)

I don't WANT random mistakes like leaving empty files to pass silently. I want bad code to fail early so I can easily detect the presence of a problem, and locate it. There is nothing worse than silent failure. If you think that silencing errors "just works" then you have your head in the sand. Don't think that users don't notice when a site is broken.

You can use a builtin framework which behaves inappropriately by default and then rewrite later, but why would you actively choose to do this? I think that most people do not choose to do it, because they just don't know. That is why this topic keeps coming up.

It is nice to nurse people along, but it is not nice to require them to nurse your tool along continuously because of all its broken behavior. Their time is better spent working on their own code rather than nursing yours. So perhaps other frameworks could somehow do an even better job of nursing users along, and those specifics are worth discussing. But that doesn't mean the right answer is to hook people on PHP's builtin framework.

And by the time you dress up PHP with a third party framework and other tools to make it fit for use, which you can certainly do, it is absolutely not easier than frameworks in other languages.


Rails and Symfony were pretty much the same framework 3 years ago. Now Symfony 2 is doing things that Rails doesn't. The sheer number of programmers who use PHP versus the amount that use Ruby means that good software in PHP will evolve faster than good software in Ruby.


No, the sheer number of programmers who use PHP just means that there's a much higher signal-noise ratio of half way decent code.


I'd say setting up Rails or PHP takes pretty much the same amount of time unless you need a really specific custom setup.

Plus of course Heroku has simplified it down to git push so setup times are a bit of a given now.


Hahahahaha! No, Heroku has simplified it down to:

- git push

- fix all the stuff Heroku complains about regarding which assets have to be precompiled and where

- repeat until someone who's used Heroku a long time knows your specific problem


I started writing PHP about nine years ago, I'd say about five years of that was within a professional context. I can elaborate more if you like but whilst I understand PHP can be used in an effective way in the hands of someone that understands all the nuance, and I know that PHP enables people to start hammering stuff out with ease, it also enables people that don't know the nuances of the language to write utterly shit code that people like me have to deal with for ages on out. It's as if the low barrier to entry, shit, actually means that the door is wide open to cowboys who just abuse shit to go wrong.

Of course you can write decent PHP, but I've since switched to Python (which I really enjoy, but I'm not biased toward it, I can equally imagine people writing decent Ruby or whatever), but I'd never look back. It's an enabler of people who care little, not for the love of code, or the technical beauty of things, but an enabler of people who don't give a blind fuck about whoever is the next person to inherit their code. No, this is not necessarily a language flaw (because there are many of those, I don't have to elaborate), but what's lauded as the brilliance of PHP, especially lately, is an attitude that fucks people down the line. Look at osCommerce FFS.

I mean, perhaps now osCommerce is a decent product, but it wasn't in 2003, it was a godawful mess, and this is relevant now because there a bunch of hapless fucks that are tasked with maintaining a clusterfuck of hacks based on a version of software X that was made many years back because very little of the people who are developing in PHP give a blind fuck about the next dev to come along.

What's the point of talking about the latest generation of PHP nearly-catching-up-to-decent-interpreted-languages when the entire culture is based around godawful hackery, misuse, half-arsed ports of 4.3 codebases and developer laziness and insecure anti-patterns and other shit buzzwords I can't be fucked to mention but most likely apply to the majority of PHP code out there?

PHP. Never. Again.

Also Wordpress.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: