Taking PHP Seriously [pdf](raw.github.com) |
Taking PHP Seriously [pdf](raw.github.com) |
Here is my TL;DR of this article. PHP is bad we all know this and accept it. Facebook has made it better by keeping most of the syntax and chucking everything else out the window. Run your stuff on HipHop ( unless you need extensions in which case your OOL )
Also, it's a little obscure for languages like PHP where we're unused to making architecture/implementation distinctions, but if HHVM is good then PHP is good. It runs the same core language as php.net. To the extent we don't, it's likely to be a bug these days. I think HHVM is a better implementation of that language than php.net, but I am biased, and that isn't the point of the talk. We're also chipping away at running other popular programs, extensions and all: http://www.hhvm.com/blog/?p=875
Edit: transposed sentence
I've heard this argument before, but it's important to realize that Facebook was able to use standard PHP up until the point when they had roughly 500 million users. Unless your site has a half billion users you can't compare your use case to Facebook's.
As far as I can tell, only 3 is obviously something that only affects whether you can use the language once you have a certain number of users. The first two are really about changing the language.
As a matter of fact Facebook would probably have run into the same problems if they had used Ruby or Python. These problems are problems of massive scale most of us will never face. Twitter had problems running on Ruby/Rails and i bet theres a case to be made for Python too. All this says is that at the scale level of facebook you will encounter the limits of dynamic typing scripting languages, but its not a problem with PHP per se and also not a problem that should hold anyone back from choosing php/ruby/python because its premature optimization.
>At this point we almost need to stop saying facebook programs in PHP
Also, your TL;DR is a flat out lie.
I like the idea of opt-in typing for PHP via Hack which you can enter by beginning your PHP code with <?hh — Facebook have essentially taken everything that is wrong with PHP, every complaint that someone has ever published in a blog post or bug report, forum or IRC channel and built it into an improvement of the language.
PHP isn't going anywhere. It might be one of the oldest web languages, but I think the PHP space is starting to get better with Facebook's contributions to the language, Laravel 4 being a solid PHP framework and we can't forget that most Yahoo! products are built using PHP as well (even the recently acquired Tumblr is coded in PHP). Flickr! is probably one of their biggest PHP applications.
Event hough Facebook appear to have resolved the many complaints and problems of PHP, I am sure people will still find a way to complain about the language that powers most of the web...
As for php encouraging shitty programming, a good bit of that is that so many more people program in php because its easier to get started with. This does not mean that just because php attracts shitty programmers that it doesn't have more or many awesome programmers than languages such as python.
http://blog.samuellevy.com/post/41-php-is-the-right-tool-for...
Please stop complaining about how horrible PHP is if you don't use it or have. intentions to replace it.
Having worked with clients that publish thousands of articles of content per month the best solution for the job at the end of the day is still WordPress. Have a client that needs an online store? Magento (both of which are built in PHP).
Development shops don't have time to custom build CMS's and eCommerce solution because their clients don't give a shit what language or framework their site is built in.
Show me a CMS built in ruby, python or javascript that comes anywhere near WordPress and I'll gladly switch. Unfortunately it just doesn't exist. Like you said, PHP has its place and until something better comes along stop complaining.
PHP means access to easy to install, ready to go software, which meets 95% of the needs of small businesses. I would love to see that in python, or anything else, but it simply isn't there. The most widely used python CMS? Plone. It's massive, hard to maintain, and far from easy to install or host.
I've been on and off working on systems like WordPress for pyramid/python for a while, but it's a massive project. One day I might finish it...
I use php since v3 as well, when I joined College back in 2001, in my first programming class, the professor told me PHP was cr@p when I told him that was the language I was more proficient with. I didn't listen to him... PHP was paying my bills since before I joined the College.
I feel like so much of the bias towards PHP is either an unfair comparison (language to 'rails') or a bad taste left in the mouth because the person worked with a nasty domain specific language like Wordpress, Drupal, Magento, etc.
PHP is like pop music; there is a lot of it and 'true' artists think it's beneath them. Nevertheless the public demands and craves it, and most of the big web applications that are open source run on PHP.
If you feel like PHP is a blight on the world, by all means go out there and disrupt the community by launching something that gets widespread adoption the way PHP software has.
All the same, if you're not inheriting a legacy codebase, I don't think there is any reason to use a LAMP stack on a greenfield project that you will be creating tomorrow. There are just too many better alternatives out there.
> Facebook’s PHP Codebase
> x * 105 files
> y*107 LoC
> 10 releases per week
> Anecdotally, good engineers are astonishingly productive in PHP
...Fuck it, I'll rail. It's 2013. Do yourself a favor. Use something better than a horribly inconsistent glorified cgi script.
1) State => because endpoints have no persistent state
2) Concurrency => because there is no concurrency model
3) Transparency => (1) + (2) + fast reload = easy to understand
These combined give the language nice programmer "ergonomics" (Keith's terminology). It also limits the collateral damage any particular change to the codebase can have which allows Facebook to more confidently deploy multiple times a week.
Remember also that a large part of the reason why facebook won over its competitors (friendster and myspace) was technology. Both myspace and friendster had trouble scaling up their featureset at the same time as their userbase, whereas facebook pulled it off relatively well. It's hard to know without inside knowledge whether PHP had anything to do with that, but it obviously didn't prevent facebook from winning.
I'll be the first one to take a swing at PHP, but Facebook has done some awesome things with it. I used to program in PHP and it does have some really nice bits...I mean, it's hard to fathom not waiting for my container to start anymore and go back to the days of save/reloading.
Cool. Nice link, OP.
You can do a lot with meta-programming in PHP. For example, you can write your own array type if you are so inclined and use it anywhere you would use an array. Here's an experimental library that showcases the meta-programming abilities: https://github.com/jsebrech/php-o
Its just baby garden. Im sorry.
PHP will be Seriously if will use major Erlang features: processes, pattern matching, atoms, lists, tuples
Tuples need because they more simple for understand and matching then lists and strings. Tuples can simple converts to lists and back. Tuples more effective with memory.
Only one class can implement tuples now its SplFixedArray. But there bugg when you call createFromArray in own custom class derived from SplFixedArray. Also with small count uts slow.
Try test Erlang and see his power. I hope you think will too, that PHP needs with Erlang features.
ouch
Despite this, there is nothing in PHP that prevents you from doing the thing you want to do, however you want to do it. As projects become larger and involve more time and people, the fine grain of line syntax fades out of view, and all that is left is the large scale design decisions, which are similar in any language. And this is what ultimately determines the technical success or failure of software.
To be honest, PHP is really just simpler, less hassle, and if you know what you're doing things come out structured well. Just stick to classes (Including statics! There shouldn't be a define() anywhere.), use namespaces, use composer (I've come to really like it), and use a coding standard.
I would. For every job, a proper tool. If my project is client-side heavy and only needs a thin layer between the client-side and the database, I'll pick PHP. The code I would write in PHP would be minimal and I would get it up and running very quickly.
If I'm writing something substantial on the server-side, then yeah, you may want to consider something else.
Doesn't make me want to give up python or node, but these are strong points in PHP's favor.
At the end of the day, every program is a stream of bits too. That doesn't diminish the importance of programming languages as a tool for reasoning, managing complexity and avoiding common mistakes.
As the industry shifts from deliver something that sort of works to deliver something with these assured characteristics, programming languages designed around enforcing desired qualities will be of immense value.
> Another good point is the efficiency of a developer working in PHP.
Compared to what? Depends on the developer and problem domain.
> The language is easy, it's so easy to be a PHP master after a few years working in the language.
You can master any language after a few years.
> It's easy to find super-talented PHP developers compared to any other language.
Data?
It should be quite obvious to anyone by now that when it comes to shitty programming, language is negligible factor once a language has hit the mainstream.
But I'm pretty sure 5 to 10 years from now someone manages to argue that Ruby is crap, Rails is to blame for encouraging a generation of developers to write bloated controllers full of spaghetti code, and that this attracts shitty programmers incapable of understanding software architecture.
Instead of relying on actual reusable building blocks, you're expected to build specific versions of ruby interpreter and libraries for every project.
Imagine having to cope with just ever so slightly different (but certainly incompatible) philips screws whenever you want to affix one physical thing to another.
Or much worse what are the odds that if I'm an average developer and am picking a random feature from each language's standard library, making care to read the docs before using it in my application that I've still introduced a bug? (Consider that maybe I'm dealing with things that were considered strange and new when most of PHP is still from - like character encodings - particularly character encodings that differ from the system I'm running in).
Most languages can be CGI-style executed by an httpd with shared-nothing, but can also start up and be a long-lived stateful daemon. I don't have to decide between putting a square peg in a round hole or throwing my code away to learn something entirely new if I realize I need the latter part way through a project.
PHP comes with a excessively large (but strangely CGI/HTTP/HTML/SQL-obsessed) standard library littered with footguns, and for most of its life has not had a common pattern for reusable modules, and has not had a good bundler for shipping reusable modules or making working with C extensions easy - and as such few people bother reimplementing functionality from core outside of what's been provided there (which is all set in hard clay), and when they are forced to tend to do so in (plain-ole-interpreted) PHP and don't generally package it up for reuse outside their own projects - a practice much more common outside PHP-land.
Case in point (goddamn strlen, even): https://api.drupal.org/api/drupal/includes%21unicode.inc/fun...
Some of that is changing in recent history (as in well after other languages figured these problems out) with PSR (design for reuse) and Composer (bundler) but it's slow moving and the latter still won't compile C extensions yet: https://github.com/composer/composer/pull/498
Plenty of this could be solved in PHP, some of it already is if you have the luxury to work with a tiny subset of PHP projects, but the practice in PHP seems to still mostly be to have it piss in your face and believe that it's raining. People are in a rut of tradition or simply don't expect their tools or libraries to be good - and I've spent the last 6 years working with PHP (several products, several teams) and wondering where I can get some of the Koolaid that my colleagues are drinking.
Why? What difference does that make as a programmer using it? If another language is more modular, and lets libraries handle things that are baked into php, isn't that a good thing?
> As for php encouraging shitty programming, a good bit of that is that so many more people program in php because its easier to get started with. This does not mean that just because php attracts shitty programmers that it doesn't have more or many awesome programmers than languages such as python.
Maybe not, but it makes it harder to hire the good ones.
You have things like Rubymotion(to build iOS and Mac apps), which I'm really liking. Opal which translates Ruby to Javascript. You can build Android apps with Ruboto. You can run Ruby the JVM and call Java libraries. You can run Ruby on the .NET runtime(Iron Ruby). You have a really good Web framework called Rails. Most other PHP frameworks just copy Rails, so why not just use the source. You can build games for iOS using Joybox(library for Rubymotion).
So from a business prospective we chose Ruby because we can do pretty much everything in Ruby. We rarely have to use anything else. From command line applications, to web, to iOS, to Android, to reporting, etc.
PHP, well, you can output HTML, or JSON.
Several years ago I was told to use Magento on a project. Great, Magento is a mature PHP app and I'll get to see some great PHP code. Nope, I was horrified by what I saw and dreaded coming to work everyday and having to deal with that mess of a system.
I have a hard time getting behind a language that everyone uses but no one uses well.
Just look at MoinMoin's source and see how much more elegant it is than MediaWiki.
> either an unfair comparison (language to 'rails')
Why is that unfair?
> a bad taste left in the mouth because the person worked with a nasty domain specific language like Wordpress, Drupal, Magento, etc.
If that's how PHP is used in practice then it's fair to complain about PHP.
Because PHP isn't actually used like that. Most engineers use frameworks (like Symfony, Zend, Yii, Cake, Laravel etc.) or at least components of these frameworks if they work on something very complex. NIH is a thing of the past.
> If that's how PHP is used in practice then it's fair to complain about PHP.
If shitty developers use a language then it's fair to complain about said language? Really?
I don't choose my music by popularity, and won't try point you to popular repositories. You need to look at your needs, and decide what works for those needs. If that is php, that is great. No need to look further. If php doesn't cut it for you, you will have to decide what you need and find a solution that works for that.
Speaking anecdotally, I got exposed to PHP before I did to Python. I tried Python after hearing how much more amazing than PHP it was. I understand why people say that now, because Python has a "flavor" that I suspect most programmers find more pleasing. I also learned another thing: I am not more productive in Python than PHP.
PHP, like JavaScript, is a language constructed out of good parts and bad parts. They both suffer from the same ailments. It is painfully easy to construct code examples of their horribleness, there are mountains of bad code floating around the internet, they lack essential facilities like strict typing, many facilities that they do provide should be carefully avoided, and the overall flavor of the language is just plain weird. However, PHP, like JavaScript, allows you to be remarkably productive.
JavaScript got out of the doghouse when Douglas Crockford wrote his book and converted the JS community to the jslint style of programming. JavaScript didn't change, but the perception and practice of it did. I think PHP needs a similar champion who is willing to say: PHP can be a good and proper language, provided you use it correctly, and btw here is a tool that tells you whether you're doing that in your code.
I am a PHP programmer, and to your high and mighty attitude I say: screw that. There's nothing wrong with being a PHP programmer.
I think the only reason PHP is still relevant is because it's so damn accessible (kinda like w3schools), every shared hosting provider under the sun gives you apache+php, and when you're starting learning web programming shared providing is the way to go.
Why do you say php and Javascript suffer from the same ailments? They suffer from a few of the same ailments, like a crappy/confusing stdlib (although you don't see mysql_real_escape_string in javascript's API) and funky invisible type coercions. Lack of true OOP in javascript, though confusing to beginners, is a design feature as far as I'm concerned, prototyping gives you the tools to implement OOP however you like. But javascript has had a known design pattern from the beginning, which is very powerful and useful once you learn it. I strongly doubt a (another?) phplint at this point would change anything.
As for the "anecdotally" slide, I read the last statement as a conclusion of the previous stats, which didn't make any sense to me. Either I am completely misreading it or you are taking the phrase "anecdotally" far too literally.
PHP is the dream of a one-man team that gets paid by the hour. Get contract, slap something together that makes the client willing to pay, throw it all away and do it again when the client wants a change.
$productid = "0x4zz5";
print $productid + 4;
If not, then PHP doesn't work. End of story.
Implicit type conversion is evil, and I don't see how PHP's sin of favouring string -> number over number -> string is any worse than, say:
// Javascript
console.log(+(+!![]+(+[]+[]))); // outputs the number 10
// C, Java
float celsius, fahrenheit1, fahrenheit2;
celsius = 100;
fahrenheit1 = celsius * 9 / 5 + 32;
fahrenheit2 = 9 / 5 * celsius + 32;
assert(fahrenheit1 == 212); // OK
assert(fahrenheit2 == 212); // Oops! It's 132. What happened?Of course, it is better to manually convert.
print $productid . 4;I wish I could use static typing too, but when I can't I use vars that are somewhat intuitive.
I'll look at Erlang. I'm trying to wedge self-teaching Python into this semester.
For start:
http://www.maht0x0r.net/library/computing/erlang.pdf
http://rosettacode.org/wiki/Category:Erlang
http://ruslanspivak.com/2007/09/09/erlang-for-python-program...
and you need emacs24+ for good ide and programming with erlang or just use interactive shell erl for initial start.
Properly mocking methods allows you to get rid of this unknown and say, "The submit() method will return an array of this specified data" without Authorize.net ever getting a ping.
With static properties, the problem is that they do have memory. If you change it in one place in your codebase, that static property will then be changed across your whole codebase for that execution, even if you have multiple, separate object instances.
As far as static properties go, if you're mucking with those you're back into the world of storing state, which OO is more suitable for, but the whole point is to avoid doing that wherever possible. :) What I was getting at before is that we really use a mixture of both real OO and procedural with class-namespaces-static-methods wherever each thing makes sense, but given the nature of what most backend PHP is trying to accomplish, the latter ends up being the majority.
You missed the problem as well. Don't ask for trouble by creating broken situations.
I can't speak for anyone else but for myself regarding this but here we go. I have 12 years experience with PHP, it's my primary language, I know it's got pros and cons, I accept it for what it is and work around it. I know Python is better in terms of standards in languages. I know PHP started out as just a few tools and morphed into a language. But here's what's keeping me from switching to Python or Ruby, or heck even Node.js.. Experience...
Yes I can learn a new language basics pretty easily, but am I gonna be able to write a complete app in say RoR with very few google searches or even looking at the manual as fast as I can in PHP? No... I have been playing around with node.js for 2 years now, long enough to know it pretty well, and yet I can still code circles around node.js with PHP.. 12 years using this language as a primary, it'd take me at LEAST 4 years to even get close to the scale of how well I can code in PHP.
It's just not feasible for me to just up and leave PHP for something "better" based on a few cons and other peoples opinions.
> Yes I can learn a new language basics pretty easily, but am I gonna be able to write a complete app in say RoR with very few google searches or even looking at the manual as fast as I can in PHP
That's debatable. I saw someone finish and sell a property management web app in Rails, without knowing Ruby and next to no knowledge of Rails. I wouldn't recommend it. Rails just gives you a lot of things for free. This is getting to much into a framework vs language thing, which I don't like.
I was just making a case for Ruby as opposed to PHP, especially if your job involves more then just web stuff.
As far as PHP frameworks copying Rails, I'm pretty sure that's just accepted as fact. If you don't use frameworks then that's cool.
harshreality argued that, because PHP's implicit type conversion leads to weird behaviour, "PHP doesn't work. End of story."
In that case, nearly every widely used language (with the possible exception of Python 3) "doesn't work. End of story." That's not a very interesting or useful story to tell.
So, you'd probably be pretty ornery too when other people had more discipline to use the language without shooting their foot and were also employing it successfully. You'd probably want to make assumptions, and word hard to belittle them. Insult them.
And they'll talk about beauty. And zen. And wonder, and joy in a language. And they'll gloss over the major problems that it suffers from. They'll imagine all is well. And they'll try and tell you that nothing good can come from the tool they once used to shoot themselves in the foot.
Just walk away. Because you still have two feet.
And if we're talking about consumer products like facebook, it doesn't even say anything about how fast your programming language is since performance is dominated by database access time.
At best, we can try and claim that Facebook found PHP to be insufficiently expressive/safe/suited for them once they had X number engineers making Y number of changes per day.
Maybe they really could "move fast and break stuff" with 200+ engineers trying to commit to a vanilla PHP codebase.
If I make a function meow(MyClass $meow) { } it will throw errors if anything other than a MyClass is given to it, including NULL.
It's the computer equivalent of a bozo worker who does something random everytime they don't know how to do their job, and then tries to hide any consequences while whistling innocently.
The whole total function has something that it's expected to do, some value that it returns in the end - and if it can't do that then any returned value is useless and wrong anyway; and automatic, silent type conversion is the worst possible choice of action, since it not only doesn't work, returning a value that you didn't intend (as other options); but in addition makes the actual bug hard to find and potentially corrupts a lot of stored data before you find the bug.
I've also hacked up a bunch of open source projects (wordpress, joomla). No tests, so you never know what you've fucked up, and you spend more time checking for regressions than actually adding that one feature you want. That's not how you do large scale software development, that's how you add pack on billable hours by charging your client for the same work 100 times.
Really, it's boils down to taste more than anything else. I've yet to see a tasteful application written in PHP.
If I were to summarize it with one anti-pattern, it's that PHP encourages people to mix unrelated parts of the program into one place, making testing, maintenance, and understanding nearly impossible. I should be able to test your app's interface without having a database. I should be able to write a database query without reading any code that touches HTML. And it's something I never see in PHP code.
So the answer is No, you don't have any experience with professional PHP, and you haven't used it in more than half a decade. Could have just said that.
Really, you judge PHP off of Wordpress and Joomla?
Haha, you are actually the problem you complain about.
Half assed "developers" who try to build anything large scale with WP or Joomla, people who can't be bothered to keep up with the changes that happened in the past 5-10 years but still complain about how shitty everything is.
As I said earlier, I agree that implicit type-conversion is evil. But if I refused to use flawed tools...
They're native to PHP http://php.net/manual/en/language.oop5.abstract.php
I think the primary difference is PHP is web first: it was designed to be a language for the web above all. Everything else is tacked on. On the other hand, Python is useful for a whole array of problems and a website is just one problem you can solve with it.
This will only accept an object that is_a MyClass. It can either implement an interface MyClass, extend an abstract MyClass, extend a regular class MyClass, or be the actual object MyClass.
Namespaces have nothing to do with this, other than you being able to use the "use" statement at the top to alias it.
Like php code, php itself is often confusing and hard to decipher, currently I think it of it as a C dsl for web stuff that people mistake for a high level application framework.
Like C, many people learn basic syntax and functionality in school or as a side project. Unlike C, people believe that that their skillset is the one required to build a complex server side application combined with a web ui.
If you realize the mismatch and account for it, you can build great php websites. The problem arises when people assume they are getting a 'faster/cheaper' .Net/Java stack and start to hire programmers into that structure.
The net result is a clash between people that are using PHP as intended, and people that have been subjected to the misuse of the php.
1. http://stackoverflow.com/questions/5647598/cannot-import-use...
I use PHPUnit, the de facto standard for testing php code.
To create a proper mock in it, you use getMockBuilder()
1) You've implemented dependency injection, or
2) You're using a container
For example, in PHP you can't mock something like "$foo = new Bar();". The code is right there, it's saying exactly what it wants, you can't return a fake class (unless you do some ugly magic).
However, you can pass in an object that is_a Bar, either injecting it via DI or storing it and then retrieving it from a container.
With code like Foo::Bar() - that's it. You're tied to the Foo class, Bar() method and you can't change a thing about this.
I work with WP, I'm the first to recognize it's an old codebase with all defects this entails, but popularity has value. Value that PHP critics dismiss too lightly.
All that dependency crap is only a result of your AbstractTestingFrameworkMethodFactoryClassMockMethodGenerator() and similarly useless abstractions, anyway.
A simple module system can be implemented in a single function and referenced from test code as easily as:
test_requires('module1','module2');
Purely procedural tests are as easy as:
assert_equals(function_one('example_input'),'expected_output'); assert_not_equals(function_two(true),false);
Full featured test framework:
function assert_equals($a,$b) { return $a==$b; } function assert_not_equals($a,$b) { return $a!=$b; }
(Edit: I don't believe I missed the point - 'dependency injection', a recent term in PHP, essentially means tightly coupling to an entire DI system instead of directly to a single dep as demonstrated above. Either way, loose coupling is a concept to strive for as far as reasonably possible - not an absolute requirement. If your code requires something else, then it requires something else. The solution is not to create a new AbstractPretenderOfTotalWorldVisibilityEvenThoughControlFlowIsNowAllOverTheShop() After all, if you carry that tight coupling argument further you could claim that by virtue of writing PHP at all you are tight coupling to a certain, if broad, class of processor architectures. There has to be a limit somewhere! Mostly, that's determined by legibility/maintaintability and programmer time, not by abstract measures of correctness.)
Don't tell anyone else, though :p