Live data from Hacker News

PHP is much better than what you think

fabien.potencier.org

281–290 of 346 posts

Re: PHP is much better than what you think

#281

Earlier quoted context omitted.

It's a double-edged sword however. Users stuck on PHP 5.2 will miss out on potential security fixes to Symfony 2. This can potential compound an already bad situation. I'm not saying Fabien didn't have good reasons, more playing Devil's Advocate.

If only cheap shared hosting was consistently up to date :<

It's not reasonable to host symfony on anything less than a VPS. It can be done, but you can also punch yourself in the face.

Servergrove.com has the best options for symfony sites IMHO

Re: PHP is much better than what you think

#282
post #279

PHP still can't access email inboxes inherently, can't do CSV import, can't download packages from GitHub the way Bundler can, doesn't support metaprogramming, has a hacked-together OOP system, and has an absolutely horrid syntax. Why am I meant to use PHP again? Oh yeah, because you haven't discovered Ruby yet.

Uh, Ruby can't do most of that out of the box either. Lots of those things you mention you need gems for.

And really? Can't do CSV import? What does that even mean?

I mean, it's a programming language. There are packages you can get that will do those things, and if there aren't, you program them.

I'll give you the point on the syntax.

Re: PHP is much better than what you think

#283

Earlier quoted context omitted.

While Composer introduced a new package format, it can be used to retrieve PEAR packages, 'plain' zip files and even git, svn and hg repositories - and these can be integrated even if they don't contain a composer.json file, needing just a little extra configuration in your project. This is a huge step forward and very convenient. http://getcomposer.org/doc/05-repositories.md I don't know how Bundler handles this and…

Well, it's not needed - that's my point. Bundler just uses the one well-established format for packaging libraries and declaring dependencies. Even git repositories and local code uses the same depency-declaring format: A standard gemspec. Otherwise bundler just stays out of the way to do it's main job - dependency resolution. There is no such thing as two package formats in the ruby world. There is now in the PHP wo…

I didn't mean to say it is better than all other dependency managers and basically didn't want to argue at all. My point is just that I am happy that Composer is around now, as it lets me include all dependencies from various sources in a convenient and reliable way. So no matter which dependency manager for which language is 'the best', Composer definitely means better times for all PHP developers.

Seems that Ruby had one good standard solution with gems for a long time, let's hope that Composer has a similar bright future. From my perspective, it's already the standard and including a composer.json file is a 'best practice' for all 'well-connected' PHP developers releasing a library these days.

Re: PHP is much better than what you think

#284

Earlier quoted context omitted.

Indeed a good point, fabien is the catalyst in the current generation of PHP projects, just take a look at Symfony2, Symfony CMF, Silex, Composer, Doctrine, ... they all spawned in the trail of his work. I actually wonder how he gets so much work done.

I think Doctrine is not related to his work. The Symfony CMF, while part of the Symfony community, has been mainly pushed by companies like Liip AG

Projects like Doctrine & swift mailer for email have been adopted and had development funded by Sensio @fabpot's dev shop.

So while not a tightly coupled part of Symfony they are related through developers, community, and funding

Re: PHP is much better than what you think

#285
Composer is pretty nice, but there's at least once vital package that's missing from it: PHPUnit.

As long as the only decent testing framework[1] isn't in the package repository, It just seems somehow not "official" enough.

[1] which still has more than its fair share of legacy warts

Re: PHP is much better than what you think

#286

Earlier quoted context omitted.

Sorry have to quibble on that last sentence. I'm transitioning from PHP to Python at the moment and I constantly keep thinking "jesus, I wish docs.python.org was as good as php.net".

In what sense? I feel it's better than PHP's docs (tutorial, index, module list, everything.) Besides, you rarely ever need to look at the docs. `help(...)` works well enough 99% of the time. Method and module names are clear and easy to guess. If I remember PHP well enough, it was a sorry_mess_of_underscored_function_names (with no namespaces) and had $funky $dollar $signs before variables. Some of the functions wor…

I miss the user contributed notes. I miss the way you can drill down on the left hand side of the screen. I miss the multitude of quick examples embedded alongside the documentation (py docs has some but not nearly as many). I find the descriptive language used more approachable and easier to understand. I also prefer the general look and feel.

To answer your second point about deployment: regarding your ini file, you set this up once how you want it to be and then use that across all your projects. Not very hard. As for apache, I don't know what you were doing but in my experience it's almost impossible for apache not to find php. I've just setup uWSGI (plus emperor) + mongrel2 + Flask (in a virtualenv) and that is 100 time harder to get going than apache and mod_fcgid (IMHO).

Re: PHP is much better than what you think

#288
post #37
post #21

Earlier quoted context omitted.

Facebook.

Yes. And now Facebook is spending a ton of resource and man-hours programming around this. They had to write their own compiler! Also, I think they are trying to move away from PHP as quickly as possible without rewriting the entire site. The new projects and tools are not in PHP; moreover, I think most of the new people they hire never have to use PHP at all. Finally, just because they managed to use PHP to run a bi…

I have only a year and a bit of context since starting at Facebook, but here's my viewpoint.

Facebook isn't trying to move away from PHP as quickly as possible. For years, there have been PHP components (primarily web front-end rendering, aggregation/ranking of data from various sources) and C++ components (primarily high-performance back-end services) and other languages like Python (primarily non-production-path/operations back-end services) and Java (primarily Hadoop-related technologies like Hive and HBase, and services that are heavy users of such), and nothing groundbreaking has changed in this.

New hires use PHP or C++ or whatever language (and often multiple languages) necessary to work on the team and projects they choose to work on. New projects use the languages that make the most sense.

Almost all web front-end work involves PHP - the frameworks and libraries and runtime environment are well-developed, well-tested, well-documented, and well-known.

In terms of HipHop for PHP, the question to ask is: What language could have allowed quick low-barrier-to-entry web-app-centric development in the early days while still delivering the sort of runtime efficiency demanded by the environment? Languages like Python and Ruby may arguably allow the first (but remember we're talking about early 2004 here, so Ruby on Rails was not out, and neither were Django, Flask, and so forth and WSGI had just come out), but would have required a "HipHop for PHP"-style solution as well. Languages like C, C++, and Java may have the runtime efficiency, but it would be a hard argument to say they're as developer-time-efficient as PHP (especially back then).

That's a slightly different question to what one should do today if starting a new venture. And _that_ is also a different question to what Facebook should do today - HipHop for PHP exists, and is delivering performance/runtime efficiency that most languages people mention as an alternative do not. And, the PHP frameworks and libraries and runtime environment exist and allow rapid development of production code. It's actually reasonably pleasant to develop for with those in place.

The HipHop for PHP team is small, but have huge leverage - this small team of reasonably hardcore low-level C++ programmers are making a whole bunch (hundreds?) of PHP developers way more productive (since they don't have to use a relatively slower-to-develop-in language/runtime like C++), and also makes the cost of operating the site go down by making that code more efficient and reducing the number of servers needed.

Re: PHP is much better than what you think

#289

Earlier quoted context omitted.

> Hacker News really doesn't like PHP. But Y? function Y($F) { $func = function ($f) { return $f($f); }; return $func(function ($f) use($F) { return $F(function ($x) use($f) { $ff = $f($f); return $ff($x); }); }); }

Honestly, and with complete sincerity, that just means you're a bad programmer. It has nothing to do with the language. And trying to correlate the two is makes you look even worse.

Did you mean to reply to a different comment?

Re: PHP is much better than what you think

#290
post #182

Earlier quoted context omitted.

What's so horrible about CakePHP?

Its legacy (who wants to still support PHP4?). AFAIK, it's no longer maintained; I believe all the core development is now taking place on the Lithium project: http://lithify.me/

> AFAIK, it's no longer maintained

False. Last commit was 18 hours ago.

Post reply on HN