301–310 of 673 posts
I find the virtues quite uncompelling, take for example >First, state. Every web request starts from a completely blank slate. Except for, you know, when you don't want to reinitialize everything everytime someone makes a new request. There are tons of things that you only need to run once. >I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive. Over the course of a long and…
Earlier quoted context omitted.
There's also $data->key->value[0], which is the default. But yes, dots are shorter.
There's a special place in hell for language designers that make you use shift that often.
I work on PHP at my day job (in a public company), before this, I came from Ruby, and .NET before that. I'm convinced the reason so many successful projects use PHP, is not because of any inherent nature of the language. I think it's the people who use it. They just don't care. A successful project needs to be started by someone that cares just enough, but not too much. If you're programming in PHP, you're not runnin…
This seems to assume that a developer necessarily hits an MVP in PHP faster than in other languages. This might be true when comparing with the tooling/dependency nightmares of JS/NPM, but a half decent Python dev can get a Flask app up and running in about 15 minutes.
Earlier quoted context omitted.
I cannot agree that OOP in Javascript is anywhere near good. Every library (like Backbone) includes a layer to emulate traditional Java-like classes with private/public fields and inheritance. Because until ES5 there were no syntax for classes, and in ES5 it is just a syntax for adding methods to a prototype and not a real class. And JS is too forgiving, even more forgiving than PHP. In JS you can misspell object fie…
That's because many dislike prototypical inheritance. It's perfectly usable. As for misspelling field names, the same is true for variable names in both languages, and many things in many languages. Here it's more justified, as JS semantics mean that the language can't know your intent in this case: check your spelling.
Earlier quoted context omitted.
Unless you are using ReactPHP, PHP doesn't handle Http requests in any serious production configuration, the server fronting PHP does( Apache ,Nginx). But PHP wasn't design with Async programming in mind so using ReactPHP is more than tricky since most operations are blocking.
That wasn't my point. PHP is great at HTTP because it doesn't have to do HTTP, and with php-fpm and mod_php it has first class support with Apache and Nginx. Node isn't very good at HTTP, Python doesn't have first class support with HTTP servers, Java has great HTTP libraries but is stateful, etc. If you want to handle HTTP requests quickly, reliably, repeatably, with minimal setup and maintenance, I still argue that…
Most languages don't "have to do HTTP" and those that do often do a pretty terrible job. Somehow Node not only does it, but does it well, where a bare Node process behind some load balancers is often enough to get the job done. PHP on the other hand needs all sorts of hand-holding to work properly.
Earlier quoted context omitted.
PHP isn't quick. It isn't faster than other languages. It's just a tool, and if you know how to use it well, it will be faster for you . If you want fast, build a static site. If you're iterating on your builds and doing something non-trivial, pick your tools carefully but don't be afraid to try new things.
Not quick as in execution speed, quick as in time from idea in head to working code.
For anything with a server-side component, PHP might be fast if you know a lot about how to get PHP up and running properly.
Node, as a counter-example, runs on Windows and POSIX systems indifferently, and with very little effort can be a self-hosted web server for development that can be deployed to production almost effortlessly.
If you have a favorite hosting provider which better supports some tools than others, certain things will be faster, but that's because of preference and familiarity rather than any factual differences.
> Virtues of PHP > First, state. Every web request starts from a completely blank slate. > Second, concurrency. An individual web request runs in a single PHP thread. > Finally, the fact that PHP programs operate at a request level Isn't this just "virtues of Apache modules"? There's mod_python, mod_perl, and mod_ruby. Are state, concurrency, and global requests virtues of these languages too? --- Even if you do some…
Also, most folks serve PHP applications in production under PHP-FPM/FastCGI.
Earlier quoted context omitted.
> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. Do you most of those need to happen at all, ever? In my mind, auto-loader is a sign that nobody knows what's being loaded (if they did, they would just require it). Requires should be full pathed (because have you seen what happens when you search the include path). Mysql_pconnect has been doing…
IMHO, developer time is more expensive than CPU time; I don't want or need to have to write out all of those requires. That's the job of the autoloader. And if I'm writing my code remotely well enough, each section only uses the things that it needs. Granted, there may be some things that each request get that they don't need with the autoloader. But I can optimize later. "Make it work, make it right, make it fast"
Burning cpu and maybe i/o looking for code all over the place is going to make it really hard to make it fast later.
Earlier quoted context omitted.
Unless you're writing in pure hand-optimized assembly language, 3 orders of magnitude in performance is way more than you could claim. PHP web requests commonly execute in hundreds of ms (of course, here I generalize mercilessly, but that covers most of cases I know of and that's what most sites aim for). So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds? I have v…
> So you say your non-PHP requests which would do the same thing would finish in hundreds of microseconds? I had a side project written in Elixir/Phoenix make it onto the front page of HN and it indeed was the case that the majority of requests were in hundreds of microseconds. The default log messages actually use "µs" which is kind of cute. I wrote about it here[0] and extracted a random sample of my logs and you'l…
Earlier quoted context omitted.
The downside is literally exactly the same as the upside: you have to bootstrap from literally nothing for every single request. Think about how ActiveRecord in Rails reads from the DB schema to generate it's magic methods, etc. This is usually done on startup or at least cached in memory once it's loaded. This is something that you have to manage more carefully with a PHP app since you can't have anything initialize…
> Code paths, auto-loaders, database connections, config files, etc. All that has to happen over and over for each request. So? If it takes We serve most of our requests in < 10ms, and we're not even on PHP7 yet.