Slack usesphp for most of its server-side application logic, which is an unusual choice these days. Why did we choose to build a new project in this language? Should you?
Most programmers who have only casually used PHP know two things about it: that it is a bad language, which they would never use if given the choice; and that some of the most extraordinarily successful projects in history use it. This is not quite a contradiction, but it should make us curious. Did Facebook, Wikipedia, Wordpress, Etsy, Baidu, Box, and more recently Slack all succeed in spite of using PHP? Would they all have been better off expressing their application in Ruby? Erlang? Haskell?
Perhaps not. PHP-the-language has many flaws, which undoubtedly have slowed these efforts down, but PHP-the-environment has virtues which more than compensate for those flaws. And the options for improving on PHP’s language-level flaws are pretty impressive . On the balance, PHP provides better support for building, changing, and operating a successful project than competing environments. I would start a new project in PHP today, with a reservation or two, but zero apologies.Background
Uniquely among modern languages, PHP was born in a web server . Its strengths are tightly coupled to the context of request-oriented, server-side execution.
PHP gets several things very deeply, and uniquely, right.
First, state . Every web request starts from a completely blank slate. Its namespace and globals are uninitialized, except for the standard globals, functions and classes that provide primitive functionality and life support. By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1 . State does reside in places other than the program heap, of course, and it is possible to statefully mess up a database, or memcache, or the filesystem. But PHP shares that weakness with all conceivable environments that allow persistence. Isolating request heaps from one another reduces the cost of most program defects.
Second, concurrency . An individual web request runs in a single PHP thread. This seems at first like a silly limitation. But since your program executes in the context of a web server, we have a natural source of concurrency available: web requests. Asynchronously curl’ing to localhost (or even another web server) provides a shared-nothing, copy-in/copy-out way of exploiting parallelism. In practice, this is safer and more resilient to error than the locks-and-shared-state approach that most other general-purpose languages provide.
Finally, the fact that PHP programs operate at a request level means that programmer workflow is fast and efficient, and stays fast as the application changes. Many developer productivity languages claim this, but if they do not reset state for each request, and the main event loop shares program-level state with requests, they almost invariably have some startup time. For a typical Python application server, e.g., the debugging cycle will look something like “think; edit; restart the server; send some test requests.” Even if “restart the server” only takes a few seconds of wall-clock time, that takes a big cut of the 15 30 seconds our finite human brains have to hold the most delicate state in place.
I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and complex software project’s life cycle, these productivity gains compound.The Case AgainstPHP
If all of the above is true, why all the hate ? When you boil the colorful hyperbole away, the most common complaints about PHP cluster around these root causes:Surprise type conversions . Almost all languages these days let programmers compare, e.g., integers and floats with the >= operator; heck, even C allows this. It’s perfectly clear what is intended. It’s less clear what comparing a string and an integer with == is supposed to mean, and different languages have made different choices. PHP’s choices in this department are especially perverse, leading to surprises and undetected errors. For instance, 123 == “123foo” evaluates to true (see what it’s doing there?), but 0123 == “0123foo” is false (hmm). Inconsistency around reference, value semantics . PHP 3 had a clear semantic that assignment, argument passing, and return are all by value, creating a logical copy of the data in question. The programmer can opt into reference semantics with a & annotation [ ] . This clashed with the introduction of object-oriented programming facilities in PHP 4 and 5, though. Much of PHP’s OO notation is borrowed from Java, and Java has the semantic that objects are treated by reference, while primitive types are treated by value. So the current state of PHP’s semantics is that objects are passed by reference (choosing Java over, say, C++), primitive types are passed by value (where Java, C++, and PHP agree), but the older reference semantics and & notation persist, sometimes interacting with the new world in weird ways. Failure-oblivious philosophy . PHP tries very, very hard to keep the request running, even if it has done something deeply strange. For instance, division by zero does not throw an exception, or return INF, or fatally terminate the request. By default, it warns and evaluates to the value false. Since false is silently treated as 0 in numeric contexts, many applications are deployed and run with undiagnosed divisions by zero. This particular issue is changed in PHP 7 , but the design impulse to keep plowing ahead, past when it could possibly make sense, pervades libraries too. Inconsistencie
本文开发（php）相关术语:php代码审计工具 php开发工程师 移动开发者大会 移动互联网开发 web开发工程师 软件开发流程 软件开发工程师