Live data from Hacker News

Taking PHP Seriously (2016)

slack.engineering

141–150 of 150 posts

Re: Taking PHP Seriously (2016)

#141
post #105

Earlier quoted context omitted.

> Somewhat unrelated comment, but the fact that PHP got so good and most people are still not willing to give it a second chance goes to show how hard it is for a language to regain market share after people left for greener pastures. I guess some of the reasons why some devs would not chose PHP (horrid syntax, std lib mess, stupid error reporting system, language inconsistencies, the very existance of php.ini, overr…

Some of the most annoying things in the language (error reporting and type coercing in comparison operators) are fixed in PHP 8.

Some, not all. That alone should answer the question why aren't people coming back.

Re: Taking PHP Seriously (2016)

#142

I 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…

> Second, concurrency. An individual web request runs in a single PHP thread.

Erlang/Elixir (or any BEAM language) runs every request in a separate green thread which scales much better than OS threads since most of those green threads can be generously multiplexed on just 4-8 CPU cores due to 90% of the time being spent waiting on a database.

One OS thread per request is such a... strange thing to brag about in 2020.

Re: Taking PHP Seriously (2016)

#143
post #10

This seems to be an unpopular opinion in the tech world, but I honestly enjoy working with PHP. It's such a simple, robust language, and you can use it in many different ways, depending on what you're building (OOP, scripting, microservices, etc).

I'm with you. 10 years ago I was doing moderate 'shell scripting' type stuff in PHP - if I needed to scan a dir, parse some files, etc. PHP seems usually far more useful than trying to shoehorn the problem in to bash. And... writing shell scripts in Java ain't ever going to be a thing.

For general scripting where bash is a poor fit PHP and Ruby remain pretty solid to this day and I like them for that.

For web development though, not really. Elixir is much better there and I am saying this as a guy who had 8 years with Java and 6.5 years with Ruby on Rails (and consulted and helped 10+ PHP and JS projects in the meantime).

Re: Taking PHP Seriously (2016)

#144
post #76

PHP was the first language I learnt and although I don't use it as much today I still think it's a great language for startups. Languages like Java, Node, C#, etc are great but unlike PHP you can't just drag and drop a .php file on a webserver, point your browser at it and go. Basic things required for web development like connecting to a MySQL database are made trivial in PHP. Code is executed synchronously in PHP a…

And this has led to countless SQL injection vulnerabilities some of which WordPress in particular is still fighting with (in community extensions, not in their core) to this day. "Trivial to connect to a database" isn't a selling point. It is a liability when put in the hands of inexperienced programmers.

People really need to be taught about prepared statements. I once worked on a code base (mainly PHP and Java, with a bit of Perl here and there) where someone had built their own SQL parameter escaping. It still didn't work some percentage of the time.

Re: Taking PHP Seriously (2016)

#145

I 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…

It's likely a combination of the sunk cost fallacy and loving the syntax and maybe the enablement for quick iteration (and all 3 aren't specific to PHP at all).

I have the same opinion about Python btw. Just today I had to install a complex toolkit for flashing ROMs and you can guess that thing absolutely didn't work on the first try and I learned much more about "pip" than I ever wanted to.

Re: Taking PHP Seriously (2016)

#146
post #70

The argument that you don't have to restart the server after editing a file? I mean I've used a couple of web dev environments and I know for a fact that Rails, Django and Express all come with some sort of automatic reloading in development - provided by the framework itself or by a library. Quite sure there is a solution for most environments.

You still need to contend with build and startup times with those setups though, even if a rebuild is triggered on file save. With PHP, there's no such thing as build or startup, because it's interpreted.

An Elixir Phoenix's page live-reload never took more than one second even on a fairly weak i3 laptop for me. And on my desktop Mac it usually takes 0.2s.

Not that big a deal at all.

Re: Taking PHP Seriously (2016)

#147
post #79

Earlier quoted context omitted.

"Use an IDE" is never an answer to shitty language design. Shitty language design is shitty language design. That said, I cut my teeth on PHP and still have a fondness for it. It's especially great being able to deploy small little backend-driven pages with rsync or sftp in a pinch. I just discovered other languages and environments I enjoyed working in much better.

If there's room for Javascript, there's room for PHP. Both are sloppy, inferior languages, but both can do anything you need. And unfortunately, both have immense momentum from being first in the web game.

Unlike php, I can see Javascript slowly disappearing thanks to Wasm.

Re: Taking PHP Seriously (2016)

#148
post #79

Earlier quoted context omitted.

If there's room for Javascript, there's room for PHP. Both are sloppy, inferior languages, but both can do anything you need. And unfortunately, both have immense momentum from being first in the web game.

> If there's room for Javascript, there's room for PHP. PHP doesn't run in the browser. For browser programming there's literally almost no choice. TypeScript seems to be an improvement but even that compiles down to JS. Same for ReasonML and BuckleScript and Elm.

My point is that both PHP and Javascript owe their popularity not due to their merits as languages, but rather to being in the right place at the right time - time and positioning.

Re: Taking PHP Seriously (2016)

#149
post #148

Earlier quoted context omitted.

> If there's room for Javascript, there's room for PHP. PHP doesn't run in the browser. For browser programming there's literally almost no choice. TypeScript seems to be an improvement but even that compiles down to JS. Same for ReasonML and BuckleScript and Elm.

My point is that both PHP and Javascript owe their popularity not due to their merits as languages, but rather to being in the right place at the right time - time and positioning.

Yeah, sadly this is true. Inertia is a much bigger motivator than merit for many. I still struggle accepting that as a life philosophy.

Re: Taking PHP Seriously (2016)

#150

Earlier quoted context omitted.

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…

If premature optimization getting in the way is the norm for the projects you helped then I'm afraid that the people who crated them before that might not be as smart as you imply. A "smart" and/or a "senior" programmer knows not to optimize prematurely. But maybe I latched only on this one sentence and missed your point. Sorry if that's the case.

Honestly I think even junior developers know better, but we all make bad calls sometime and maybe worst of all, requirements can change and sabotage our best efforts.
Post reply on HN