6 ms·

The Lesser Known Contributors Who Are Trying To Make PHP Good Again

56 points by DanielN 14y ago

jey 14y ago
When was PHP good in the past? (Honest question; I don't use PHP.)
- DanielN 14y ago
  Quite possibly never, but it was arguably the best web language in the early 2000s.
  - plorkyeran 14y ago
    Perl fans would probably object strongly to that, but it is true that when PHP first caught on there really weren't any great choices.
    - prunebeads 14y ago
      The strong selling point of PHP for a long time was cheap hosting. Combine that with a fast learning curve and you're set. Nowadays, it's not so clear cut price wise, but PHP took a strong advance in term of user base - look at the number of libraries, projects, and jobs (!) available in PHP, vs python or ruby.
      - gubatron 14y ago
        good selling points, but those things never made it a good language, it was just convenient.
        prunebeads 14y ago
        PHP followed a very uncommon path. Features were added as needed, in an incremental fashion. Nice syntax is never a huge problem, though that's probably most people complaint. That said, it isn't worse than its "contenders" in terms of feature set. You get a decent object system, lambdas (note that they'd been there for a long time, but it's more convenient now), a wide range of bindings. It's not pretty, but it does the job in many cases. But, anyway, if you're really looking for a good language (something efficient, where you don't have to spend hours to spot a stupid bug), skip the dynamic ones altogether, and go for as much static analysis you can get.
- mtts 14y ago
  When shared hosting was the norm. mod_php was much faster than CGI and a lot safer to use because usually processes in one virtual host did not affect processes in another unlike with mod_perl and the like.
ericclemmons 14y ago
Time to beat this dead horse again! PHP as a language isn't great, since it has been around the block in a volatile environment (the web) and shows lack of foresight in language design. However, PHP is experiencing a renascence with modular components, frameworks and tools utilizing established design patterns, and an overall boost in contribution and collaboration in the open-source community, in large part thanks to Github. PHP is not dead, and vibrant communities around Symfony and Doctrine are pushing it forward considerably. In my opinion, large applications can and have been built primarily on PHP while leveraging other languages and tools for their strengths.
- mseebach 14y ago
  A lot of good people are working on a lot of PHP that isn't going away, and obviously they are going to improve tooling and the language itself. There is a renaissance in terms of making PHP development sane and thus not something good people run away screaming from - a bit like Java. But the benefits of starting a new project in PHP are few: All of the original benefits (mainly low barrier to entry) are eradicated, and that leaves PHP to compete directly, as a full development environment, not as the only easy way to get code on the web, with a myriad of other languages that can, almost objectively, be thought of as better. Again, a bit like Java.
- DanielN 14y ago
  Very well put. I'm not a huge fan of php, but find this possibility of resurgence (particularly because I use the language for my day job) very interesting.
lunetics 14y ago
You shouldn't forget about PSR-0 / http://www.php-fig.org/ http://www.php-fig.org/
- Dachande663 14y ago
  PSR-0 would be great, except for the use of mixed case filenames. The number of packages that have obviously only been tested on HFS+/other case-insensitive filesystems is staggering (or maybe I just have bad luck picking ones). The only logical reason I can see they didn't normalize and lowercase filenames is that the big boys had too much legacy cruft already broken.
zdw 14y ago
Everyone probably knows this, but PHP's Smarty template engine (http://www.smarty.net http://www.smarty.net) is really awesome. I've yet to see a better one in any language - it has things like Unix-like pipe chaining of filters, user defined functions, and intelligent caching built in. I reduced the number of lines in one codebase I worked on by 70% through use of Smarty.
- deleted 14y ago
  [deleted]
- michaelsbradley 14y ago
  I enjoy using Hiccup more than any template engine I've used previously. Before I met (Clojure and) Hiccup[1], I would have said the same regarding Coffeekup[2]. But what's really amazing is when you combine Hiccup with Enlive[3]. Enlive can give you a headache when you first start working with it, but then there's an almost magical "aha!" moment, and not long after that you'll never want to look back. By "combine" I mean using Hiccup and metadata from your db (or whatever) to generate empty, logic-less views and then using Enlive to bind in your data. Combine those steps with your own macros and HOFs, look for some choice places to memoize function calls, and now you're cooking with gas. [1] https://github.com/weavejester/hiccup https://github.com/weavejester/hiccup [2] https://github.com/mauricemach/coffeekup https://github.com/mauricemach/coffeekup [3] https://github.com/cgrand/enlive https://github.com/cgrand/enlive
- Osiris 14y ago
  I work on a legacy code base with pretty much everything in SMARTY templates (including CSS and JS files!) and it's really aweful. It may not be SMARTY's fault, but most of what's going on could be just as easily done with PHP code than with SMARTY tags, include variable insertion (<?=$var?>) and control logic (if ($var) : // endif;). Now we've actually moved everything to the client side using Ember and Handlebars templates. JS doesn't have any built-in templating like PHP (which is basically just a template engine), so Handlebars makes it really useful to write up HTML code blocks that get variable insertion and data-binding on the client side.
  - 14y ago
error54 14y ago
While I've bashed PHP as much next guy, these are the facts: -Take away PHP and the internet would break. The vast majority of websites are either written in PHP or have a PHP back end. -The LAMP/LNMP stack is by far one of the most deployed web server configuration. -PHP is extremely well documented and it's been around so long that it's easy to find solutions on the web. PHP is the Model T of web languages: people love to laugh at it because it's old and ugly but it nearly single-handedly revolutionized the landscape. I for one applaud any efforts to revive and improve this language.
- OmIsMyShield 14y ago
  The documentation point is important - it's been used in so many projects that a lot of weird fringe cases occurring in only the most bizarre setups have been documented. There is a lot of value in that, and it takes time to build a similar body of knowledge for newer platforms.
- shashashasha 14y ago
  I don't know enough to deeply critique the various web languages, but if PHP is the Model T, wouldn't it sound odd and backwards facing to talk about reviving and improving it?
  - mseebach 14y ago
    The analogy breaks down quickly, because cars are mostly standalone, and can be replaced with little risk, while software is often complex and interconnected, so the benefit of a rewrite in a new language only rarely exceed the massive risks of abandoning your clunky but well-tested codebase. But, sticking with it, it's comes down to there being a huge market in parts and service. Something like all taxis in the US still being Ford Ts, with very little forecast of change.
- josteink 14y ago
  PHP is extremely well documented and it's been around so long that it's easy to find solutions on the web. I can agree that PHP is documented. That it is well documented however is something I'm very much willing to argue against. PHP has string-operations documented to be "binary-safe" without ever saying what that is supposed to mean, if it's good (it's not), if it's bad (yes, yes, yes it is) and why you should have an opinion on that at all. Nothing about that. "Binary-safe" is not defined anywhere. It just "notes" that all these operations which should operate on text is "binary-safe". And "safe" makes it sound like a good feature, right? Documentation like this is probably written by people who have no idea what a character encoding is and thinks that being able to strpos() on raw byte-data is a "cool feature", without understanding that text and it's encoded representation are two very different things. Basically, the documentation is written by people lacking any deep understanding of the subject they are covering, and they pass their confusion on to whoever may be unfortunate enough to stumble upon it. So... Is bad documentation better than no documentation? I don't know. Maybe? Still: PHP documentation, good or bad, represents the blind leading the blind. If you want "extremely well documented", head over to MSDN and check the .net docs. It's systematic, it's consistent and it's thorough. It's written by people who understand the difference between Unicode, UTF8, text and bytes. Or whatever else the subject you are reading about covers. But people peddling in PHP wouldn't know that, because they wouldn't want to go too far outside their comfort-zones, and hey, they definitely wouldn't want to look at anything done by Microsoft.
gubatron 14y ago
Again?
mseebach 14y ago
PHP was never good, but it abstracted away some basic web specifics -- as opposed to CGI/Perl that required you to care about protocol details such as starting output with two newlines -- and hit a sweet spot infrastructurewise -- dead easy to get started with, dead easy to get hosted for next to nothing -- that gave it enough traction to grow very quickly.
- fallous 14y ago
  I'm not sure that was so much the attraction when PHP first started gaining traction given the existence of CGI.pm From my experience in the 90s, most of the early adopters of PHP were more smitten with included PHP code in otherwise static HTML files. It was SSI++
languagehacker 14y ago
Those examples aren't good differentiators between PHPUnit and Phake. And unfortunately, despite how goot Composer it, it just adds another package management system into the mix. GitHub has ended up being the best package manager PHP could really ask for. I kind of view the native PHP development server as getting featural parity with Rails and Django. But it seems like that's a major gripe for developers who are averse to working with Apache or Nginx for being too complex. I'm very excited for traits as a feature. This is when we get into real language features other, more prestigious or "hot" web development languages actually have that PHP lacks. These result in true architectural deficiencies requiring annoying hacks to accommodate. In the end, PHP itself benefits most from expanding its capacities as a logical formalism. Tools are great, but they're also a lot less easier to get right.
deleted 14y ago
[deleted]
adaml_623 14y ago
Article title seems to imply there will be some info about the people who programmed these new features... instead there's a rehash of the new features and mention of a library or 2 that we could read about elsewhere. Author says, "the developers of these new tools deserve some serious recognition for the work they are doing" and then totally fails to mention them! So now we've again been suckered into the 'PHP good' vs 'PHP bad' non-debate.
jentulman 14y ago
composer is great, I'd just like to add that the docs make the distinction that it's a dependency manager rather than a package manager.
eik3_de 14y ago
Serious question: Do you know of successful/large web startups in the last two years that used PHP as their main language?
- robryan 14y ago
  I would be interested in the answer to this also, but I am coming from the side of expecting lots probably are.
- lrobb 14y ago
  Iirc some startup hired rasmus lerdorf, the creator of php.
jrockway 14y ago
So does PHP not let you mock things by actually writing classes in the test file, like: class FakeFooBar(FooBar): def my_method(self, *args): self.last_my_method_args = args return self.result class TestFooBar(TestCase): def test_my_method(self): foobar = FakeFooBar() foobar.result = 42 self.assertEquals( foobar.use_my_method('hello world'), 'forty two') self.assertEquals( foobar.last_my_method_args, ['hello world']) This is more verbose than mocking things out, but the control flow is more obvious and you don't have to rewrite the entire test case every time you change one tiny implementation detail (which is what I've had to do with every mox test I've ever written). Actually, it's not even that verbose compared to mox :)
- TomNomNom 14y ago
  It does; it's just not very common. Defining mocks manually is my preferred method. I find things like Phake and Mockery to be a little too opaque and hard to debug when you get subtle problems. I think they also add to the learning curve when getting new devs up to speed. IMO one reason a lot of PHP devs avoid the manual method of defining mocks is just laziness.
acabal 14y ago
Those are all nice, but as a long-time PHP dev, the only way to make PHP truly better is to do a Python-style hard version bump. Rip off the band-aid, so to speak. Create an entirely new, consistent, object- or namespace-oriented standard library to replace the mess that exists now. The majority could just be wrappers for existing code, which is fine but just inconsistently named and parameterized. Then fix the terrible namespacing implementation, consolidate the jumble of operators (::, ->, ., +, etc.), add some syntactic sugar to objects (getters and setters?), add native Unicode support, and call it all PHP X or something. There's much to be said for backwards compatibility, and PHP does that really well; but there's also much to be said for a new generation built with the mistakes of the past in mind. I actually really like PHP despite its flaws. It gives the programmer easy, deep control over HTTP output, it's easy to install on new servers, it's easy to deploy (no compilation, just rsync everything!), it has decent built-in templating (if you can learn the quirks), it's OSS, it has rich libraries, rich documentation, and a rich community. But it's also deeply flawed and it deserves a break from the past. My ideal sort of web language would be something with C# syntax and libraries but with PHP-style OSS-ness, simplicity in output and compilation, and expressiveness in HTML. That would be nice!
TamDenholm 14y ago
To all the language bashers, can we all agree that a good developer beats a bad developer in any language? I wrote a post on this: http://news.ycombinator.com/item?id=4606961 http://news.ycombinator.com/item?id=4606961

56 points by DanielN 14y ago

jey 14y ago

When was PHP good in the past? (Honest question; I don't use PHP.)

DanielN 14y ago
Quite possibly never, but it was arguably the best web language in the early 2000s.
- plorkyeran 14y ago
  Perl fans would probably object strongly to that, but it is true that when PHP first caught on there really weren't any great choices.
  - prunebeads 14y ago
    The strong selling point of PHP for a long time was cheap hosting. Combine that with a fast learning curve and you're set. Nowadays, it's not so clear cut price wise, but PHP took a strong advance in term of user base - look at the number of libraries, projects, and jobs (!) available in PHP, vs python or ruby.
    - gubatron 14y ago
      good selling points, but those things never made it a good language, it was just convenient.
      - prunebeads 14y ago
        PHP followed a very uncommon path. Features were added as needed, in an incremental fashion. Nice syntax is never a huge problem, though that's probably most people complaint. That said, it isn't worse than its "contenders" in terms of feature set. You get a decent object system, lambdas (note that they'd been there for a long time, but it's more convenient now), a wide range of bindings. It's not pretty, but it does the job in many cases. But, anyway, if you're really looking for a good language (something efficient, where you don't have to spend hours to spot a stupid bug), skip the dynamic ones altogether, and go for as much static analysis you can get.
mtts 14y ago
When shared hosting was the norm. mod_php was much faster than CGI and a lot safer to use because usually processes in one virtual host did not affect processes in another unlike with mod_perl and the like.

ericclemmons 14y ago

Time to beat this dead horse again! PHP as a language isn't great, since it has been around the block in a volatile environment (the web) and shows lack of foresight in language design. However, PHP is experiencing a renascence with modular components, frameworks and tools utilizing established design patterns, and an overall boost in contribution and collaboration in the open-source community, in large part thanks to Github. PHP is not dead, and vibrant communities around Symfony and Doctrine are pushing it forward considerably. In my opinion, large applications can and have been built primarily on PHP while leveraging other languages and tools for their strengths.

mseebach 14y ago
A lot of good people are working on a lot of PHP that isn't going away, and obviously they are going to improve tooling and the language itself. There is a renaissance in terms of making PHP development sane and thus not something good people run away screaming from - a bit like Java. But the benefits of starting a new project in PHP are few: All of the original benefits (mainly low barrier to entry) are eradicated, and that leaves PHP to compete directly, as a full development environment, not as the only easy way to get code on the web, with a myriad of other languages that can, almost objectively, be thought of as better. Again, a bit like Java.
DanielN 14y ago
Very well put. I'm not a huge fan of php, but find this possibility of resurgence (particularly because I use the language for my day job) very interesting.

lunetics 14y ago

You shouldn't forget about PSR-0 / http://www.php-fig.org/ http://www.php-fig.org/

Dachande663 14y ago
PSR-0 would be great, except for the use of mixed case filenames. The number of packages that have obviously only been tested on HFS+/other case-insensitive filesystems is staggering (or maybe I just have bad luck picking ones). The only logical reason I can see they didn't normalize and lowercase filenames is that the big boys had too much legacy cruft already broken.

zdw 14y ago

Everyone probably knows this, but PHP's Smarty template engine (http://www.smarty.net http://www.smarty.net) is really awesome. I've yet to see a better one in any language - it has things like Unix-like pipe chaining of filters, user defined functions, and intelligent caching built in. I reduced the number of lines in one codebase I worked on by 70% through use of Smarty.

deleted 14y ago
[deleted]
michaelsbradley 14y ago
I enjoy using Hiccup more than any template engine I've used previously. Before I met (Clojure and) Hiccup[1], I would have said the same regarding Coffeekup[2]. But what's really amazing is when you combine Hiccup with Enlive[3]. Enlive can give you a headache when you first start working with it, but then there's an almost magical "aha!" moment, and not long after that you'll never want to look back. By "combine" I mean using Hiccup and metadata from your db (or whatever) to generate empty, logic-less views and then using Enlive to bind in your data. Combine those steps with your own macros and HOFs, look for some choice places to memoize function calls, and now you're cooking with gas. [1] https://github.com/weavejester/hiccup https://github.com/weavejester/hiccup [2] https://github.com/mauricemach/coffeekup https://github.com/mauricemach/coffeekup [3] https://github.com/cgrand/enlive https://github.com/cgrand/enlive
Osiris 14y ago
I work on a legacy code base with pretty much everything in SMARTY templates (including CSS and JS files!) and it's really aweful. It may not be SMARTY's fault, but most of what's going on could be just as easily done with PHP code than with SMARTY tags, include variable insertion (<?=$var?>) and control logic (if ($var) : // endif;). Now we've actually moved everything to the client side using Ember and Handlebars templates. JS doesn't have any built-in templating like PHP (which is basically just a template engine), so Handlebars makes it really useful to write up HTML code blocks that get variable insertion and data-binding on the client side.
- 14y ago

error54 14y ago

While I've bashed PHP as much next guy, these are the facts: -Take away PHP and the internet would break. The vast majority of websites are either written in PHP or have a PHP back end. -The LAMP/LNMP stack is by far one of the most deployed web server configuration. -PHP is extremely well documented and it's been around so long that it's easy to find solutions on the web. PHP is the Model T of web languages: people love to laugh at it because it's old and ugly but it nearly single-handedly revolutionized the landscape. I for one applaud any efforts to revive and improve this language.

OmIsMyShield 14y ago
The documentation point is important - it's been used in so many projects that a lot of weird fringe cases occurring in only the most bizarre setups have been documented. There is a lot of value in that, and it takes time to build a similar body of knowledge for newer platforms.
shashashasha 14y ago
I don't know enough to deeply critique the various web languages, but if PHP is the Model T, wouldn't it sound odd and backwards facing to talk about reviving and improving it?
- mseebach 14y ago
  The analogy breaks down quickly, because cars are mostly standalone, and can be replaced with little risk, while software is often complex and interconnected, so the benefit of a rewrite in a new language only rarely exceed the massive risks of abandoning your clunky but well-tested codebase. But, sticking with it, it's comes down to there being a huge market in parts and service. Something like all taxis in the US still being Ford Ts, with very little forecast of change.
josteink 14y ago
PHP is extremely well documented and it's been around so long that it's easy to find solutions on the web. I can agree that PHP is documented. That it is well documented however is something I'm very much willing to argue against. PHP has string-operations documented to be "binary-safe" without ever saying what that is supposed to mean, if it's good (it's not), if it's bad (yes, yes, yes it is) and why you should have an opinion on that at all. Nothing about that. "Binary-safe" is not defined anywhere. It just "notes" that all these operations which should operate on text is "binary-safe". And "safe" makes it sound like a good feature, right? Documentation like this is probably written by people who have no idea what a character encoding is and thinks that being able to strpos() on raw byte-data is a "cool feature", without understanding that text and it's encoded representation are two very different things. Basically, the documentation is written by people lacking any deep understanding of the subject they are covering, and they pass their confusion on to whoever may be unfortunate enough to stumble upon it. So... Is bad documentation better than no documentation? I don't know. Maybe? Still: PHP documentation, good or bad, represents the blind leading the blind. If you want "extremely well documented", head over to MSDN and check the .net docs. It's systematic, it's consistent and it's thorough. It's written by people who understand the difference between Unicode, UTF8, text and bytes. Or whatever else the subject you are reading about covers. But people peddling in PHP wouldn't know that, because they wouldn't want to go too far outside their comfort-zones, and hey, they definitely wouldn't want to look at anything done by Microsoft.

gubatron 14y ago

Again?

mseebach 14y ago

PHP was never good, but it abstracted away some basic web specifics -- as opposed to CGI/Perl that required you to care about protocol details such as starting output with two newlines -- and hit a sweet spot infrastructurewise -- dead easy to get started with, dead easy to get hosted for next to nothing -- that gave it enough traction to grow very quickly.

fallous 14y ago
I'm not sure that was so much the attraction when PHP first started gaining traction given the existence of CGI.pm From my experience in the 90s, most of the early adopters of PHP were more smitten with included PHP code in otherwise static HTML files. It was SSI++

languagehacker 14y ago

Those examples aren't good differentiators between PHPUnit and Phake. And unfortunately, despite how goot Composer it, it just adds another package management system into the mix. GitHub has ended up being the best package manager PHP could really ask for. I kind of view the native PHP development server as getting featural parity with Rails and Django. But it seems like that's a major gripe for developers who are averse to working with Apache or Nginx for being too complex. I'm very excited for traits as a feature. This is when we get into real language features other, more prestigious or "hot" web development languages actually have that PHP lacks. These result in true architectural deficiencies requiring annoying hacks to accommodate. In the end, PHP itself benefits most from expanding its capacities as a logical formalism. Tools are great, but they're also a lot less easier to get right.

deleted 14y ago

[deleted]

adaml_623 14y ago

Article title seems to imply there will be some info about the people who programmed these new features... instead there's a rehash of the new features and mention of a library or 2 that we could read about elsewhere. Author says, "the developers of these new tools deserve some serious recognition for the work they are doing" and then totally fails to mention them! So now we've again been suckered into the 'PHP good' vs 'PHP bad' non-debate.

jentulman 14y ago

composer is great, I'd just like to add that the docs make the distinction that it's a dependency manager rather than a package manager.

eik3_de 14y ago

Serious question: Do you know of successful/large web startups in the last two years that used PHP as their main language?

robryan 14y ago
I would be interested in the answer to this also, but I am coming from the side of expecting lots probably are.
lrobb 14y ago
Iirc some startup hired rasmus lerdorf, the creator of php.

jrockway 14y ago

So does PHP not let you mock things by actually writing classes in the test file, like: class FakeFooBar(FooBar): def my_method(self, *args): self.last_my_method_args = args return self.result class TestFooBar(TestCase): def test_my_method(self): foobar = FakeFooBar() foobar.result = 42 self.assertEquals( foobar.use_my_method('hello world'), 'forty two') self.assertEquals( foobar.last_my_method_args, ['hello world']) This is more verbose than mocking things out, but the control flow is more obvious and you don't have to rewrite the entire test case every time you change one tiny implementation detail (which is what I've had to do with every mox test I've ever written). Actually, it's not even that verbose compared to mox :)

TomNomNom 14y ago
It does; it's just not very common. Defining mocks manually is my preferred method. I find things like Phake and Mockery to be a little too opaque and hard to debug when you get subtle problems. I think they also add to the learning curve when getting new devs up to speed. IMO one reason a lot of PHP devs avoid the manual method of defining mocks is just laziness.

acabal 14y ago

Those are all nice, but as a long-time PHP dev, the only way to make PHP truly better is to do a Python-style hard version bump. Rip off the band-aid, so to speak. Create an entirely new, consistent, object- or namespace-oriented standard library to replace the mess that exists now. The majority could just be wrappers for existing code, which is fine but just inconsistently named and parameterized. Then fix the terrible namespacing implementation, consolidate the jumble of operators (::, ->, ., +, etc.), add some syntactic sugar to objects (getters and setters?), add native Unicode support, and call it all PHP X or something. There's much to be said for backwards compatibility, and PHP does that really well; but there's also much to be said for a new generation built with the mistakes of the past in mind. I actually really like PHP despite its flaws. It gives the programmer easy, deep control over HTTP output, it's easy to install on new servers, it's easy to deploy (no compilation, just rsync everything!), it has decent built-in templating (if you can learn the quirks), it's OSS, it has rich libraries, rich documentation, and a rich community. But it's also deeply flawed and it deserves a break from the past. My ideal sort of web language would be something with C# syntax and libraries but with PHP-style OSS-ness, simplicity in output and compilation, and expressiveness in HTML. That would be nice!

TamDenholm 14y ago

To all the language bashers, can we all agree that a good developer beats a bad developer in any language? I wrote a post on this: http://news.ycombinator.com/item?id=4606961 http://news.ycombinator.com/item?id=4606961