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.
Taking PHP Seriously (2016)
141–150 of 150 posts
Re: Taking PHP Seriously (2016)
#142I 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…
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)
#143This 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 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)
#144PHP 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.
Re: Taking PHP Seriously (2016)
#145I 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…
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)
#146The 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.
Not that big a deal at all.
Re: Taking PHP Seriously (2016)
#147Earlier 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.
Re: Taking PHP Seriously (2016)
#148Earlier 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.
Re: Taking PHP Seriously (2016)
#149Earlier 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.
Re: Taking PHP Seriously (2016)
#150Earlier 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.