Why do engineering blogs have to share this stuff? Is it an attempt to hire?
Taking PHP Seriously (2016)
121–130 of 150 posts
Re: Taking PHP Seriously (2016)
#122I don't doubt that PHP has some benefits. That said, the reasons cited in the blog post don't seem that unique to PHP.
> 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.
Is there a modern web framework where a failed request can crash the entire server? I'm not sure this is a problem in other languages.
> Second, concurrency. An individual web request runs in a single PHP thread.
Huh, so maybe this could be an interesting concurrency model. But it's not that different than say, Node's promises. The only difference is Node's promises aren't tied to literally making a web request.
The restarting the server problem also is not an issue. Almost every mature web stack I've seen has hot reloading. Yes, even in 2016.
There are certainly reasons to use PHP, but the trap I see a lot of PHP proponents fall into is assuming that the benefits they see are somehow unique to PHP. Laravel fans love to cite packages, migrations, the ORM, etc. as reasons to use PHP. I certainly think all of these are great features but they're not unique to PHP.
Re: Taking PHP Seriously (2016)
#123Besides the common gripes, the thing that ruined PHP for me was learning that empty("0") is true. I learned this the hard way when this edge case caused an incident and I spent half a week rewriting code to be...not that.
PHP has some great properties, and if you're tolerant of its sharp edges, great. But up until recently (and perhaps still?) it's got many of its safeties turned off by default. When I left PHP, (insecure) mysql bindings still came included pretty much universally, but often not PDO. They have every amazing helper function under the sun at your fingertips (urlencode and htmlentities!) but also some tremendously dangerous ones (backticks! variable variables!).
What's most striking to me is that Slack is 100% off of PHP now (onto Hack). There's something telling when neither the syntax nor the runtime nor the standard library are sufficient for the biggest users of a language. With recent versions of the core runtime finally getting fast, I wonder if they'll rip off the bandaid and break backwards compatibility to dull some of the larger sharp edges.
Re: Taking PHP Seriously (2016)
#124Earlier quoted context omitted.
Close I think - the best language to use is the one you will have the easiest time hiring good talent for. If you found a startup and all really love and are fluent in COBOL that's great but... good luck when it comes time to hire another employee.
If you have a good product new engineers will learn whatever language it is in. This very article is a perfect example. I'm sure Slack isn't hiring kids out of college with extensive PHP experience.
Php is pretty easy to pick up. We have way to many languages (Java ,Perl, php and python)
A lot of interns end up using php(symfony). If they know Perl or Java they can pretty much jump right in. Python they take a little bit though not much more.
Re: Taking PHP Seriously (2016)
#125The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.
No, really no, as someone who has worked on code bases where people followed the path of least resistance (PHP in this case) things turned into a giant mess of human suffering. Pick a language that has tooling for what you want to achieve otherwise everyone reinvents it or just makes a mess.
I’ve found giant messes of human suffering even where the tooling chosen was relatively excellent for the problem at hand. The part not being considered is that some problems are hard to solve and developers will make a mess even with the right tools. Programming isn’t easy, but especially in uncharted territory. I think that’s why choosing tools you at least know has merits.
I spent a lot of my career consulting as a mess cleaner, more or less, and even very smart people end up making a mess sometimes. Time constraints, shifting goal posts, all of it.
I’d say the worst thing I ever see, regardless of tools, is premature optimization getting in the way of everything else.
Re: Taking PHP Seriously (2016)
#126I get it. Old PHP was a joke, so people (including me) are biased against it.
I would personally love to get beyond that bias. However, every single time I install any piece of software written in PHP, it's simply a nightmare (e.g. Matomo, rss-bridge).
Unhelpful error messages, unexplained or undocumented features, all held together with metaphorical duct tape.
I always have to dive into the source code to figure out things that a README or tutorial should be able to help me with.
I can't recall ever doing that with tools written in any other language.
Is it simply that PHP programmers care so little about their products?
Re: Taking PHP Seriously (2016)
#127I don't doubt that PHP has some benefits. That said, the reasons cited in the blog post don't seem that unique to PHP. > 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. Is there a modern web framework where a failed request can crash the entire…
Most languages have global or module-level state that can leak between requests. Hack deliberately avoids this.
Re: Taking PHP Seriously (2016)
#128It's like an ugly C. It's a perfectly reasonable choice for web development, just like a Chevy Caprice is a perfectly reasonable car for a taxi service (as evidenced by the thousands of them in NYC, still plodding along). You'd still rather ride in a Mercedes E430 taxi (long time European standard)... unless you had never experienced both, in which case you probably think the Caprice is just fine. And if you knew Rub…
What a load of bolax. A language is nothing more than a hammer or a saw. PHP is just like the other languages you mentioned very mature. It's up to the developer to make good furniture. Entirely different skillset and not linked to a language.
I have seen low level drivers for hardware written in PHP operating for over 15 years. I have seen JavaScript used in a medical device.
You sound like that creepy negative 'you don't wanna hire' developer complaining about everything you have never worked with.
A good developer generally appreciates most technologies.
Re: Taking PHP Seriously (2016)
#129Why do engineering blogs have to share this stuff? Is it an attempt to hire?
Yes.
Re: Taking PHP Seriously (2016)
#130The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.
I espoused this sort of rhetoric until I worked at a PHP shop. Every other discussion was about problems posed by the shortcomings of the language, crossed with mistakes made by past staff. It's so easy to make assumptions about "good actors" and "reasonable developers" that just fly out the window with a team that picks PHP and/or doesn't know much else.
That's true, I've made amazing things with PHP, but as soon as you throw some more people on the project, especially people who pine for their JS or Ruby and don't want to accept the PHP way of doing things, you get a shitshow of epic proportions.