Great for prototyping, or just to encourage new programmers (as they can see results almost immediately).
Though PHP was essentially thrown together initially so had a massively inconsistent standard library, had some insanely unsafe defaults for a few major versions, and other issues that it is very valid to complain about. It was also closely associated with mysql which at the time played very fast and loose with data integrity (2008-02-31? - perfectly valid date to store! Foreign keys? Let the business layer worry about rules like that! Transactional integrity? Again, sort that elsewhere!) in the name of ease & claims of performance - the two shared bits of each others reputation.
I also just trashed an extremely repugnant PDF template processor, first with fpdf.org, then with tcpdf.org - far from perfect, but improvement a thousand fold.
Exaggerate, you say? Can I interest you in COBOL on my VAX (I'm not kidding)? Or perhaps (is this is too new-fangled) assembler under EXEC-8 on OS2200?
I do like the PHP solutions very much, and yes, I work in a museum.
2. Adding a bunch of bogus escaping routines isn't an excuse for an incredibly poorly conceived off language, or continuing using it in production in the presence of superior solutions.
In fact, I'd go so far as to say if you're selling PHP solutions/consulting in this century for apps managing ecommerce or any other kind of PII, you should demand your customer signs a liability waiver. If you can even disclaim liability for gross negligence in your jurisdiction, that is.
For highly dynamical apps, consider porting to JavaScript on the client side, and use PHP only as a service backend language. That's what I understand newer PHP frameworks are doing; but this will only be attractive for migrating legacy PHP apps rather than bring new users.
Edit : large part cut for brevity
I really should have composed what I just said, much better than I have done -/so I have cut the bulk from my first too enthusiastic version / I mean to describe how much you can get running with just BASIC language skills and, at least atop of VMS, and buying the right licenses, that answer is "anything almost anything that you can imagine from a power station to a stock exchange ". Stack Overflow and POF running tiny amounts of hardware under Windows Server aren't rare cases of the potential for leveraging commercial tools. If VMS is more palatable than Windows (and certainly I will not compare the two for TCO) and the Intel architecture pricing for RDB holds up I totally believe that SAAS on VMS can be a viable alternative platform capable of making a minor industry of positions for the experienced programming talent for whom ageing has become a invisible barrier to retirement or even employment and if that's possible, then there's right there the environment wherein a generation of younger engineering minds can both take respite from rat race technology change and learn from direct experience to write the reliable systems for replacing what I fear is a current batch of the most fragile infrastructure building in modern history.
edit : incidentally, I think the entry level salaries the FAANG group is paying is a coincidentally perfect match for the price for a consultant from IBM or whoever and I don't think this is a accident by any means, only it didn't seem to work out how the old big firms would have wanted things..
edit, again, mea - my conspiracy being IBM et.al killed the good development tools in hope for being able to bill for consultation only they didn't count on the ability for big tech competitors to dismantle entirely other industries to feed paying salaries at the level of consulting rates and monopolizing the talent in that way.
RAD tools were focused on Desktop application development and web suddenly took over everything.
Nope. The web was both cross platform and insanely easy to use at the same time. It also cost an order of magnitude less because developers didn't have to implement an entire ui, printing and a bunch of code to make little things like the clipboard and resize window actually work. The web was vastly superior to the 1998 4gl scene and it was crystal clear in 98 that it was the future. So sure you could make a order entry crud app with your favorite 4gl and your order entry team could use it. With the web, I could make an order entry system and the whole world could use it...
Rails made this approach viable at the time.
Rails didn't get big until 2006, eight years later than this time period =).
Wait for the crows.
In systems where actual row deletion doesn't actually happen its kind of a pointless kick to the nuts.
Now I have to create things in a specific order for no reason other than foreign keys say so. When you're using uuids for reference keys you're not beholden to what order you insert you can have these things span databases or have separate systems do the insert.
For a naive example, maybe I have an order A, and two orderliness A1, A2, why do I have to create A before I create A1 and A2. Why can't I loadbalance those three operations to different systems that insert at different timings.
Eventually they all line up, and my system is resilient enough to be ok with that.
With foreign keys you're just beholden to some feigned idea about data integrity but it's mostly bullshit.
The other common situation is when you need to backup tables and restore them elsewhere in whatever order you want, foreign keys just get in the way.
But otherwise, I disagree strongly.
> feigned idea about data integrity but it's mostly bullshit
I call BS on your call of BS.
> The other common situation is...
If that is common in your production environments, then I never want to work with your production environments.
> foreign keys just get in the way.
Disable them, do the jiggery-pokery, and then replace them. Again, but not in production systems.
If FKs are an inconvenience day-to-day then you have something seriously wrong somewhere. They are protection against bugs and other unpredictables causing corruption of data that other code later relied upon being correct.
A simpler language for a simpler time.
Isn't that still the case?
At least here in Europe the word Backend Developer is basically synonymous with PHP Developer.
Every other language for backend development is pretty niche. Sure there is Java (and C#) for the enterprise but that was already there back then. Ruby had a good run but modern PHP with frameworks like Laravel could reclaim most productivity benefits so not that fierce of a competition. JS with node, sure but I mostly hear it in the context of micro services which is the opposite of wanting to get something done.
> PHP barely ages - from 1999 or 2010 or 2020, it looks similar and works fine.
Yes but no. PHP takes stability and backwards compatibility quite seriously but the language and culture around it has changed tremendously. The wild west days are long gone, it has gotten much more professional and mature while adding many modern language features.
Pretty much, I've seen PHP powering traditional companies with revenue in the hundreds of millions (approach billions).
Basically the only two technologies I touch these days are rails and php. I'm not filtering out other tech stacks, these two are just absolutely dominant for this type of company.
The place I'm thinking off that I know uses PHP for everything is a bricks and mortar retailer/manufacturer, I think last time I looked their revenue was ~£500m a year.
Their software was however awful in the worst ways :).
> At least here in Europe the word Backend Developer is basically synonymous with PHP Developer.
Here in Norway backend mostly means JVM or dotNet it seems. Last I touched a PHP installation that wasn't a prototype or a blog or something was in the spring of 2009.
That said: In my opinion PHP has been massively underrated in HN circles.
Even on basic hardware, hundreds of requests per second are trivial -- assuming you aren't loading a bunch of files ("require") or making 800 trips to the database to load the site.
I've never found PHPs performance to be a limiting factor, even when I was dealing with dynamic page loads coming in at sustained rates between 50 and 100 per second, and this was on PHP4/5, slow (400MHZ), single core, low ram system. FAMP stack.
I assume Java apps are the same way -- I've never encountered (to my knowledge) a java-based website that wasn't slow. I assume anything that relies on a huge framework probably also had that framework to blame for most performance problems.
When you just had expensive queries that were already optimized, you’d use IPVS, haproxy, apache, or RR DNS to help. This was before nginx existed. Static caching pages using Perl scripts to crawl the site and write out everything static as html files worked well too. Varnish was a real game-changer when that came out.
Edit: forgot about Gearman for distributing work as well. Now people probably build the same types of things using SQS and functions.
PHP was never the bottleneck, and the web could definitely “feel” faster back then on hardware an order of magnitude or two slower than we have today with these >10MiB index pages, CDNs and parallel downloads be damned.
And by squeze I mean copy 30 lines or so from their hello world tutorial and run: php start.php
I used a PHP process running in the background using stream_socket_server().
IIRC my computer had a 5Gbps connection to localhost using HTML5, and fractionally less using Flash :>
...which meant that PHP was writing to the web browser at 5Gbps.
PHP was simple to use, and to understand its logic, because it was embeded into HTML itself if you want to. No need to write views, controllers, templates, anything. And most of the shared hosting (paid and free) supported it.
[1]Includes were like magic back then because if you had a heavy content website with a lot of inner pages (fansites), updating the navigation sidebar was a pain in the ass. Originally they were made with framesets, later iframes (with no borders, but if the content changed, a scrollbar appeared). When I (and my friends) started to use PHP and be able to use includes, it was awesome.
(Edited to fix formatting)
I sometimes find myself thinking about teenagers getting started nowadays and the accessibility of development, but I suppose there are a lot more resources now than the early 2000s for some enterprising kids to get started.
Today it still works.
Similarly to how one can start writing python scripts without having to know OOP, maintainability, or even functions. It will suck, but it is a valuable learning step.
With PHP you can just start typing in your file and produce output. Even with lightweight frameworks like Flask there is boilerplate.
And if you really need php-fpm (which you should, anyway), at least in Ubuntu (never set up on other distro), the boilerplate nginx config is there.
Neither mod_php nor php-fpm is related to the built-in server though. Both are designed for production.
> Set the PHP_CLI_SERVER_WORKERS environment variable to the number of desired workers before starting the server
https://www.php.net/manual/en/features.commandline.webserver...
The implications of what this meant for security were very important too, but in a negative way. Instead of an application with a single or few small entry points (like CGI), you could just design your PHP app with a bunch of files spread across the exposed public directory structure, and for a long time this was the reigning paradigm for PHP.
This, combined with the extension controlling whether it was processed as a PHP script or a plain text file meant that anyone making a quick and dirty backup of a file they were changing that didn't consider this would often end up exposing files to the public they didn't intend (mv config.php config.php.bak).
Additionally, since most people were running on shared hosting platforms and PHP was usually run as the webserver user, and many applications were designed to be dropped entirely into a public web structure, any capability for writing locally (like allowing file uploads) often consisted of setting a directory world writable to drop files in. Even ignoring how often people screwed up setting permissions and set everything of theirs world writable, even when done correct this usually ended up being security through not-so-obscurity, since common apps had default locations they used more often than not (customizing that required more user interaction and knowledge to set up, which was against the ethos of "drop in and use" PHP heavily leaned on initially).
PHP's ease of use was the ease of use of Windows 95 compared to Windows NT or Windows 2000. Sure, things are easier when you don't have to care about users and permissions and security. But you need to bootstrap any success you have into fixing those problems ASAP.
PHP was always a victim of it's own success in this regard. The thing that made it easy to use for people was that it did away with a lot of the security concerns that were (barely) in place at that time, and the effects of that are what made it a nightmare for those managing it, and often at one point or another those using it as they were bitten by these problems.
I'm glad we've all moved on from that. PHP did a lot to make it easier for people to do stuff online, and that in itself is a good thing and a laudable achievement. I'm unsure if it was a net gain though. It's too complex for me to easily say it was one, nor that it was definitively a net loss.
How often do people leak things via S3 because they couldn't set the permissions properly? Same thing as you mention, except it's yet another layer that has to be maintained.
I went from Perl to PHP, and my productivity definitely improved, and the speed of execution also improved significantly. mod_perl was available, but I was pretty well switched to PHP by the time I really looked into that.
I think the fact that it's another layer and not essential for anything is a pretty good reason why it's not necessarily the same.
What I'm talking about is the default or minimal install complexity and how that affected what was to come. I'm not sure anyone considers S3 a default or minimal config for a website or code execution on the web.
I do agree it's much easier to add complexity these days though, and there are plenty of resources that probably encourage it.
> mod_perl was available, but I was pretty well switched to PHP by the time I really looked into that.
You didn't miss much. While mod_perl was first released within a year or two of the first version of PHP, it works in a fundamentally different way, as wasn't really suitable for shared hosting, so it was never going to have the same popularity. mod_perl keeps a perl interpreter persistent per Apache thread, but it doesn't (can't) really completely separate one request from the next, and given's the prevalence of globals that Perl lets you tweak that affect how many built-ins function (and the ability to redefine portions of the symbol table), it wasn't really suitable for shared environments, just for applications which were mostly the sole purpose of the webserver.
In fact, the way it works is sort of to just take any file set to be handled by it, and eval the content of it in a sub (to deal with some scoping issues), and display the output. As you might imagine, this required special care to not accidentally create closures and pollute subsequent request handling with data in variables from prior requests.
The guy who was interviewing me was sitting their shaking his head like that wasn't a valid answer.
I wonder what would be the proper answer. Also if there is a proper answer, they shouldn't ask what your favourite feature is.
I hate it when people ask questions where they expect some sort of exact question to see if you think in the exact same manner as they do. Just ask me what you want to know or I'll pack my shit and leave.
For a PHP deployment this is all handled by a fully standardized Apache httpd (at least back in the days, nowadays setups became more fancy) and the PHP.user just uses (s)ftp to copy the files in and all works magically. Need to update? - Just copy the new files. This is the unbeaten simplicity. (Of course that breaks at some point, like imma high traffic site simply copying the files via sftp will lead to some request in the middle having inconsistent state etc.)
If the binary fails for whatever reason the application is either down or you have to have something ensuring it stays running. With PHP if it breaks, it'll be ok for the next run.
You say you just drop a golang binary into any linux enviroment and it'll just run. Except it won't. If I just upload the file it won't just run. I need to run the binary. Literally, you need to do more than just upload the binary to the enviroment. Where as with PHP with many hosters you do just need to upload the files and it is deploy. As you said you can't get simplier than just uploading the files.
Secondary, if you have to make exclusions to proof your point of simplicity then it is not as simple as you state.
Thirdly, your deployment would be unstable. If an error occurs someone would manually have to restart it. For any production deployment you would need supervisior. And if you were going to deploy a new version you would have to stop supervisor, stop your process, upload and then restart supervisor. Quite simply your trival deployment is not production ready and would not be how someone would deploy it.
I get it you like golang, I like it to, but PHP has it beat on deployablity. It's got years on it when it comes to improving the ecosystem around it.
Whatever you think it is that is simple about php, I am certain there is plenty happening behind the covers that you are unaware of. An environment built around supporting php is required.
A compiled golang binary only needs a linux system. That is it. Very, very simple.
Doesn't restarted failed processes last time I checked. Maybe I'm wrong but I am pretty sure there is a reason every sys admin I know uses supervisord to manage long running processes.
> Whatever you think it is that is simple about php, I am certain there is plenty happening behind the covers that you are unaware of. An environment built around supporting php is required.
You are as wrong about that as you are as wrong about golang being as simple to deploy. You're just consisently wrong.
> A compiled golang binary only needs a linux system. That is it. Very, very simple.
Golang binary requires the deployer to have linux system knowledge. Uploading files does not require that it requires FTP client knowledge at most or in some cases the ability to use a web based file manager.
Requring knowledge core operating system functionality do deployments is not simple. Just because a techincal person can do it, does not mean it is simple. If you can not teach your grandma to do the deployment it is not simple.
mod_perl worked without running an app server but I still don't know how other languages never implement mod_$lang or $lang-fpm that reloads code on change, so you don't have to place auto restart magic on development.
These days you need transpilers (but I don't blame the flourishing of higher level tools when JS, CSS kind of totally stalled from adding useful features and people never let go of old browsers), auto restart of app servers and other build procedures just to get started and that's one of the reason people stick to plain PHP/CSS/JS (loaded independently via script tag...).
We do want nice pretty slick GUI that does all that for cross platform to get new people started without asking them to do console magics. I know a few good ones but doesn't seem cross platform.
By far, the most useful tool in the box was probably MySQL. Before then, you had to work with flat files.
Oh, and "magic quotes" was a bad idea ;-)
Prior to PHP as part of a LAMP stack, I had indeed been cobbling Perl scripts and GDBM key/pair databases to do web apps for various projects and customers. The ability to just print to the browser with PHP without explicitly having to send HTTP headers was wonderful.
FLASK_ENV=development python run.py
You drop a file in your public web server folder and you’re done. Prior was CGI Perl scripts that hacked together how to access session and rest data. Or you had to develop in C. PHP had native support for the web. It also eliminate the need for an app server.
I’m still not certain even today, if anything exists that is faster to get a dynamic site up and running than PHP.