Earlier quoted context omitted.
> It's a garbage language. I'm overwhelmed by how rich of a statement that is.
Its accurate.
[deleted]
Taking PHP Seriously
81–90 of 673 posts
Re: Taking PHP Seriously
#82I 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…
> "The next guy to join the company will clean up your shit" Is that acting in the best interest of your employer? or ripping your employer off? I think more like the latter. Imagine if other professions behaved like this, like finance or legal people. But suddenly because you are an "engineer" this is acceptable? If I was your boss I would fire you immediately. The world of difference between balancing trade-offs in…
other professions do behave like this. Look at the CEO of Wells Fargo or Valeant. "Fuck you, I got mine!"
Re: Taking PHP Seriously
#83I 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…
I can sign below your post as experience of PHP developer who "fights" each day with bad code written by PHP devs. There are a lot of frameworks like Laravel, Symfony or Zend which introduces a lot of conventions (folder structure, naming, PSR autoloading built-in functions, resources) but it is so often skipped to "get shit done". I would complain on many aspects of daily PHP-development like not using tools like the PHP-MessDetector (one of the rarest tool used by PHP programmers), PHP-CodeBeautifier (phpcbf) or PHP-CodeSniffer - Hopefully some open-source projects started using a StyleCI. Another things is database-related code. PHP developers tends to use ORM lately, but on five projects with Doctrine in 4 developers used it improperly messing with a 1000+-lined classes and storing annotation above the fields instead of file or even using Doctrine to get native database-connection via PDO driver to use query db with SQL only instead of DQL for any case. In google there is enormous list of articles about PHP optimization - the interesting thing is, that almost any touches the fact the PHP application should be "compiled" (cached) (e.g. for Laravel [1]).
Whatever I would say about PHP - how good or bad is - I am almost forced to use it - In central/eastern europe almost any company uses it to develop web-backend... but I really would love to jump to Node/Go/Golang-based development team (maybe even remotely).
[1]: http://laravel-recipes.com/recipes/60/optimizing-the-framewo...
Re: Taking PHP Seriously
#84The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…
Many CGI scripts were coded like this.
Here is an example in C: https://www.cs.tut.fi/~jkorpela/forms/cgic.html
Php was born out of trying to reduce a lot of that cruft and blending code and html output easily. And that's what initially made it a winner.
Re: Taking PHP Seriously
#85Earlier quoted context omitted.
>>Why are there no other "competitors" in this space? There are. Any language that supports either fastcgi, or runs as an apache plugin (or similar) functions in the "each request starts new" space. There's certainly others, but Python and Perl are both good examples. Starting new with each request does, of course, mean lots of re-work that shouldn't have to be done with each request. It does initially keep complexit…
I mean more of languages that actually "target" this kind of setup. I know it can result in a lot of "extra work", but I really feel like most of the pain of that could be abstracted away by the runtime. Nginx/apache setup a PHP process before the request comes in, so why couldn't you expose that point to your language and let the programming language do work before that point, even "snapshot"ing it to avoid re-doing…
I think python has exactly that with WSGI. With this protocol you make a module containg an "application" function object which is called by the server when a request arrives. On module load time you can do any required setup work.
(On my systems, by default there is some reuse of the loaded module, so you can leak state between requests. However it should be possible to avoid reused processes).
Re: Taking PHP Seriously
#86I 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…
I've been in the game long enough to realize how true this is. Good point. It will certainly make people here defend their sacred choices.
Not everything can or should be well engineered. People that always chase this are worshipping false gods. Does anyone have experience working on something that at one point actually met with the high ideals a certain mindset strives for?
Re: Taking PHP Seriously
#87> Hack provides an option that no other popular member of the MPDPL family has: the ability to introduce a type system after initial development, and only in the parts of the system where the value exceeds the cost.
JavaScript and Python both have systems that allow you to do this: JavaScript has the Google Closure Compiler, and, more recently, TypeScript. Python has a number of projects that use a common syntax [1], including PyChecker.
I say this not to "well, actually" the post, but just to be a gradual typing cheerleader. It's great! We should all be using it! All the time! Please!
Re: Taking PHP Seriously
#88I 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…
I used to be this guy, ie, who cares but not too much. A big reason why I switched to node. Let's me think less about code (JS everywhere), and more about the problem at hand.
Re: Taking PHP Seriously
#89> 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 somehow convince me that these virtues are specific to PHP, you can't convince me it does it well. Hence, MaxRequestsPerChild.
To quote Radmus Lerdorf,
> The real programmers will say "Yeah it works but you're leaking memory everywhere. Perhaps we should fix that." I’ll just restart Apache every 10 requests.
Clean slate, my eye.
Re: Taking PHP Seriously
#90The article points out that arguably the best part of PHP is the "shared nothing lifecycle". That each request starts new, and the process dies at the end of the request. It's by far my favorite part, and I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier. Why are there no other "competitors" in this space? Why do most other languages go with the alternative rou…
> I completely agree that it makes "reasoning about" (boy do I hate that phrase...) your program much easier.
Actually I have never seen that this was a problem in practice with the application server model. I therefore don't think this is a relevant argument.