For me it's too late. I used PHP when it wasn't "mature" yet and hated it. There something blocking me now from ever going back to check it, no matter what its new features might be.
I cut my teeth on it years ago, I don't hate on it for cheap jokes. That said I don't know why anyone would pick it to start a new project in 2020. We've been lucky to have so many new and established options that are better in almost everyway.
If my project is "big enough" to warrant something like Laravel, I would just pick Rails or Phoenix over it any day.
I find both those languages much better to work in and I just feel like I'm getting things done way faster. If its smaller than that, I'dd definitly just pick go or node with express or go maybe.
I work with PHP 5 days a week through work and even a few years into it, i still do not like it. Its feels like a mess compared to the other languages I work with for my own projects. Even when working with something like Laravel which do mask a bunch of the pain points of the language, it still feels cumbersome IMO.
I think it depends on the types of project or the target of the said project.
Recently I had to develop a very small CMS that manages personal web pages and it was a requirement that it could be installed very easily (i.e., by copying a single file) on virtually any hosting provider. PHP was (and is) still the natural candidate for such projects.
you can run PHP pretty much anywhere, even the cheapest VPS probably has PHP, as well as all managed hosting. For python, go or other languages it can be more tricky if you're looking for cheap hosting / VPS
With docker containers and the numerous PaaS/FaaS runtimes, does that really matter? You can run anything just about anywhere these days, cheaply or even for free.
For average business owners who buy a WordPress template and some 5€ hosting in order to set up a business card web site on their own, on the other hand, it matters a lot. So if your project targets that group of people then PHP is pretty much the only option; anything more complicated than an FTP upload/MySQL import is pretty much to advanced for them and they generally aren't interested in learning new skills just to get a web site online.
Who's doing that anymore? Either you (or your staff) are technical enough to manage installing a web framework on a server, or you use any of the numerous managed sites instead. (Squarespace, Wix, Webflow, Wordpress.com, Shopify, Facebook, etc)
The last thing a non-techie business owner needs is to worry about setting up a random server with bad PHP code.
There's plenty of businesses selling business card web sites built on WordPress. They usually install it on whatever hosting the customer orders and then leaves the rest up to the customer.
I've worked with PHP since 5.4, and to me the language has not been the obstacle, it has been my own skill-level that has held me back, and still is - I lack very much the core architectural skills in getting forward as a developer, among many other things.
I've seen some codebases using an even older version, and I think I can understand where people are coming from with their angst towards the language - but I think we should look at ourselves before we jump to the bandvagon of just hating something blindly - I remember being part of the "Apple sucks" group for no other reason than hype, and now I've used one for years as a work machine.
This has been my experience too. Ten+ years ago I had already concluded that the biggest problem PHP has is the community. Googling for "php mysql" you still end up on w3schools and the like where SQL injection is still not emphasized. Everyone was making their own frameworks and software from scratch. My last foray into PHP, and my realization that it's not actually all bad, was working in Zend Framework (iirc this was also when Ruby on Rails was fairly new and gaining popularity fast).
I haven't touched it (beyond very basic edits on my website, wordpress etc) for over a decade, but recently I inherited an older codebase at my new job. The existing codebase is an absolute mess, worse than the shit posted in those tutorials I mentioned.
But as part of the job (beyond rebuilding the application), I also had to add a big new feature to the application, a REST API. Keep in mind that due to constraints on the systems we install on, it had to be made in PHP 5.2 or 5.3 - one difference being that the older version doesn't even support an array creation shorthand (`$var = []`).
I could keep interactions with the existing codebase to a minimum. The rest was... actually surprisingly all right, thanks to me knowing what a REST API is and how to structure an application properly.
I did have to basically write my own framework (sigh) because pretty much nothing is still available that works on pre-array-shorthand-versions of PHP, but it was fairly minimal; an off-the-shelf router and URL matcher (can't be arsed with writing that myself), middleware for authentication, and a simple class structure to encapsulate different output formats (json, csv, streaming plain text).
Granted, this old version of PHP is seriously rough around the edges, and at the time it already represented great advancements in the language. I mean before 5.4 the language didn't even have a function to set the HTTP response code (you had to write the header manually).
I got back into web development in the last year or so. Previously I did mostly Python/Django and then 5 years of something unrelated to dev. Now I'm working in a fairly typical PHP/Wordpress mixed joint, and now I understand why PHP has the bad rep - because it allows/tolerates/even encourages bad practices (and beyond the usual "shoot yourself in the leg" we can see in other popular/common languages). And I guess that is one of the reasons why a lot of libraries/plugins/php code out there is simply bad. For example: Seeing heavy mixing of PHP code and HTML output in 2020 is a horrible sight for me (and it's waaay to common in what I saw).
Of course you can write good code in modern PHP, but you can write really bad stuff too - more (at least imho) than in other popular languages. And then the whole ecosystem "drags you down" and gives PHP a bad rep -> but I don't think it's totally undeserved.
On a similar note, this actually compelled me to try Rust/something similar instead of just going straight back to Python (which I still love tbh).
The thing I hate about php is the inconsistency and unpredictability for new-to-php developers.
camelCase? snake_case? nocase? Who knows what the global function will be.
And who knows what order the arguments should go in. Sometimes the array is first, sometimes not (in array iterating functions like map).
The thing that got my goat the most however was that referencing an undefined variable merely caused a warning, but referencing an undefined key in an array borked it.
And what's with arrays and maps being the same thing?!
FYI when you start a PHP project you need to change your dev machine php.ini to be super strict, so all warrnings should just error out.
The inconsistency seems to have it's logic and at that time was consistent and made sense, you need a good IDE to help with this. Using PHPStorm and then using PHPDoc to define your functions parameters and return type is a joy, the IDE will catch your type mistakes, show you where you missed to catch an exception and it will code complete stuff.
It never made sense. The original hash bucketing mechanism for the function lookup in PHP was the length of the name of the function, so each new function was named a specific length to ensure the function list was evenly distributed across the hash table.
Well, there were other factors in play there. htmlspecialchars was a
very early function. Back when PHP had less than 100 functions and the
function hashing mechanism was strlen(). In order to get a nice hash
distribution of function names across the various function name lengths
names were picked specifically to make them fit into a specific length
bucket. This was circa late 1994 when PHP was a tool just for my own
personal use and I wasn't too worried about not being able to remember
the few function names.
Thanks for the tips! I suspect PHPStorm/Doc may be the only one that flies for the legacy codebase I sometimes get involved with - turning warnings into errors would be suicidal...
You don't turn warnings into error on production but it will help to have them enabled on your local machine, otherwise errors are ignored and you would waste your time debugging weird issues. You can do this per file too using the "ini_set" https://www.php.net/manual/en/function.ini-set.php
Many of the features highlighted in that article as "new" are from PHP 5.x, so it reads more like a list written by someone who has been out of touch with PHP development for a number of years.
Did you actually read the article or just the headings? Any features that pre-date 7.x are discussed as being 5.x features and, where applicable, the author expands on how it's been further refined / improved upon in 7.x releases
Yes I read it, why accuse me of not doing so? The main block of sample code is highlighting OOP features in PHP, but PHP has had most of those features since 5.3, e.g. namespaces, so my point still stands. Those features are not part of "PHP showing its maturity in release 7.4", but have been around since at least 2009, so why lead with that example?
When objects were first introduced in PHP 4, the implementation was essentially an array with function references and was horribly problematic. The fundamental problems of that implementation were thankfully addressed with the release of PHP 5, featuring an entirely rethought object implementation. In the versions that have come since, up through version the current 7.4 releases, numerous interesting language features for object-oriented programming (OOP) have emerged.
I suspect you're narrowing the scope of what this article was intended to cover. It is not just a look at PHP 7.4; it's just using the recent PHP release as an excuse for a look back at the history of the language:
With PHP 7.4.5 released in April, it's worthwhile to take a look at modern PHP, how it has evolved to address the criticisms of the past, and what lies ahead in its future.
I accept it mentions that in the content, I guess its the title I find misleading. You can see on this very HN thread, lots of confused replies are falsely equating those features as new developments.
My simple point is that PHP has been "mature", in OOP terms anyway, for at least 10 years now, so the original author tying that milestone to PHP 7.4 seems weird and outdated to me.
This meme of people on HN judging articles entirely on their title really needs to die.
> My simple point is that PHP has been "mature", in OOP terms anyway, for at least 10 years now
You keep saying that and I keep replying that nobody was ever arguing otherwise.
> so the original author tying that milestone to PHP 7.4 seems weird and outdated to me.
Again, they wasn't. You just assumed they did; presumably because you just read the title and the pre block and skipped over all the rest of the content.
Even with PHP7, PHP still feels like it is playing catch up. There is nothing new or revolutionary in PHP7, just adopting features present in other major languages. Adopting as other newer languages like Go and Rust seems to be moving beyond those features. A catch up into a world that's on its way out, if one will feel so blunt.
PHP's raison d'être remains its ease of getting an instance running on a webserver. But with fewer people self-hosting these days, that has become less an advantage. And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.
Pascal, COBOL, Oracle DB and PHP today seems like technologies that only stick around because they are legacies being maintained, not because people start new grand projects with them. Would Wordpress have chosen PHP if they started today?
Most of the time you do not chose a language or ecosystem because it has some cool syntax or some new feature. As an example if you need to do X you look at what solves X the best, if I can do X by installing say ffmpeg and write a bash script I will do that and not cry that bash does not have some cool feature.
I think languages like PHP, Java, C++ appeal for people that solve hard problem where the fact that you have a giant ecosystem of existing libraries and a large number of existing developers compensates the fact that the language is not "cool" or is missing some feature that you probably don't need anyway or workaround it with a library.
X sometimes stands for problems above technical problem, such as:
- Existing team is comfortable with using PHP
- Existing project is tightly coupled PHP monolith
- Existing project cannot be migrated to other language fast enough if needed
All are valid and justifiable reasons. Learning new language is not the easiest and we should think of the people.
I must emphasis though, all party must not freeze in time. They should learn to adapt. PHP is getting smaller. The decline is slow enough to let people migrate or jump ship but fast enough that it is recognizable.
Demands are growing for languages and environments which provide more than PHP, simplest examples would be granular websocket connection control, explicit process control, whitelist-by-default security, rise of cloud and edge computing, and of course, trends, "cool new stuffs" which is not always good for everybody, but always exciting especially for the naives.
There might be a day Java is getting replaced due its huge memory usage or its tendency to be verbose and hard to read. Golang is a contender for the memory usage side of the spectrum, NodeJS is the contender for the ease of use side of the spectrum.
There might be a day C++ is getting replaced due to its "harder to write secure code". C++20 is quite cool, but there's a new cool kid Rust where you most probably won't write bad code, can be actually faster than C++ / C in some cases, and can run on browsers.
May all programmers of old languages survive and thrive and in the new world.
Sure, but sometimes X is something like you have a video and you want to use the GPU to analyze it and the best library for that is in C and there are great python bindings. So a professional developer would use C or Python and not waste his client time by trying to create it's own unmaintainable CoolLang bindings (where this dev is just now learning CoolLang and there are not that many people that know CoolLang).
Even for new projects, say you have a desktop app and you want to let the users submit some data and save it on your server(like feedback or crash reports), you can do this on your server with 1 PHP file and a few lines of code, no dependencies on 300 packages.
You installed a framework Spring for a simple feature to grab some text from a POST request and dump it into a database.
Since in general you don't have thousands of users sending feedback at the same time I don't need a framework and if you know how to correctly create SQL statements you don't need a framework for SQL. There is nothing to log, if the db call fails you can put some text in a log file or do a curl to a different url to notify you.
It will also be probably faster then a Java framework since you don't have a function call stack 30 levels deep (not a Java issue , all magic frameworks including PHP one have such giant call stacks)
It depends on the customer, will they give you a server dedicated for your Java framework so you can handle at maximum 5 POST request per day or will day give you access to the existing website they have for the company, that already has PHP,mysql installed. Honestly you are not doing the fair thing for the customer if you ask for a new server because you want to use your prefered tool and not the best thing for this job.
Btw my scenario was about sending feedback ro stack traces, this are just text, no giant file uploads and nothing insecure about it.
Yes, and all three of them has very good backwards combability, one of the most underestimated features in a language for developers but one of the most important ones for building a stable business.
I recently upgraded a huge legacy codebase from PHP 5.2 (released 2006) to PHP 7.4 (released 2019) with relatively few changes, mostly changing the use of deprecated functions & misuse of variable references.
I remember reading about Ghost.org team members saying that if they had chosen PHP instead of Node.js when they got started, they'd be much further along in their roadmap [0].
PHP has a reliable ecosystem of 3rd libraries with LTS releases. I am not aware of something like Symfony [1] for Rust or Go.
Another big bonus for PHP to me is: there are plenty of people who are comfortable with it. Most things aren't genius-scientist-required kind of things where you lock some genius in a room for eighteen months and they revolutionize the industry. Most things are pretty average and you just need somebody with a good understanding of the problem and experience to do them. You'll want plenty of those people to get things done, and using a very common tool helps with having a large pool of people you can call upon.
Generally lower quality talent. That's half the reason PHP got its abysmal reputation. Brilliant programmers using PHP must be annoyed that they're thusly tarnished. I suppose that's not so different from JS. To the flames with both of them, though, I find them genuinely depressing languages to work with.
Which is totally fine btw. Most work isn't "we're engineering a new motor for a F1 race car", most work is "this car's motor is broken, replace it". You don't need a CS degree and brilliance to write code that deals with databases and APIs, which is the super majority of code.
You need smart people that spend a lot of time on difficult problems to create strategies that are easy to follow and tooling that is easy to use. And then you just need a lot of people using those tools and applying those strategies to real world problems.
What good is it if you have something that allows those that fully grasp it to write things ten times as fast, but you only have 10 people that can actually do that? I'd much rather pick something where I have ten million people that can use it, the output is just so much higher, and you don't get single points of failure because the one guy in your city that knows that language and does freelance work has decided to move on to a different language.
Our abstractions become the basis of our imagination - do we want developers to think and experience joy? Do we want their minds to spark and innovate and solve and embrace the full power of computing? Can anything compare with the illuminating glow of a powerful abstraction that reveals a new technique - perhaps not 'world changing' - that improves our software and our programmatic structures?
I guess we don't, actually. Oh well. :').
You make a perfectly reasonable business point.
And business is, imho, not just "for profit", but society in general. I feel about it similar as I feel about wood working mastery. Creating incredible joints with extreme attention to detail and a lot of experience fascinates me. But to build furniture for more than one person a year, I'd prefer nails, power tools and a bunch of people that are experienced enough not to nail parts of their body to the wood.
If we want to provide something to the masses, we'll have to provide something that can be used by the masses, not just by a highly trained elite. PHP is mass production development. It's not necessarily elegant (though you can do a lot in it, it doesn't have to be as messy as WP is), but it gets the job done AND it empowers large groups by being easy to learn and not requiring advanced understanding before you can actually achieve something with it.
I do still believe that we want experts that do the kind of work you're describing though. But I believe they shouldn't distance themselves from the ordinary people, but instead find their elegant solutions and then give them a handle so that the uninitiated can use them. Tooling is leverage, individually but even more so collectively. Imho, if you're a brilliant computer scientist and you work on "normal" real world problems, you're wasting your talent. Even if you find the greatest thing that runs 100 times as fast as the previous one, you've sped up one thing out of a million. Instead, build something that'll enable normal people to speed up their projects by factor two, your impact will be immeasurable.
PHP does a terrible job of weeding out the terrible hack programmers. For some reason, people have no problem going into a PHP codebase and monkeying around with it, where something like Rails or Java will at least intimidate them and make them think twice.
This.
I was using TypeScript for anything that looked like I'll be the sole maintainer but for something that could last for 10+ years, I started it out as PHP as I may not be the only maintainer one day and can't ask the client to look for more specialized talents for no good reason.
Well yeah, if you would pick one technology that even PHP would compare favourably too, it would be Node... my thoughts on Node were always: just because Google built V8, which makes it possible to run JS fast enough to use it in the backend, doesn't mean that you have to do it.
Regarding frameworks: of course PHP has an advantage there, because it's a more mature ecosystem. But frameworks written in PHP like Symfony or Laravel tend to forget that they are based on a scripting language (which years of optimization have made very fast for a scripting language, but still), so using their features extensively will slow down your application...
> PHP's raison d'être remains its ease of getting an instance running on a webserver. But with fewer people self-hosting these days, that has become less an advantage. And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.
And if you are doing something moderately complex/serious/modern you probably need/want composer anyway - because uploading all of the million files via FTP is cumberstone (let's not even get into the versioning/modern deployment practices). Then you are at shell already and not that far away from other language deployments.
I think that's kind of part of the point though -- PHP provides a gentle slope from "single HTML file" to "big project".
You can start with a plain HTML page and go "Hey, I want to do X" and just throw some code in the middle of the page. When you decide you need a database, MySQL is right there and easy to use. When you decide you need some libraries, you can just download and `include()` them. All of this can just be FTP'd up to some server somewhere.
As this grows bigger, there are tools like composer and frameworks/libraries like Laravel and Symfony. You can still FTP those, but once that gets painful you can start to learn the bit of *nix skills it takes to start managing this different ways.
At no point have you had to worry about nginx/apache/supervisor/anything else. But whenever you're ready, that's all there too.
This is basically the path at least one guy I know took to going from working in a totally non-technical industry to building a massive (almost 2 million lines at this point) application that allowed people in the industry to stop working with a bunch of exploitative big name companies and instead self-manage and earn more money. And now that product makes a bunch of money for him.
And then there's the scales that places like Twitter/Facebook/etc took it.
I think the big thing that always gets missed here is PHP's... egalitarian nature. Yes, at some point it just ends up a in some ways less-good version of other things. But it provides an incredible opportunity for people who aren't engineers to realize their ideas without immediately becoming overwhelmed with needing to learn a huge amount of foundational knowledge before they can lay down their first line of useful code, and seeing that through to crazy places.
PHP still remains incredibly accessible, the documentation and legacy of problem solving means you can find help for any problem you'll encounter and the lack of complicated tooling makes it easy to focus on the problems that matter.
There is also a maturity in the tooling and community for PHP that doesn't exist in newer, better languages. There's no shortage of developers, and moreso nowadays there's also a huge body of best practices that embody good software engineering.
If what you want is a monolithic standalone web application paired with SQL, I'd argue PHP is a pragmatic choice from a business point of view. I would also argue that a monolithic web application is all the vast majority of companies need.
The biggest source of bad software and failing to meet business requirements in my experience has been following the industry's whim and rebuilding every time the wind blows in a new tech stack. If you're a PHP shop delivering web applications, you will be able to do that successfully for years to come. Picking the "right" language is a wild goose chase, just be good at the language you choose and you'll be able to deliver good software reliably.
> But with fewer people self-hosting these days, that has become less an advantage.
I don't think fewer people self-host. There are some going to big clouds, there are some using integrated offerings like squarespace, but there are still many hosting their website with a regular hoster. And probably in total many more than in the past.
> And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.
Did they? How?
With PHP, all the users has to do is to fetch the project files and upload them with FTP to the directory the hoster told them to. No other environment matches that - and no other environment is supported by those hosters. If you want to run something else - like Ruby, which I prefer to use, or something that creates a binary for you - you are looking at a completely different type of hosting. Digitalocean, Heroku - and that's not as easy, if the application is not provided as a one-click-install.
I'll concede that PHP focused hosting solutions such as your traditional shared webpage hosting environment is better at hosting PHP than any other language, and sure there are less services out there that lets you deploy code "as easy as PHP".
I had to check and I'm paying about 4$ a month for a traditional PHP server host vs 5$ for a VPS which I can run whatever I want on.
And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell. Then only thing that makes this harder is having to kill the server and restart on deployment. I dont find that to be that much harder.
It's not really a question of money, the VPS where you can do what you want can even be cheaper.
> And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell.
I mean, it's not like I'm not doing that for myself. Even my PHP blog is not with a traditional hoster. But there are many things that can go wrong there - for the ruby example starting with the ruby versions, additional system dependencies. And then you need something to make the app restart after a reboot (supervisor is thankfully excellent), and probably a nginx in front of the webapp, and letsencrypt, and does your VPS take care of backups? Each task not impossible, but in total vastly more complex. Some users can handle that, many don't.
I just did some freelance work on a wordpress site (and I'm involved with a different PHP blog engine, serendipity), and it's so nice when the setup that those PHP projects present you with is clear and straightforward, and on top of that everything that might be complicated even a mediocre hoster had years to solve now.
memory_limit is the upper bound you "allow" PHP to allocate. You can allocate more than the available RAM, and have your OS swap or PHP crash.
Pretty much every shared host I had to work with (I've been freelancing for a few years), have been terrible, except for two platforms, both of them were expensive and aimed at particular PHP software.
> I don't think fewer people self-host. There are some going to big clouds, there are some using integrated offerings like squarespace, but there are still many hosting their website with a regular hoster. And probably in total many more than in the past.
From my experience, the share of people who can only deploy PHP is steadily shrinking. PHP remains the default, and popular, but easily deploying other languages is becoming more feasible, and we're shipping docker containers with Python/Go/Node/whatever code a lot more often these days.
> With PHP, all the users has to do is to fetch the project files and upload them with FTP to the directory the hoster told them to
Let's not idealize things. For moderately complex apps, even back in the days, this falls pretty fast: missing PHP modules in default distro installation, PECL/Pear extensions, hosters messing with the php.ini in bad ways, etc. And now the dependency management and deployement systems pushing you to access a shell on your server...
The only issue of that I still encounter is hosters misconfiguring the php.ini, rarely.
There is no shell accessible on these servers, it's on the project to include all dependencies. Composer in this world is strictly not for users, but only for developers. That's a good thing.
Oh how I hated the fact that php.ini could change so much of the PHP behaviour... can't say I miss those days.
Also, I don't know about now because I left this ecosystem long ago, but it was very common for apps to bundle their own custom installer scripts (access a webpage, fill a form and so on). Certainly useful for the users but it was never standard and required a lot of work for the developers (and came with their own requirements and bugs).
But I like some of the recent additions to the language. At least the PHP Team keeps up with the competition.
This is changing now. There are no new php.ini changes that would affect how the parser or VM works. The lessons from things like safe_mode and register_globals are learned so well.
Rust and Go for writing a cusomizable CMS like Wordpress, really? Also PHP playing catch up and not breaking up my stuff with every point release is just fine. It means stability, maturity. Even Node.js has LTS releases.
Dart is more suited for this type of thing if one wants a new and shiny statically typed language with great performance.
Wait, Go hasn’t had any revolutionary change since it arrived 10 years ago. It is still basically the same language/package. I’m not saying that is bad, but why does a language need to be constantly revolutionary if it solves what it sets out to solve well?
Catch up to other languages? You can easily argue the opposite, that other languages has finally catched up to PHP, ease of deployment, ease of horizontal scaling, fast reload/build time, built in string templating, simplified variable syntax (auto, var), etc
I can go on, but if you already framed the question to the disadvantage of one party you will not really get a fair answer.
Because it fundamentally destroys the current agenda within software development, that tools should be created for developer satisfaction, not customer satisfaction.
Am I the only one scratching their head at this argument in 2020? 15 years ago when shared hosting was more common I would buy it, but I just don't find myself wasting time on figuring deployments out in other languages/frameworks. By far the biggest time sink in that area is setting up continuous integration and monitoring/alerting systems, and those problems are exactly the same regardless of language.
Other languages haven't caught up on PHP about ease of deployment.
If you need a fast hot reload, it isn't trivial in other languages. PHP does it with no effort. Save and refresh runs the updated code instantly, not to mention asking people to run PHP app is far easier as every general hosting provider has PHP installed.
On the other hand, language structure is quite behind others but can't blame when it had been around since 20+ years ago.
The new type hinting is so basic, not sure how realistically useful it is compared to typing in TypeScript.
Thats hot patching, not reloading as I've come to know it in the web development world.
Hot reloading works the same for all languages I know, which is a hardcoded port pushing notifications to clients that they should reload the browser.
The client is mostly a js library or a browser plugins. Either works.
I know it's also used differently in some contexts, but they wouldn't apply here as far as I can tell. There aren't any long running processes that need to reload the code after all. It's only read when is actually executed. Which is never unless you use the hot reloading I was talking about earlier... Or trigger it manually, making it a regular reload.
You're entirely missing the point by focusing on why someone may or may not have used the wrong words - with an application written in many other languages, you have to do something special to be able to update some server-side code and have that new code be run when you next hit the server.
If pointing out that he's using the wrong technical term is 'missing the point', I'm not sure there was one to begin with.
most examples of why php is so easy to deploy show it with hello world examples you'd never encounter in the wild.
yes, you can edit the php code directly on the server that is executing it. just like with python, nodejs, ruby ... and even java if you're not worrying about scalability.
there is really very little difference if you ignore the fact that it gets hard with the codesize and the environment in which the service is deployed in. the language is almost always the smallest challenge.
and fwiw, i'm definitely not "against" php in any way. i think ssr script languages are wonderful for easy development - especially if you combine them with something like intercoolerJS for interactivity. extremely easy to get started and you're even able to make ssr-"components" by just fetching each segment separately, which isn't really any overhead with HTTP2 nowadays.
I can, on my local server, change the code, hit it again, and have my changes reflected in what happens. Doing that with Python, Node.JS, Ruby, or Java requires extra configuration. That's the point.
Rewriting a bunch of text files isn't atomic, so you need to take a planned outage or atomically rename the source dir so you don't serve 5xx errors from parsing half-written source. At that point you might as well have a deploy process, which can be as simple as "rsync && mv" into each host.
Not sure if you even understand what you're talking about.
As for node.js, I set up pm2 to watch for file changes and restart ts-node process and this takes a few seconds, which is slower than I can hit alt-tab back to the browser, which is annoying to see 'Bad Gateway' error page quite often, not to mention embarrassing to explain and help set it up to someone new to other languages than PHP.
PHP is instant and I'd like to know if there's a solution in node.js that can do the same.
Hot reload is trivial in Common Lisp, and only marginally less so in Elixir. Turns out it's just not enough of a differentiator to actually tip the scales.
Go itself is also not a revolutionary language, actually the fact that it isn't revolutionary is one of it's "raisons d'etre". Go is mixing up various popular concepts into a reasonably compact package.
A question I ask myself often is what niche does a language fill, and it seems a little like the traditional niche of PHP has been eroded away in the last decade. Many of the things that gave PHP an edge (ease of deployment, templating within your HTML files, direct SQL queries) are no longer considered the correct approach.
At the same time PHP is trying to reinvent itself by adopting a strong type system and experimenting with async and long running processes. But these are niches that are already filled better by other languages (Java/C#, Node, Go), so it feels like they are fighting an uphill battle. But maybe it is that tenacity of the language to stay relevant that makes it attractive to a younger generation of developers and decision makers.
Greenfield projects are much less important than brownfield projects. After all, a project is new only for the first few months of its existence. After that, it all becomes legacy code :-)
And techs with mainstream adoption in the post DotCom bust era, especially if they're free and Open Source, will be around for decades. A newbie PHP programmer in 2020 will most likely be able to retire in 2065 as a veteran PHP programmer, if he/she so wishes.
> Even with PHP7, PHP still feels like it is playing catch up. There is nothing new or revolutionary in PHP7, just adopting features present in other major languages.
Of the first programming languages that cater to novices to some degree (which is important to project health, because excessive gatekeeping is toxic), PHP was the first to make Curve25519 and Argon2id widely available (through the sodium extension). (7.2)
Even with the "just use FFI" mindset of other languages, the experience is janky at best.
For example: Before sodium-plus [1] came along (which was something I created, so I'm removing it from the table for my criticism of the JS crypto ecosystem), JavaScript required knowing which of the following packages to install: [2] [3] [4]
There was no guidance available anywhere. Some of these APIs were suitable for browsers, others for mobile devices, and still others for server-side JavaScript. And their APIs were subtly incompatible with each other.
Java's in a similar situation [5] today.
> Java (Java Native Access): libsodium-jna
> Java (Android): Lazysodium for Android
> Java (Android): Libstodium
> Java (Android): Robosodium
> Java (Android): libsodium-JNI
> Java: Apache Tuweni (crypto module)
> Java: Lazysodium for Java
> Java: jsodium
> Java: Kalium
Yikes.
With PHP7, you just had to update to the latest version (and make sure your OS package vendor isn't huffing or eating glue, which was rare but still existent) and you had it.
There are probably still languages and runtimes today that make using modern cryptography (Ed25519, X25519, etc.) a miserable experience.
Miserable experiences moving to modern cryptography keep peoples' projects trapped in an early 2000's RSA-PKCS#1v1.5 + AES-CBC hellscape reminiscent of SSLv3 but somehow worse.
Thus, I would argue that what PHP did with libsodium counts as revolutionary.
Your move, $languagesThatHackerNewsFindSexierThanPHP
Do the two overalp in their niches at all? You'd write a web server in Rust. But is there much effort put into Rust web frameworks?
It's just a weird comparison. PHP is competitive with JS, Python, Ruby and even Java. But Rust? That's C/C++/D territory. And Go is somewhere in between.
There is lots of effort by Rust devs, even if the libraries are not as mature or easy. I don't believe you meant to be disrespectful here. I think better a better words could be any of manpower, maturity, or time.
For web backend, being able to ship a single binary, such as what Rust and Go can provide, is really nice. I don't see PHP as a more compelling solution than either of those languages.
Scripting and command line automation is executed better by Python and Ruby, which excel for writing Unix scripts and tools.
I do not see what the use case for PHP is in 2020.
PHP has one of the most abhorrent language syntax designs this side of Perl, and the standard library is wildly inconsistent.
I really wish PHP would just die. Continuing to drag it along like the dead carcass it is wastes so much human effort. The longer it exists, the longer we have to support it.
At the same time, being able to install new or change existing software just by uploading some files to a cheap webhost is not to be dismissed as easily.
Most webhosts provide some kind of support for containers don’t they? Perhaps I’m completely missing the point here? I’ll readily admit that Im young enough to have used docker to deploy apps nearly everywhere I worked. Is php useful for ultra low cost websites? Is it low maintenance? Is that the appeal? Genuine question.
I don't think I even disagree with you here, but to use arguments for version control as your arguments for docker images and static binaries seems odd.
All three of the issues you raise would be solved by involving a VCS somewhere in your FTP deployment.
Incidentally, claiming that either option is "no more difficult" than FTP upload or even using VCS is either disingenuous or at least a little blinkered. FTP can work as simply as copying files between "folders", I've successfully taught my non-techy parents to use FTP. Setting up docker images or static binaries requires significantly more understanding of what's going on but of course provide speed, consistency and scalability benefits.
Many small businesses just want to get online, how does a container help them? Actually it doesn't.
Containers definitely has its place, but there hundred of thousands problems out there that needs to be solved for a low cost, otherwise it will never be solved, and a container will just increase that cost with little or no gain for the customer.
> Scripting and command line automation is executed better by Python and Ruby, which excel for writing Unix scripts and tools.
Python has a ridiculous time it needs to start up, it is not suited for any batch task that requires a lot of process creation.
> PHP has one of the most abhorrent language syntax designs this side of Perl and the standard library is wildly inconsistent.
At least it has a standard library that is both usable (in contrast to the JS ecosystem, remember left-pad?) and actually not that inconsistent if you have experience in developing C - most of what is described as "inconsistent" comes right from there.
And: the stdlib of PHP can easily be expanded upon by a rich variety of Composer libraries that can easily be deployed. Let's compare that to... Java, for example. Three popular dependency managers (and build tools): Ant, Maven, Gradle. Plus classpath worries if you're using Tomcat or other application servers which means you also have their libraries in the mix.
Changing code in production? In PHP it's as easy as changing the file using rsync and automatically all new incoming requests will use the new code, vs Java where you have to restart the server (which for large project means minutes of downtime).
Think of a simple landing page with a form to save data from a form and send out an email with confirmation.
In PHP you just need to add to your HTML page a few lines of PHP code and copy it using scp to any share server hosting that costs 4 dollars a year.
No "automation", no "cloud", no REST APIs, no WSGI/Gunicorn, etc. just plain Apache with mod_php enabled, which is available everywhere. I don't think anything can beat PHP productivity for such simple usecases.
Aren't there a zillion online services that provides that product out of the box, most likely for free, only requiring a browser and some monkey clicks around? -> No PHP, HTML or web server.
As someone who works with PHP reasonably often, I'd say you have a very limited view of what PHP is actually used for in 2020, if you think 3 hosted blog services will replace it.
The majority of PHP usages tend to be, frankly, unsophisticated Wordpress, WooCommerce, Magento, and Drupal sites that are hacked up to support e-commerce. These needs can now be met by a vast array of ecom and omnichannel platforms.
> being able to ship a single binary, such as what Rust and Go can provide, is really nice
Unless you're distributing your binary to 3rd parties, why?
If you really don't want to deploy changes to e.g. a single/small number of controller or template files as independent file changes, build your PHP app into a .phar archive, and deploy that.
I don't specifically think PHP, when run (IMO) the best way it can be, is "easier to deploy" but I also don't think it's harder either.
I'm going to ignore your other comments because they're personal opinions and while you express them as facts, I realise you probably mean them as statements of opinion.
But the last part, I just don't understand:
> I really wish PHP would just die. Continuing to drag it along like the dead carcass it is wastes so much human effort. The longer it exists, the longer we have to support it.
Who is the "we" in this statement? You clearly don't like it personally, so why does it affect you, at all? I'm not a huge fan of Java, but I don't go around claiming that it should "die" or that humanity is somehow worse off because it exists.
There's no such thing as a client-side PHP application, so it doesn't even compare to e.g. genuine concern over tech choices that are 'forced' upon users of a website (e.g. Flash, SilverLight, ActiveX, javacript bloat, etc). If the backend part of the system does what it needs to do, the language/framework/runtime it's written in/with is meaningless.
I very rarely write PHP and will probably never have to use these features, but I think that the combination of the FFI and preloading can be quite a powerful thing.
I've been using PHP for over 15 years and always liked it. There is no other webserver language that's so easy to use and so deployable while still being fast.
But for larger projects the available frameworks are just okayish. I think Symfony is closest to what a good framework should be. But every time I use it I wish it would be like .NET
Today .NET core is also available on Linux and very easy to deploy so I don't think I will ever start a big project in PHP again.
But for quick smaller and CMS[1] projects PHP is still my goto language.
What if you’re looking for a great way into .net web dev on Linux? I’ve been struggling to find a good guide that combines dev env, deployment and a good web framework. Any advice?
I have quite a bit of xp with Python (Django/flask) and less with php.
Most can be done via de command line but an editor like VisualStudioCode could be handy. Personally I use Jetbrain's Rider as IDE on Ubuntu.
Deploying can be done via the `dotnet publish` command. But tools like Teamcity can also be very useful. When you built a webapp it includes the Kestrel webserver. So it is just a matter of running the app and navigating to the port it listens to.
.NET core is a complete set of tools to create console apps, (web)APIs and webApps. This includes the .NET framework.
.net has proper debugging working compared to node.js, has great standard library, can develop 3d games, servers, mobile apps, web apps, machine learning ,desktop apps and even (some) embedded devices.
Great instrumentation and support with quality updates from MS and the community.
The IDE is superb and free (community edition at least), drag & drop desktop & mobile app development (if you wish).
I've worked with PHP for about 4 years (5.x - 7.0 days), .net for the next 6 years and node.js for the last 1 year, and every day i work with node.js i wish i could switch everything to .net because it's sooo much better & smoother experience, and everything just works together so well.
Honestly, as a PHP hater that got much more experience in .Net than PHP, it both were the only options, I would go with Laravel without any doubt.
C# is an inflexible language that just can not have a modern web framework on it. MS extended it with hard-coded functionality to closely emulate a framework and did an ok job on it, but it emulates a closed down, inflexible framework that is stuck in time. It's not a disaster, but it doesn't compare to the stuff that has kept evolving for the last decade.
I use php daily. Mostly Symfony/Laravel stuff. There are still some stuff it needs what other languages have. (Can't really right now remember all the stuff i stumble upon sometimes which gives me the feeling "damn if i could do this like i do it in rust/java/cpp/(w/e)")
Maybe the worst thing is the composer (it's slow.)
I have been coding in PHP for 15 years (not exclusively) and indeed many things had to improve.
Nevertheless, many other languages also had to. Just as an example, PHP had a much more mature vendor requirements system than Go and years before!
What I see many people tend to fail to observe is that a language is also good as the amount of value it can being to the business and in that PHP was and still is phenomenal.
Anyhow, I'm really happy to see how it has evolved.
I wrote my very first webapp in PHP when I was a teenager, and my first dozen paid apps shortly thereafter as a consultant. PHP was a lot worse then, but still has a lot of the same fundamental issues that it won’t ever be able to escape without becoming a different language.
I think it’s a good first tinkering language for people around that age: sort of like BASIC, but for the web.
I am glad PHP is still around; it is a very useful signal on the resume or CV of someone who uses it a lot.
It’s sort of like c# in that regard (exception granted for vertical-specific devs who work professionally to ship commercial apps with Unity), or Visual Basic before it.
Same goes for heavy Java outside of Google/Amazon backend, or outside of Android.
Most of these people are desktop Windows users by choice, too. It’s a very specific type of techie. Perhaps one day I should make an ishkur-style taxonomy. :D
I think this is also why almost all forum software is written in PHP.
Of course. Why change that for zero gain? Powershell does too.
Can you point to some research that scientifically proves that the use of dollar sign in variable names makes it harder to solve computer science problems?
1. Waste of time and mental cycles: forces the programmer to do the parser's job because the language designer was too lazy to build in the logic to recognize variables.
2. Carpal tunnel syndrome, especially on keyboards where "$" can only be reached via shift.
1. Personally I find it easier to read variable names prefixed with dollar signs, it differentiates variables from other symbols, which makes them very easy to find, especially now when many languages gives information overload by lots of type information etc. My eyes can scan code faster.
Whether you like or hate PHP, it has achieved something that no other language has done - made it easy to host a dynamic website or app on the server. Other languages may claim to be 'web-friendly' (e.g. Python, Ruby) but when it comes to ease of deployment, they are anything but 'web-friendly' or easy.
This is what programmer and blogger Jeff Atwood - who isn't a fan of PHP - has written about PHP:
"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option"
He wrote that in 2012. It's 2020 and I can't think of any other language that has caught up with PHP's ease of deployment. If you want to get your customers to self-install your software as painlessly as possible, what other language can match or exceed the ease of deployment of PHP?
>If you want to get your customers to self-install your software as painlessly as possible, what other language can match or exceed the ease of deployment of PHP?
Anything with containers. Docker was a real game-changer here.
>In our dashboard you will find pre-configured Open Source apps like WordPress, Plone and other. They are all based on the official docker images and can be deployed with just one click.
They had to write an installer ecosystem around installing docker images, whereas with PHP and most stock server configs you can SSH a file into a server and you're pretty much done.
Still if I want to write a simple web app in < 1 day, I would definitely use PHP.
In such a manual workflow ("you can SSH a file into a server"), you still have to setup at least URL rewriting in nginx for any PHP app using routing (which is basically everything using any PHP framework or micro-framework).
Plus if the deployed app has its own domain/subdomain, you need to set that up, set up TLS certs etc., so it is really no different in the end. You either configure nginx to proxy all requests for some domain to an index.php file, or you proxy them to a locally running container (where you also don't have to worry about versions of software installed on that server, clashes between different apps, etc.).
Commercial PHP webhosts also have an "installer" for automating all of this, provisioning databases, etc.
A lot of this can also be automated by various Kubernetes controllers (DNS configuration, TLS cert provisioning, databases, volumes, backups, monitoring etc.) if you already have a cluster. And for packaging installable apps, there is Helm and its charts (e.g. https://hub.helm.sh/charts/bitnami/ghost), you can also manage them from a GUI dashboard (https://kubeapps.com/) or even from a git repo (https://argoproj.github.io/argo-cd/) if you want to have a repeatable history of all changes to the environment, updates, etc.
Literally, just start `docker run` with a proper restart policy, set up a proxy_pass on nginx and you're good to go (unless the app requires external services, databases, etc., but you have the same problem with PHP).
Plus you don't have to worry about things like "do I have the correct PHP version for all my apps?" or "do I have the necessary PHP extensions installed in the system-global PHP?
>And surely you must be joking when comparing Kubernetes' complex configuration to anything else.
Setting up a Kubernetes cluster is indeed complex. Installing apps into an already configured cluster (e.g. ordered as a service from someone) is not (unless the app itself is complex of course).
I was comparing it to the automation tools that "traditional" webhosts have for installing and managing application deployment, replying to a comment above ("They had to write an installer ecosystem..."). If you just want to have one VPS with nginx on port 80/443 and run apps there, you don't need any of that stuff. The container images are the same either way.
For hosting companies, PHP has a unique benefit: A single installation which scales with the load. Most Python, .NET, Java, NodeJS, Docker, whatever require to run a seperate executable for each site permanently (producing a basic workload / memory consumption / security mgmt needs / ... ).
In that sense, PHP is like a early variant of Lambda ;) When there would be a universal, simple-install, simple-use, low-requirement version of Lambda (incl. Gateway etc) we would see a easier hosting market for all the languages beyond the public clouds.
PHP, Python and Ruby all feel to me like last-generation languages. IMO we should be building new frameworks on modern languages that support concurrency & static typing. The most promising new stack I've seen is Kotlin's KTOR framework. Thanks to the expressiveness of Kotlin it's not really any more verbose than something like PHP or Ruby but it's far more powerful and robust.
Nah. The JVM must go; we have Docker and the universal platform are Linux ELF binaries so the entire "bytecode" concept makes sense for the compiler (i.e. LLVM), but no longer at runtime. It's just bloat.
Kotlin native might eventually make the JVM superfluous but for now there are a lot of benefits to being on the JVM including great performance, a huge ecosystem of Java libraries, and very battle hardened monitoring and debugging tools.
Bytecode is simple enough to alter at load time. This gives you aspect-oriented programming and instrumentation of everything that statically linked binaries have never offered. And I don't think anything compares to the JVM's GC throughout yet; why roll your own if it's slow?
Considering the GP commenter started with an emphasis on concurrency, Elixir's concurrency features (thanks to the Erlang VM) are totally different than what Python can offer, namely isolated processes (scheduled in the VM so like green threads) where you can write blocking or CPU intensive code without worrying about blocking the other processes and where GC is per-process. With Python you (AFAIK) run into the GIL when threading or you fork OS processes that are heavyweight so you can't do that for every request or you'll fall down. Or you have to write async code which can still only saturate one core.
Not saying Elixir is the answer to everything but that's where it differs in the concurrency sector. It doesn't have static typing though, which is a requirement for some.
What do you mean by concurrency here? JS like async or Java/C# like threads? And why would concurrency help in problems where PHP is involved, in the problems I solve with PHP I don't think I ever needed async. For unning more things in parallel like processing 1000 RSS feeds you can spawn 10 scripts that run in parallel and if one crashes the others still continue to work(I had experienced crashes with some RSS XML files crashing the built-in XML parser).
Just curious what problem are you trying to solve, I never had the need for different threads to communicate in PHP, most of the time in my work a user makes a request, and a PHp scripts does something like update the database or does some searching/working and returns a result.
What if that request was a document upload and your system is calling out some external api or processing for long enough such that you’d rather return now and update later when the job finishes. Maybe through Ajax or a redirect.
The shenanigans that WP plugin devs go through to get around the lack of a queue is ridiculous (chunk the file and keep reloading the page until we’ve processed all the chunks or have an Ajax endpoint that processes a chunk at a time...) and the when I asked a marketing friend of mine who works with Wordpress he said that redis is an “advanced requirement” and I should keep things simple.
In Django land I’ve always set up queues even just to send emails because it keeps things snappy.
For that kind of problem we create a database table. then you schedule there your work tasks and background scripts will fetch jobs from the database and run them. This also works great if the third party is busy or fails, the background jobs are set to attempt a few times before giving up.
What solution would you prefer for this kind of jobs? launching a new thread directly? or have a worker project always running and send to it the job directly?
.... As you identified at the end, the correct solution for this problem is a job queue. There is nothing about PHP that prevents the use of a job queue - in fact the shared-nothing, process-per-request model almost encourages the developer to offload as much work as possible to a job queue..
Using Wordpress (or it's plugins) as any kind of reference for what PHP is capable of, is like using McDonalds as the basis for a cook book.
If putting a job/event into a queue, or writing a log entry is taking so long that you need a separate thread just to enqueue/log that entry, something is dreadfully wrong with your application.
Ironically, the root cause that made me think of that example was AWS.
The example was where each SQS call (there could be as many as five) was taking between 50ms-200ms, and logging took another 75ms. The rest of the request processing time was approx 50ms.
There's a bunch of other architecture options we could have looked at, but due to the share-nothing nature of PHP, they weren't an option.
I do. However, the process would have stuck around until it finished. It wouldn't have changed our overall RPS at all.
Arguably the same problem would exist in other languages, but at least there we would have had the option of using threads, and we could have executed multiple calls to SQS in parallel. Probably not something I'd want to do all the time, but it would be nice to have had that option in this case.
Anything that will block the server. Fetching data from an external API, doing some kind of expensive computation, sending an email etc. You can either handling this Node style with blocking i/o, throw the work onto a background queue like Sidekiq, or use a language with first-class concurrency support like Golang or Kotlin. To me Kotlin feels like a far nicer and more scalable language than Golang.
I like this about PHP, you don't have a callback hell. I don't disagree with you just sharing my experience here, we might work on different kind of problems.
I work on highly concurrent backends that handle 100k requests per second across a cluster, and PHP will never work in those situations. Any time you have to orchestrate multiple data store or service calls in the background, you don't want to block.
Callbacks are not how you do non-blocking IO. You typically have multiple threads and use constructs like futures or promises to make them easy to manage.
PHP bakes you into a very simple request flow. There's so much more you can build if you get out of that manner of thinking.
Yes, I never disagreed with that, best tool for the job. But your problem is not the usual stuff that web projects are about.
Edit: FYI I have experience with other languages too, so if at my work I use PHP does not imply that I am some inexperienced person that has no idea how other languages work. I do not have experience with your domain of high concurrency, low latency stuff but I worked with threads, and thread pools and multi-processes programs(it happened that some thread would segfault and bring the app down so we had to use background processes instead of threads) .
Alas, I feel the same way. After much thought this weekend, I concluded that it was time to move on from PHP. I decided against the any other scripted language (Ruby, Python), as it felt like more of the same.
Requirements were strict typing, functional programming support, built-in concurrency, decent library support, and real support for both native and Javascript. It pretty much came down to Kotlin or Rust.
I really want to like Rust more, but the library support, and the jobs in my area just aren't there (yet?).
No garbage collection, doesn't compile to Javascript[0] and everything on Android is moving to Kotlin anyway.
Just to be clear, my reasons stated above is why I'm moving to Kotlin. I make no claim that other people should or would want the same things. I've realised that I like languages with explicit strict typing, and that allow for a greater level of expressiveness at the cost of a higher intrinsic complexity and the comprehension that requires.
Kotlin is really a fantastic language even without IntelliJ but with IntelliJ it makes these older languages feel archaic. Once you've had this level of explicit typing & null checking, code navigation, and refactoring that really works its very hard to go back.
Kotlin also feels like a pretty safe bet since both Google & Jetbrains are backing it.
You can defined what types/interfaces methods needs to return, what types/interfaces variables must have, what types/interfaces the method arguments needs to have.
It also supports class inheritance, abstract classes, interface classes, class traits, etc.
It does, and using PHP in strict mode, in combination with tools like phpstan is what led me to looking for a language that is even better in that regard.
If PHP hadn't made advances in it's type system with the 7.x series, I probably would not have stuck with it this long.
However, while PHP the language supports strict typing, it does it at run time (inherently a limitation of scripted languages, I know), rather than compile time.
One of the main benefits of PHP for web serving, is the "shared nothing" architecture.
By operating as a non-threaded application, entire categories of bugs and security holes are avoided.
Are there situations where threads could genuinely help? Sure, there is always an exception to any rule, but for the vast majority of projects where PHP is used, I don't believe threading would achieve much in terms of performance gains.
There are very few places where PHP cannot do strict comparisons.
The first example in that article even highlights that `in_array` has a `$strict` parameter.
I'd bet a months salary it's easier to teach developers to use strict comparisons (either through arguments to be passed, or strict operators to be used) than it is to teach developers how to avoid thread-safety bugs.
Though, it might take longer to train them to spot every place where they could/should be using some stricter version of the defaults. That's the problem with opt-in safety.
On the other hand, there are languages that make thread-safety bugs much less likely. Some day those ecosystems will catch up to the languages that have been around "forever" and we'll get our cake and eat it, too.
There really aren't that many places to remember, and there is copious amounts of developer tooling available to identify, and in some cases even fix the issues automatically.
I don't recall ever seeing any kind of dev tooling that can just automatically fix thread safety issues.
I'm there with you about Kotlin. I started with PHP last "last generation" and was pretty bored with it. Kotlin was a breath of fresh air. Also, if you like some similar to Laravel/Symfony for Kotlin, give Alpas a try: https://alpas.dev/
If it's modern PHP specifically, are you saying that both languages are adding a bunch of the same things? That doesn't really sound like one language turning into the other.
If you're starting with WebDev in 2020, choose Go or Rust. Concurrency & safety + simple deployable static ELF binaries > weak typing and legacy bloat.
Why would I use Rust for Web dev or anything else that is not some low level system programming? I mean if you want to write some toy project and want to learn sure, but for a serious project I would chose something that uses a higher level programming language, that has a big and stable standard library and that also has a big community made , well tested libraries to work with.
Depicts language feature, PHP ecosystem is dying. For me, an example is latest MediaWiki syntax highlight extension dropped GeSHi (PHP) which is not updated anymore, to pygments (Python) using a sub process.
I realized I have to drop MediaWiki because my host didn't expose PHP proc_open() feature.
I don't even know where to start. A natively written syntax highlighter can be considered as an important brick in an ecosystem (GeSHi was used everywhere few years ago), but it looks like no-one is working on it anymore so MediaWiki did an strong technological move to use Python via a sub process.
This kind of move (dropping a existing natively written tool for a tool from another language) shows how bad the ecosystem situation is.
Would it be feasible to write a PHP equivalent to emscripten, so that one could export software compiled from any frontend language (including, e.g. the WASM representation) as a php object that can be run directly by mod_php?
It should be possible, but I'm not sure if PHP has the kind of community drive behind it to make it a realistic option.
Or a necessary one – emscripten's main use case is "everyone has a browser", but there's very few PHP hosting offerings where you can't shell out and just run straight native code (in your own little isolated sandbox).
This is a side effect of open source. GeSHi, and many others, suddenly stop getting maintained, and more often than not, project ownership doesn't get passed down.
This problem isn't unique to PHP. I have seen this is many projects across all kinds of different languages and tooling.
Unfortunately, if there's no good alternative written in PHP, MediaWiki could have either reimplement it from scratch. In my opinion, GeSHi isn't the best implementation of a syntax highlighter, so I get their reason to not adopt it. Writing a syntax highlighter from scratch isn't a trivial task either.
None of this says that the PHP ecosystem is dying though. MediaWiki isn't going to suddenly move away from PHP. Nor will many, many of the other big name projects that are still built on top PHP, and as long as there are big name projects, PHP ecosystem will continue to evolve.
I will say choosing a Python sub-process at the sacrifice of portability (considering how many people simply run this on a PHP webhoster) is quite surprising.
That's not a side effect of open source: it's a side effect of any dependency. If you were using foxpro, any google service, apis from companies bought by Apple, etc then the dependencies stop being maintained or vanish altogether.
I've been using PHP professionally since ~1999. I remember ripping the Perl fanboys in the early 2000's until the foundations of PHP started to crumble with what are issues that stick in peoples minds today; so I do wonder if we brought it on ourselves sometimes. But PHP moved on carefully to preserve backwards compatibility. I still have a SaaS first developed back in 2005 on the latest version of PHP that's happily ticking over with the minimal of maintenance required - the code base is horrendous but that's because a developer I had with me at the time made a massive case for "software design patterns" that he crowbarred into every nook and cranny regardless of if it was required or not.
I've done things with PHP that would give people nightmares. It's a far more capable language [1/2] than most realise and with version 8 bringing us JIT things just keep getting better. Would I use PHP if I was starting out today? Unlikely, but I know PHP inside out and can wield it to my wicked ends with ease so won't be dropping it anytime soon.
> Would I use PHP if I was starting out today? Unlikely, but I know PHP inside out and can wield it to my wicked ends with ease so won't be dropping it anytime soon.
So just out of curiosity, if you hypothetically did start learning web development today from scratch, what would you spend time learning instead of PHP?
When I started I struggled with browser inconsistencies. Over the years Javascript has come a long way and whilst I'm not 100% sold on node.js, I like the idea of using the same language across front and backend so likely would have gone down that road.
If after 20 years of PHP experience you arrived at "not 100% sold on node.js" as your most likely alternative, that to me more than anything else signals a strong, ongoing vote for PHP :)
There is plenty to dislike about javascript but modern versions are really quite nice. We're about to ship our first node backend having been largely a django shop up until now. There is loads to miss about django and python, but it is so nice to not have the context switching between languages and paradigms. It may not be for everyone, but if you're doing modern web, I think the starting point has become javascript everywhere, and then moving away from that on a use-case basis.
Piggybacking to say that if you're just starting out, I'd recommend choosing _anything_, as in, your choice of programming language ecosystem is ancillary to learning the broader technologies and patterns common to web applications. Know somebody who knows PHP you can bug? Use PHP. Find the idea of writing Python exciting? Use Python. Really like the tutorial / book you found for Ruby? Use Ruby. It doesn't matter.
Why do these discussions always end up in some black/white dicotomy? Are there situations where PHP is a valid part of a tech stack? Sure. Are there places where, if you could choose, PHP is not a good choice in the stack, Yup.
My personal view of it is that it is part of our eco-system and will not go away, how eager some of us may be to have it disappear, so seeing it getting better as a platform should make the world a little better for a lot of people that need to use it in systems that are built with parts in PHP.I cant see how that is a bad thing.
The thing I dont understand is, if you for some reason do not like to use a specific language or tech, why bother trying to convince others not to use it?
Few of the people I worked with have only one tool in their belt, and they can work in any language. We all have some favorable setup that we think is best for us/others to use in order to build better software with quicker iterations. But all of us (hopefully) also know that few, if any, stacks are 100% solid and consistent after a couple of years. There is always some parts that we wish would not exist, some script that magically does stuff that we do not dare to touch, some service that is written in some fancy language by that awesome dev that worked here 10 years ago or some really central part of our software that is written in Python, talking to a module written in C that needs to be compiled with a specific compiler that went dead 4 years ago. Even if we dream about the perfect system that just works (LIKE I WANT IT) and has a fantastic setup, it is only at specific snapshots of time systems work like that. Time, people, organizations, product requirements, marketing efforts, buzz, hacks, fixes, playfulness, boredom etc all makes system degrade over time and while it is important to manage these debts, it is more or less impossible to have a system in a state where it will always have the tech stack you want right now. That way, we will always have to address bugs in PHP, old Python-versions, rage over custom compiled nginx or whatever. Whether or not PHP is a good language or not is a meta-discussion IMO. If languages that are used by a lot of people gets better over time, that is awesome in my book. Having a perfect tech stack with only funny/new/fancy/awesome tech is at best an interesting mind experiment.
As soon as you hit a certain level of complexity in your solution/software/whatever, you will be using multiple languages. You'll have scripts written in Bash, front-ends using PHP, back-ends using C or whatever. You are definitely correct that there is no black and white here, all software just needs to be "good enough" to actually solve a problem and be worth paying for.
If PHP being slow stops you from being "good enough" then it's very likely that you can just isolate the part where PHP isn't doing a good job, re-write that in another language and keep the parts where PHP is working fine.
> The thing I dont understand is, if you for some reason do not like to use a specific language or tech, why bother trying to convince others not to use it?
Because, if others use it, I have a higher chance of also having to use it.
I do not use Java and JS at work because of my like or dislike of these languages; I use them at work because, many years ago, whoever started the project I'm working at chose these languages. Had they chosen Python or Ruby or C# or anything else, I would have to use these languages. And it does not apply only to work: if I want to contribute to the Linux kernel, I have to do it in C; if I want to contribute to LibreOffice, I have to do it in C++; if I want to contribute to MediaWiki, I have to do it in PHP; and so on.
Convincing others to not use a poor language reduces the chance of myself having to deal with it later.
I guess the "poor" in "poor language" is in the eye of the beholder and I get your point. Have you found yourself lucky in convincing the world in not using any language yet?
Tried PHP again (using it since the 3.x days off and on) a few years ago and didn't dislike it. It would be great if types were even better enforced. But then again I could have been working with Microsoft MVC instead and have an even better experience, especially in terms of autocomplete in an IDE (because C# has stronger types and they are more logical to find by trial and error, like typing a . after a string value), something which I highly value.
But I still think PHP is really cool when you just want to hack something together and indeed like many people said before run it anywhere without headache. You can output formatted text really easily. Other languages are way more formal about output. I hacked together a song recommendation and voting system for my marriage website in a few hours and people loved it.
I still can't see how it can be "mature" if it offers an iterable returnable type like in the article example yet doesn't indicate the type of the object it is returning!
It has type hints for function parameters and return types but not for arrays. This makes it useless to me.
I know everybody will say "just add comments so an IDE can interpret it" but this should be a feature of the language. Just adding comments to hint to an IDE is not a real solution.
It's still just a vector<void* > in C++ parlance. Nobody would take you seriously if you said "just add comments to indicate what your void* might be" in a large codebase.
I still can't see how C++ can be "mature" if you have to indicate the type of object it is returning!
I know everybody will say "just add a type declaration so the compiler can interpret it" but this should be a feature of the language. Just adding type declarations to hint to a compiler is not a real solution.
But it's not a hint to the compiler. It's stating a fact to the compiler. It'll stop compilation.
If I have a basket of fruit, all the items in that basket container are fruit. I can't put anything other than fruit in it. It's a basket of fruit. I know how to interact with the fruit due to its type.
If I am able to put dung into my basket, my fruit is spoiled and I cannot assume how to interact with the objects in the basket.
This is a PHP array without types at the array level. I can put dung into it and have no idea how to interact with it.
Or are you saying that a container of any type is perfectly acceptable? Did the other languages (C++, C#, Java) get it wrong?
eg. on this line can you tell me what the array holds and how I interact with it? What does array $operations hold?
> But it's not a hint to the compiler. It's stating a fact to the compiler. It'll stop compilation.
So, if I type out that something's a Banana, and the compiler stops and tells me it's actually an Apple, why did I need to type anything?
> Did the other languages (C++, C#, Java) get it wrong?
I can only speak for Java, but here goes. Here's something that compiles without warning and crashes at runtime:
Fruit[] basket = new Apple[] { new Apple(), new Apple() };
basket[0] = new Apple();
basket[1] = new Banana(); // Crash here
You and I know Dung doesn't belong in a basket, but Java sure doesn't. It will not warn about me comparing Fruit to Dung, nor is there a way to ask the compiler to warn me that I forgot to handle Banana:
void handleFruit(Fruit fruit) {
if (fruit instanceof Apple) {
System.out.println("Apple");
} else if (fruit instanceof Dung) {
System.out.println("Dung");
}
}
Here's another one:
void foo() {
Fruit[] basket = new Apple[] { new Apple(), new Apple() };
handleFruit(basket[0]);
handleFruit(new Apple();
}
void handleFruit(Fruit fruit) {
System.out.println("Do I get called?";
}
void handleFruit(Apple apple) {
System.out.println("Or do I?";
}
In the first code sample we established that the basket could only contain Apples, but now when you handle something from the basket, it's apparently any Fruit.
And when you handleFruit an Apple, there's no warning that the compiler is making a choice between the two acceptable handleFruit functions.
Anyway, just like me, this Bucket<Dung> is full of shit. Time to dump it all out. I could put it in the compost, or in the veggie garden. Anywhere that contains Dung. Likewise, the Fruit could go in a Bowl, or a Cupboard.
Here's a first pass at it:
interface Transfer<F, T> {
void dump(F from, T to);
}
class FertiliseGarden implements Transfer<Bucket, Garden> {
public void dump(Bucket from, Garden to) {
}
}
class PutAwayFruit implements Transfer<Basket, Cupboard> {
public void dump(Basket from, Cupboard to) {
}
}
It compiles, but it's missing the only safety check I really cared about - the contents must match (even if the containers vary!) Let's introduce another type variable X to assert this:
Now it asserts what I want it to assert, but it doesn't compile.
I can't call how Java handles the above stuff as 'wrong', since that's stating it too objectively. I can only say I disagree with the above design decisions (if they were deliberate) or I find fault with them (if they just turned out that way).
Yes that Java example is bad and terrible. I'm honestly amazed you can do Fruit[] basket = new Apple[]. That's terrible.
You can't do that in C++. You can slice objects but you'll get a warning in any good compiler.
I would like to know the type of the object I am working with else it'd be "auto everything" in C++ and it makes the code unreadable.
That's basically what I am finding objectionable about PHP because you've got types added as return types from functions, and also types for parameters and you can enable strict checks for the types but none of it makes any sense when you can just get an array of unknown/any type.
It's like a C++ vector of void pointers that you can cast to whatever you'd like it to be and that's really bad. It's also not very maintainable, particularly in large codebases.
It's a strange oversight in PHP given the type "safety" enforced elsewhere. I suspect they just aren't doing it because so much code would break.
I would like to see this typed array introduced so you can look at horrible codebases like the Magento example (there's loads of it) and see at a glance what you're dealing within instead of "an array of unknown type".
I will use your FertiliseGarden function shortly, thanks.
people make fun of php all the time... just see the comments in this thread.
people forget though that wordpress, drupal, joomla and magento are all written in php and most likely accounts for 70% or so of all the websites online today.
php is going to be around despite all the negativity and fanboyism of other languages. you can't go wrong with knowing php if you always want something to fall back on if you need a job. while coding wordpress websites isn't the greatest job in the world, it is a job and be thankful for that especially during these times.
so is PHP worth learning right now? and what is the job prospect looking like? if I study the language for the next few months what is the lickely scenario I will find a career in it.. I actually enjoy and like PHP unlike other people idk what it is about the languauge it looks fun and enjoyable to play with . Plus it's simple and easy opens doors to more complex languages later on down the road
If I was looking for a job as a developer, I probably would not go with PHP. But if I had a new saas that I wanted to build and turn I to a business, I would seriously consider using php to get to a rapid mvp.
There will be work for PHP developers for many years to come. It will not be the sexiest work, but you'll get paid to write code, and any day being paid to write code is better than any day not being paid, or a day being paid to do something you don't enjoy.
I stopped coding it professionally almost 20 years ago (!), but it was a great foundation to a ton of stuff, and going back through the release notes and modern frameworks I'm actually thinking I might use it for a few side projects.
Don't let anybody put you off, I say if it appeals to you that you should go and learn it and get some work with it.
If you want to work at companies like Facebook, Slack, Etsy, etc. then yeah it's fine. If you want to work for podunk company with devs that derive happiness from the language their codebase is written in rather than business success then yeah, go ahead and skip it.
609 comments
[ 3.2 ms ] story [ 378 ms ] threadsuch as?
Or Java/Scala/Kotlin. Or Go. Or Python. Or Node + Typescript.
I work with PHP 5 days a week through work and even a few years into it, i still do not like it. Its feels like a mess compared to the other languages I work with for my own projects. Even when working with something like Laravel which do mask a bunch of the pain points of the language, it still feels cumbersome IMO.
Recently I had to develop a very small CMS that manages personal web pages and it was a requirement that it could be installed very easily (i.e., by copying a single file) on virtually any hosting provider. PHP was (and is) still the natural candidate for such projects.
For average business owners who buy a WordPress template and some 5€ hosting in order to set up a business card web site on their own, on the other hand, it matters a lot. So if your project targets that group of people then PHP is pretty much the only option; anything more complicated than an FTP upload/MySQL import is pretty much to advanced for them and they generally aren't interested in learning new skills just to get a web site online.
The last thing a non-techie business owner needs is to worry about setting up a random server with bad PHP code.
I've seen some codebases using an even older version, and I think I can understand where people are coming from with their angst towards the language - but I think we should look at ourselves before we jump to the bandvagon of just hating something blindly - I remember being part of the "Apple sucks" group for no other reason than hype, and now I've used one for years as a work machine.
For me, having no standard HashMap and having to set strict mode params in functions - is an instant no go. There is no lack of better options.
Could you elaborate on this one, I am not exactly sure what you mean by it.
I haven't touched it (beyond very basic edits on my website, wordpress etc) for over a decade, but recently I inherited an older codebase at my new job. The existing codebase is an absolute mess, worse than the shit posted in those tutorials I mentioned.
But as part of the job (beyond rebuilding the application), I also had to add a big new feature to the application, a REST API. Keep in mind that due to constraints on the systems we install on, it had to be made in PHP 5.2 or 5.3 - one difference being that the older version doesn't even support an array creation shorthand (`$var = []`).
I could keep interactions with the existing codebase to a minimum. The rest was... actually surprisingly all right, thanks to me knowing what a REST API is and how to structure an application properly.
I did have to basically write my own framework (sigh) because pretty much nothing is still available that works on pre-array-shorthand-versions of PHP, but it was fairly minimal; an off-the-shelf router and URL matcher (can't be arsed with writing that myself), middleware for authentication, and a simple class structure to encapsulate different output formats (json, csv, streaming plain text).
Granted, this old version of PHP is seriously rough around the edges, and at the time it already represented great advancements in the language. I mean before 5.4 the language didn't even have a function to set the HTTP response code (you had to write the header manually).
Though I also totally forgot things like array creation syntax and wonder how I could have ever lived without stuff like that shorthand.
Of course you can write good code in modern PHP, but you can write really bad stuff too - more (at least imho) than in other popular languages. And then the whole ecosystem "drags you down" and gives PHP a bad rep -> but I don't think it's totally undeserved.
On a similar note, this actually compelled me to try Rust/something similar instead of just going straight back to Python (which I still love tbh).
camelCase? snake_case? nocase? Who knows what the global function will be.
And who knows what order the arguments should go in. Sometimes the array is first, sometimes not (in array iterating functions like map).
The thing that got my goat the most however was that referencing an undefined variable merely caused a warning, but referencing an undefined key in an array borked it.
And what's with arrays and maps being the same thing?!
The inconsistency seems to have it's logic and at that time was consistent and made sense, you need a good IDE to help with this. Using PHPStorm and then using PHPDoc to define your functions parameters and return type is a joy, the IDE will catch your type mistakes, show you where you missed to catch an exception and it will code complete stuff.
When objects were first introduced in PHP 4, the implementation was essentially an array with function references and was horribly problematic. The fundamental problems of that implementation were thankfully addressed with the release of PHP 5, featuring an entirely rethought object implementation. In the versions that have come since, up through version the current 7.4 releases, numerous interesting language features for object-oriented programming (OOP) have emerged.
I suspect you're narrowing the scope of what this article was intended to cover. It is not just a look at PHP 7.4; it's just using the recent PHP release as an excuse for a look back at the history of the language:
With PHP 7.4.5 released in April, it's worthwhile to take a look at modern PHP, how it has evolved to address the criticisms of the past, and what lies ahead in its future.
My simple point is that PHP has been "mature", in OOP terms anyway, for at least 10 years now, so the original author tying that milestone to PHP 7.4 seems weird and outdated to me.
This meme of people on HN judging articles entirely on their title really needs to die.
> My simple point is that PHP has been "mature", in OOP terms anyway, for at least 10 years now
You keep saying that and I keep replying that nobody was ever arguing otherwise.
> so the original author tying that milestone to PHP 7.4 seems weird and outdated to me.
Again, they wasn't. You just assumed they did; presumably because you just read the title and the pre block and skipped over all the rest of the content.
Nope, read it all as I mentioned already.
PHP's raison d'être remains its ease of getting an instance running on a webserver. But with fewer people self-hosting these days, that has become less an advantage. And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.
Pascal, COBOL, Oracle DB and PHP today seems like technologies that only stick around because they are legacies being maintained, not because people start new grand projects with them. Would Wordpress have chosen PHP if they started today?
You could replace "Wordpress" and "PHP" with whatever you want, depending at which point in history this comment is made.
There is nothing wrong with that. Java also follows that philosophy.
> Would Wordpress have chosen PHP if they started today?
According to Matt Mullenweg: no, but does it matter?
People do start new PHP projects, and people use old, but still maintained PHP projects.
If you're looking for shiny new things, look elsewhere. But you don't have to take away the working, well-known "old" away from others.
I think languages like PHP, Java, C++ appeal for people that solve hard problem where the fact that you have a giant ecosystem of existing libraries and a large number of existing developers compensates the fact that the language is not "cool" or is missing some feature that you probably don't need anyway or workaround it with a library.
- Existing team is comfortable with using PHP - Existing project is tightly coupled PHP monolith - Existing project cannot be migrated to other language fast enough if needed
All are valid and justifiable reasons. Learning new language is not the easiest and we should think of the people.
I must emphasis though, all party must not freeze in time. They should learn to adapt. PHP is getting smaller. The decline is slow enough to let people migrate or jump ship but fast enough that it is recognizable.
Demands are growing for languages and environments which provide more than PHP, simplest examples would be granular websocket connection control, explicit process control, whitelist-by-default security, rise of cloud and edge computing, and of course, trends, "cool new stuffs" which is not always good for everybody, but always exciting especially for the naives.
There might be a day Java is getting replaced due its huge memory usage or its tendency to be verbose and hard to read. Golang is a contender for the memory usage side of the spectrum, NodeJS is the contender for the ease of use side of the spectrum.
There might be a day C++ is getting replaced due to its "harder to write secure code". C++20 is quite cool, but there's a new cool kid Rust where you most probably won't write bad code, can be actually faster than C++ / C in some cases, and can run on browsers.
May all programmers of old languages survive and thrive and in the new world.
Even for new projects, say you have a desktop app and you want to let the users submit some data and save it on your server(like feedback or crash reports), you can do this on your server with 1 PHP file and a few lines of code, no dependencies on 300 packages.
And it will likely be an order of magnitude more scalable & reliable than the PHP, having proper logging, security features, etc.
Whereas such PHP systems in my experience tend to be unreliable, in need of maintenance and often broken.
The Java/ Spring Boot option will also take you all the way to a high-end commercial system/ large website/ webapp.
It will also be probably faster then a Java framework since you don't have a function call stack 30 levels deep (not a Java issue , all magic frameworks including PHP one have such giant call stacks)
Simple file upload without any future expansion plan doesn't need hours of discussion.
Btw my scenario was about sending feedback ro stack traces, this are just text, no giant file uploads and nothing insecure about it.
I recently upgraded a huge legacy codebase from PHP 5.2 (released 2006) to PHP 7.4 (released 2019) with relatively few changes, mostly changing the use of deprecated functions & misuse of variable references.
PHP has a reliable ecosystem of 3rd libraries with LTS releases. I am not aware of something like Symfony [1] for Rust or Go.
[0] https://www.indiehackers.com/podcast/007-john-onolan-of-ghos...
[1] https://symfony.com/
Which is totally fine btw. Most work isn't "we're engineering a new motor for a F1 race car", most work is "this car's motor is broken, replace it". You don't need a CS degree and brilliance to write code that deals with databases and APIs, which is the super majority of code.
You need smart people that spend a lot of time on difficult problems to create strategies that are easy to follow and tooling that is easy to use. And then you just need a lot of people using those tools and applying those strategies to real world problems.
What good is it if you have something that allows those that fully grasp it to write things ten times as fast, but you only have 10 people that can actually do that? I'd much rather pick something where I have ten million people that can use it, the output is just so much higher, and you don't get single points of failure because the one guy in your city that knows that language and does freelance work has decided to move on to a different language.
I guess we don't, actually. Oh well. :'). You make a perfectly reasonable business point.
If we want to provide something to the masses, we'll have to provide something that can be used by the masses, not just by a highly trained elite. PHP is mass production development. It's not necessarily elegant (though you can do a lot in it, it doesn't have to be as messy as WP is), but it gets the job done AND it empowers large groups by being easy to learn and not requiring advanced understanding before you can actually achieve something with it.
I do still believe that we want experts that do the kind of work you're describing though. But I believe they shouldn't distance themselves from the ordinary people, but instead find their elegant solutions and then give them a handle so that the uninitiated can use them. Tooling is leverage, individually but even more so collectively. Imho, if you're a brilliant computer scientist and you work on "normal" real world problems, you're wasting your talent. Even if you find the greatest thing that runs 100 times as fast as the previous one, you've sped up one thing out of a million. Instead, build something that'll enable normal people to speed up their projects by factor two, your impact will be immeasurable.
PHP does a terrible job of weeding out the terrible hack programmers. For some reason, people have no problem going into a PHP codebase and monkeying around with it, where something like Rails or Java will at least intimidate them and make them think twice.
Regarding frameworks: of course PHP has an advantage there, because it's a more mature ecosystem. But frameworks written in PHP like Symfony or Laravel tend to forget that they are based on a scripting language (which years of optimization have made very fast for a scripting language, but still), so using their features extensively will slow down your application...
And if you are doing something moderately complex/serious/modern you probably need/want composer anyway - because uploading all of the million files via FTP is cumberstone (let's not even get into the versioning/modern deployment practices). Then you are at shell already and not that far away from other language deployments.
You can start with a plain HTML page and go "Hey, I want to do X" and just throw some code in the middle of the page. When you decide you need a database, MySQL is right there and easy to use. When you decide you need some libraries, you can just download and `include()` them. All of this can just be FTP'd up to some server somewhere.
As this grows bigger, there are tools like composer and frameworks/libraries like Laravel and Symfony. You can still FTP those, but once that gets painful you can start to learn the bit of *nix skills it takes to start managing this different ways.
At no point have you had to worry about nginx/apache/supervisor/anything else. But whenever you're ready, that's all there too.
This is basically the path at least one guy I know took to going from working in a totally non-technical industry to building a massive (almost 2 million lines at this point) application that allowed people in the industry to stop working with a bunch of exploitative big name companies and instead self-manage and earn more money. And now that product makes a bunch of money for him.
And then there's the scales that places like Twitter/Facebook/etc took it.
I think the big thing that always gets missed here is PHP's... egalitarian nature. Yes, at some point it just ends up a in some ways less-good version of other things. But it provides an incredible opportunity for people who aren't engineers to realize their ideas without immediately becoming overwhelmed with needing to learn a huge amount of foundational knowledge before they can lay down their first line of useful code, and seeing that through to crazy places.
There is also a maturity in the tooling and community for PHP that doesn't exist in newer, better languages. There's no shortage of developers, and moreso nowadays there's also a huge body of best practices that embody good software engineering.
If what you want is a monolithic standalone web application paired with SQL, I'd argue PHP is a pragmatic choice from a business point of view. I would also argue that a monolithic web application is all the vast majority of companies need.
The biggest source of bad software and failing to meet business requirements in my experience has been following the industry's whim and rebuilding every time the wind blows in a new tech stack. If you're a PHP shop delivering web applications, you will be able to do that successfully for years to come. Picking the "right" language is a wild goose chase, just be good at the language you choose and you'll be able to deliver good software reliably.
I don't think fewer people self-host. There are some going to big clouds, there are some using integrated offerings like squarespace, but there are still many hosting their website with a regular hoster. And probably in total many more than in the past.
> And even for those who do self-host, the advantage is becoming narrower as other languages have made it easier to distribute their web applications.
Did they? How?
With PHP, all the users has to do is to fetch the project files and upload them with FTP to the directory the hoster told them to. No other environment matches that - and no other environment is supported by those hosters. If you want to run something else - like Ruby, which I prefer to use, or something that creates a binary for you - you are looking at a completely different type of hosting. Digitalocean, Heroku - and that's not as easy, if the application is not provided as a one-click-install.
I had to check and I'm paying about 4$ a month for a traditional PHP server host vs 5$ for a VPS which I can run whatever I want on. And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell. Then only thing that makes this harder is having to kill the server and restart on deployment. I dont find that to be that much harder.
> And if you want a barebones deployment for lets say rails, what is stopping you from just copying files over with scp and running bundle and rails s from the shell.
I mean, it's not like I'm not doing that for myself. Even my PHP blog is not with a traditional hoster. But there are many things that can go wrong there - for the ruby example starting with the ruby versions, additional system dependencies. And then you need something to make the app restart after a reboot (supervisor is thankfully excellent), and probably a nginx in front of the webapp, and letsencrypt, and does your VPS take care of backups? Each task not impossible, but in total vastly more complex. Some users can handle that, many don't.
I just did some freelance work on a wordpress site (and I'm involved with a different PHP blog engine, serendipity), and it's so nice when the setup that those PHP projects present you with is clear and straightforward, and on top of that everything that might be complicated even a mediocre hoster had years to solve now.
I know some shared PHP host that cost $8/year and have larger memory_limit than the available RAM in $5 VPS.
Pretty much every shared host I had to work with (I've been freelancing for a few years), have been terrible, except for two platforms, both of them were expensive and aimed at particular PHP software.
From my experience, the share of people who can only deploy PHP is steadily shrinking. PHP remains the default, and popular, but easily deploying other languages is becoming more feasible, and we're shipping docker containers with Python/Go/Node/whatever code a lot more often these days.
Let's not idealize things. For moderately complex apps, even back in the days, this falls pretty fast: missing PHP modules in default distro installation, PECL/Pear extensions, hosters messing with the php.ini in bad ways, etc. And now the dependency management and deployement systems pushing you to access a shell on your server...
There is no shell accessible on these servers, it's on the project to include all dependencies. Composer in this world is strictly not for users, but only for developers. That's a good thing.
Also, I don't know about now because I left this ecosystem long ago, but it was very common for apps to bundle their own custom installer scripts (access a webpage, fill a form and so on). Certainly useful for the users but it was never standard and required a lot of work for the developers (and came with their own requirements and bugs).
But I like some of the recent additions to the language. At least the PHP Team keeps up with the competition.
Dart is more suited for this type of thing if one wants a new and shiny statically typed language with great performance.
Catch up to other languages? You can easily argue the opposite, that other languages has finally catched up to PHP, ease of deployment, ease of horizontal scaling, fast reload/build time, built in string templating, simplified variable syntax (auto, var), etc
I can go on, but if you already framed the question to the disadvantage of one party you will not really get a fair answer.
That's a very big If in PHP's case.
It does a few things and does them well.
If you need a fast hot reload, it isn't trivial in other languages. PHP does it with no effort. Save and refresh runs the updated code instantly, not to mention asking people to run PHP app is far easier as every general hosting provider has PHP installed.
On the other hand, language structure is quite behind others but can't blame when it had been around since 20+ years ago.
The new type hinting is so basic, not sure how realistically useful it is compared to typing in TypeScript.
Hot reloading works the same for all languages I know, which is a hardcoded port pushing notifications to clients that they should reload the browser.
The client is mostly a js library or a browser plugins. Either works.
I know it's also used differently in some contexts, but they wouldn't apply here as far as I can tell. There aren't any long running processes that need to reload the code after all. It's only read when is actually executed. Which is never unless you use the hot reloading I was talking about earlier... Or trigger it manually, making it a regular reload.
most examples of why php is so easy to deploy show it with hello world examples you'd never encounter in the wild.
yes, you can edit the php code directly on the server that is executing it. just like with python, nodejs, ruby ... and even java if you're not worrying about scalability.
there is really very little difference if you ignore the fact that it gets hard with the codesize and the environment in which the service is deployed in. the language is almost always the smallest challenge.
and fwiw, i'm definitely not "against" php in any way. i think ssr script languages are wonderful for easy development - especially if you combine them with something like intercoolerJS for interactivity. extremely easy to get started and you're even able to make ssr-"components" by just fetching each segment separately, which isn't really any overhead with HTTP2 nowadays.
As for node.js, I set up pm2 to watch for file changes and restart ts-node process and this takes a few seconds, which is slower than I can hit alt-tab back to the browser, which is annoying to see 'Bad Gateway' error page quite often, not to mention embarrassing to explain and help set it up to someone new to other languages than PHP.
PHP is instant and I'd like to know if there's a solution in node.js that can do the same.
At the same time PHP is trying to reinvent itself by adopting a strong type system and experimenting with async and long running processes. But these are niches that are already filled better by other languages (Java/C#, Node, Go), so it feels like they are fighting an uphill battle. But maybe it is that tenacity of the language to stay relevant that makes it attractive to a younger generation of developers and decision makers.
Greenfield projects are much less important than brownfield projects. After all, a project is new only for the first few months of its existence. After that, it all becomes legacy code :-)
And techs with mainstream adoption in the post DotCom bust era, especially if they're free and Open Source, will be around for decades. A newbie PHP programmer in 2020 will most likely be able to retire in 2065 as a veteran PHP programmer, if he/she so wishes.
Of the first programming languages that cater to novices to some degree (which is important to project health, because excessive gatekeeping is toxic), PHP was the first to make Curve25519 and Argon2id widely available (through the sodium extension). (7.2)
Even with the "just use FFI" mindset of other languages, the experience is janky at best.
For example: Before sodium-plus [1] came along (which was something I created, so I'm removing it from the table for my criticism of the JS crypto ecosystem), JavaScript required knowing which of the following packages to install: [2] [3] [4]
There was no guidance available anywhere. Some of these APIs were suitable for browsers, others for mobile devices, and still others for server-side JavaScript. And their APIs were subtly incompatible with each other.
Java's in a similar situation [5] today.
> Java (Java Native Access): libsodium-jna
> Java (Android): Lazysodium for Android
> Java (Android): Libstodium
> Java (Android): Robosodium
> Java (Android): libsodium-JNI
> Java: Apache Tuweni (crypto module)
> Java: Lazysodium for Java
> Java: jsodium
> Java: Kalium
Yikes.
With PHP7, you just had to update to the latest version (and make sure your OS package vendor isn't huffing or eating glue, which was rare but still existent) and you had it.
There are probably still languages and runtimes today that make using modern cryptography (Ed25519, X25519, etc.) a miserable experience.
Miserable experiences moving to modern cryptography keep peoples' projects trapped in an early 2000's RSA-PKCS#1v1.5 + AES-CBC hellscape reminiscent of SSLv3 but somehow worse.
Thus, I would argue that what PHP did with libsodium counts as revolutionary.
Your move, $languagesThatHackerNewsFindSexierThanPHP
[1]: https://github.com/paragonie/sodium-plus
[2]: https://www.npmjs.com/package/libsodium-wrappers
[3]: https://github.com/sodium-friends/sodium-native
[4]: https://www.npmjs.com/package/sodium
[5]: https://libsodium.gitbook.io/doc/bindings_for_other_language...
It's just a weird comparison. PHP is competitive with JS, Python, Ruby and even Java. But Rust? That's C/C++/D territory. And Go is somewhere in between.
Scripting and command line automation is executed better by Python and Ruby, which excel for writing Unix scripts and tools.
I do not see what the use case for PHP is in 2020.
PHP has one of the most abhorrent language syntax designs this side of Perl, and the standard library is wildly inconsistent.
I really wish PHP would just die. Continuing to drag it along like the dead carcass it is wastes so much human effort. The longer it exists, the longer we have to support it.
How do you know what version you have deployed unless you copy everything you deploy to some archive somewhere?
How do you roll back?
How do you find out if you monkey-patched something?
Deploying Docker images or static binaries is vastly superior and no more difficult. It's just a new paradigm.
All three of the issues you raise would be solved by involving a VCS somewhere in your FTP deployment.
Incidentally, claiming that either option is "no more difficult" than FTP upload or even using VCS is either disingenuous or at least a little blinkered. FTP can work as simply as copying files between "folders", I've successfully taught my non-techy parents to use FTP. Setting up docker images or static binaries requires significantly more understanding of what's going on but of course provide speed, consistency and scalability benefits.
Containers definitely has its place, but there hundred of thousands problems out there that needs to be solved for a low cost, otherwise it will never be solved, and a container will just increase that cost with little or no gain for the customer.
Many small businesses just want to get online, how does PHP help them? Actually it doesn't.
Small businesses use Wix, Shopify, Medium. Anything that prevents them from having to worry about code.
Python has a ridiculous time it needs to start up, it is not suited for any batch task that requires a lot of process creation.
> PHP has one of the most abhorrent language syntax designs this side of Perl and the standard library is wildly inconsistent.
At least it has a standard library that is both usable (in contrast to the JS ecosystem, remember left-pad?) and actually not that inconsistent if you have experience in developing C - most of what is described as "inconsistent" comes right from there.
And: the stdlib of PHP can easily be expanded upon by a rich variety of Composer libraries that can easily be deployed. Let's compare that to... Java, for example. Three popular dependency managers (and build tools): Ant, Maven, Gradle. Plus classpath worries if you're using Tomcat or other application servers which means you also have their libraries in the mix.
Changing code in production? In PHP it's as easy as changing the file using rsync and automatically all new incoming requests will use the new code, vs Java where you have to restart the server (which for large project means minutes of downtime).
In PHP you just need to add to your HTML page a few lines of PHP code and copy it using scp to any share server hosting that costs 4 dollars a year.
No "automation", no "cloud", no REST APIs, no WSGI/Gunicorn, etc. just plain Apache with mod_php enabled, which is available everywhere. I don't think anything can beat PHP productivity for such simple usecases.
PHP isn't being replaced so much by Python, Go, and Rust as it is being replaced by Medium, Wix, and Squarespace.
This is the direction things are trending.
Unless you're distributing your binary to 3rd parties, why?
If you really don't want to deploy changes to e.g. a single/small number of controller or template files as independent file changes, build your PHP app into a .phar archive, and deploy that.
I don't specifically think PHP, when run (IMO) the best way it can be, is "easier to deploy" but I also don't think it's harder either.
I'm going to ignore your other comments because they're personal opinions and while you express them as facts, I realise you probably mean them as statements of opinion.
But the last part, I just don't understand:
> I really wish PHP would just die. Continuing to drag it along like the dead carcass it is wastes so much human effort. The longer it exists, the longer we have to support it.
Who is the "we" in this statement? You clearly don't like it personally, so why does it affect you, at all? I'm not a huge fan of Java, but I don't go around claiming that it should "die" or that humanity is somehow worse off because it exists.
There's no such thing as a client-side PHP application, so it doesn't even compare to e.g. genuine concern over tech choices that are 'forced' upon users of a website (e.g. Flash, SilverLight, ActiveX, javacript bloat, etc). If the backend part of the system does what it needs to do, the language/framework/runtime it's written in/with is meaningless.
But for larger projects the available frameworks are just okayish. I think Symfony is closest to what a good framework should be. But every time I use it I wish it would be like .NET
Today .NET core is also available on Linux and very easy to deploy so I don't think I will ever start a big project in PHP again.
But for quick smaller and CMS[1] projects PHP is still my goto language.
[1] If you are looking for a great PHP CMS: https://processwire.com/
I have quite a bit of xp with Python (Django/flask) and less with php.
I think you need VS Code with some extensions, .NET Core installed and you should be off to the races in half an hour.
Most can be done via de command line but an editor like VisualStudioCode could be handy. Personally I use Jetbrain's Rider as IDE on Ubuntu.
Deploying can be done via the `dotnet publish` command. But tools like Teamcity can also be very useful. When you built a webapp it includes the Kestrel webserver. So it is just a matter of running the app and navigating to the port it listens to.
.NET core is a complete set of tools to create console apps, (web)APIs and webApps. This includes the .NET framework.
.net has proper debugging working compared to node.js, has great standard library, can develop 3d games, servers, mobile apps, web apps, machine learning ,desktop apps and even (some) embedded devices.
Great instrumentation and support with quality updates from MS and the community. The IDE is superb and free (community edition at least), drag & drop desktop & mobile app development (if you wish).
I've worked with PHP for about 4 years (5.x - 7.0 days), .net for the next 6 years and node.js for the last 1 year, and every day i work with node.js i wish i could switch everything to .net because it's sooo much better & smoother experience, and everything just works together so well.
C# is an inflexible language that just can not have a modern web framework on it. MS extended it with hard-coded functionality to closely emulate a framework and did an ok job on it, but it emulates a closed down, inflexible framework that is stuck in time. It's not a disaster, but it doesn't compare to the stuff that has kept evolving for the last decade.
Maybe the worst thing is the composer (it's slow.)
I think it’s a good first tinkering language for people around that age: sort of like BASIC, but for the web.
I am glad PHP is still around; it is a very useful signal on the resume or CV of someone who uses it a lot.
It’s sort of like c# in that regard (exception granted for vertical-specific devs who work professionally to ship commercial apps with Unity), or Visual Basic before it.
Same goes for heavy Java outside of Google/Amazon backend, or outside of Android.
Most of these people are desktop Windows users by choice, too. It’s a very specific type of techie. Perhaps one day I should make an ishkur-style taxonomy. :D
I think this is also why almost all forum software is written in PHP.
Can you point to some research that scientifically proves that the use of dollar sign in variable names makes it harder to solve computer science problems?
2. Carpal tunnel syndrome, especially on keyboards where "$" can only be reached via shift.
2. rebind your keyboard.
This is what programmer and blogger Jeff Atwood - who isn't a fan of PHP - has written about PHP:
"If you want to produce free-as-in-whatever code that runs on virtually every server in the world with zero friction or configuration hassles, PHP is damn near your only option"
He wrote that in 2012. It's 2020 and I can't think of any other language that has caught up with PHP's ease of deployment. If you want to get your customers to self-install your software as painlessly as possible, what other language can match or exceed the ease of deployment of PHP?
Anything with containers. Docker was a real game-changer here.
>In our dashboard you will find pre-configured Open Source apps like WordPress, Plone and other. They are all based on the official docker images and can be deployed with just one click.
Otherwise I don't see how something like this is that much more difficult https://www.openshift.com/blog/deploying-applications-from-i...
Or this https://kb.sloppy.io/en/articles/1313693-setting-up-mongodb-...
Still if I want to write a simple web app in < 1 day, I would definitely use PHP.
Plus if the deployed app has its own domain/subdomain, you need to set that up, set up TLS certs etc., so it is really no different in the end. You either configure nginx to proxy all requests for some domain to an index.php file, or you proxy them to a locally running container (where you also don't have to worry about versions of software installed on that server, clashes between different apps, etc.).
Commercial PHP webhosts also have an "installer" for automating all of this, provisioning databases, etc.
A lot of this can also be automated by various Kubernetes controllers (DNS configuration, TLS cert provisioning, databases, volumes, backups, monitoring etc.) if you already have a cluster. And for packaging installable apps, there is Helm and its charts (e.g. https://hub.helm.sh/charts/bitnami/ghost), you can also manage them from a GUI dashboard (https://kubeapps.com/) or even from a git repo (https://argoproj.github.io/argo-cd/) if you want to have a repeatable history of all changes to the environment, updates, etc.
If using a popular framework the documentation usually provide these lines.
And surely you must be joking when comparing Kubernetes' complex configuration to anything else.
So is setting up a `proxy_pass` to a locally running container that exposes a port to localhost (https://nginx.org/en/docs/http/ngx_http_proxy_module.html#pr...).
Literally, just start `docker run` with a proper restart policy, set up a proxy_pass on nginx and you're good to go (unless the app requires external services, databases, etc., but you have the same problem with PHP).
Plus you don't have to worry about things like "do I have the correct PHP version for all my apps?" or "do I have the necessary PHP extensions installed in the system-global PHP?
>And surely you must be joking when comparing Kubernetes' complex configuration to anything else.
Setting up a Kubernetes cluster is indeed complex. Installing apps into an already configured cluster (e.g. ordered as a service from someone) is not (unless the app itself is complex of course).
I was comparing it to the automation tools that "traditional" webhosts have for installing and managing application deployment, replying to a comment above ("They had to write an installer ecosystem..."). If you just want to have one VPS with nginx on port 80/443 and run apps there, you don't need any of that stuff. The container images are the same either way.
In that sense, PHP is like a early variant of Lambda ;) When there would be a universal, simple-install, simple-use, low-requirement version of Lambda (incl. Gateway etc) we would see a easier hosting market for all the languages beyond the public clouds.
That is probably never going to happen. GraalVM native images are a more realistic approach in this space, and even that is not trivial in most cases.
Not saying Elixir is the answer to everything but that's where it differs in the concurrency sector. It doesn't have static typing though, which is a requirement for some.
The shenanigans that WP plugin devs go through to get around the lack of a queue is ridiculous (chunk the file and keep reloading the page until we’ve processed all the chunks or have an Ajax endpoint that processes a chunk at a time...) and the when I asked a marketing friend of mine who works with Wordpress he said that redis is an “advanced requirement” and I should keep things simple.
In Django land I’ve always set up queues even just to send emails because it keeps things snappy.
What solution would you prefer for this kind of jobs? launching a new thread directly? or have a worker project always running and send to it the job directly?
Using Wordpress (or it's plugins) as any kind of reference for what PHP is capable of, is like using McDonalds as the basis for a cook book.
The example was where each SQS call (there could be as many as five) was taking between 50ms-200ms, and logging took another 75ms. The rest of the request processing time was approx 50ms.
There's a bunch of other architecture options we could have looked at, but due to the share-nothing nature of PHP, they weren't an option.
Arguably the same problem would exist in other languages, but at least there we would have had the option of using threads, and we could have executed multiple calls to SQS in parallel. Probably not something I'd want to do all the time, but it would be nice to have had that option in this case.
Callbacks are not how you do non-blocking IO. You typically have multiple threads and use constructs like futures or promises to make them easy to manage.
PHP bakes you into a very simple request flow. There's so much more you can build if you get out of that manner of thinking.
Edit: FYI I have experience with other languages too, so if at my work I use PHP does not imply that I am some inexperienced person that has no idea how other languages work. I do not have experience with your domain of high concurrency, low latency stuff but I worked with threads, and thread pools and multi-processes programs(it happened that some thread would segfault and bring the app down so we had to use background processes instead of threads) .
Requirements were strict typing, functional programming support, built-in concurrency, decent library support, and real support for both native and Javascript. It pretty much came down to Kotlin or Rust.
I really want to like Rust more, but the library support, and the jobs in my area just aren't there (yet?).
Picking up Kotlin feels like coming home.
Just to be clear, my reasons stated above is why I'm moving to Kotlin. I make no claim that other people should or would want the same things. I've realised that I like languages with explicit strict typing, and that allow for a greater level of expressiveness at the cost of a higher intrinsic complexity and the comprehension that requires.
[0] https://kotlinlang.org/docs/reference/js-overview.html
Kotlin also feels like a pretty safe bet since both Google & Jetbrains are backing it.
You can defined what types/interfaces methods needs to return, what types/interfaces variables must have, what types/interfaces the method arguments needs to have.
It also supports class inheritance, abstract classes, interface classes, class traits, etc.
If PHP hadn't made advances in it's type system with the 7.x series, I probably would not have stuck with it this long.
However, while PHP the language supports strict typing, it does it at run time (inherently a limitation of scripted languages, I know), rather than compile time.
By operating as a non-threaded application, entire categories of bugs and security holes are avoided.
Are there situations where threads could genuinely help? Sure, there is always an exception to any rule, but for the vast majority of projects where PHP is used, I don't believe threading would achieve much in terms of performance gains.
The first example in that article even highlights that `in_array` has a `$strict` parameter.
I'd bet a months salary it's easier to teach developers to use strict comparisons (either through arguments to be passed, or strict operators to be used) than it is to teach developers how to avoid thread-safety bugs.
Though, it might take longer to train them to spot every place where they could/should be using some stricter version of the defaults. That's the problem with opt-in safety.
On the other hand, there are languages that make thread-safety bugs much less likely. Some day those ecosystems will catch up to the languages that have been around "forever" and we'll get our cake and eat it, too.
I don't recall ever seeing any kind of dev tooling that can just automatically fix thread safety issues.
go is incredibly weak language in some regards (error handling?)
From these 3 I would still pick PHP for webdev.
Lots of legacy stuff has been removed.
Static typing has been added as a feature back in PHP 7.0.
The paradigm and the workflow are alien to most, the discipline needed to write with it needs learning.
I realized I have to drop MediaWiki because my host didn't expose PHP proc_open() feature.
I don't even know where to start. A natively written syntax highlighter can be considered as an important brick in an ecosystem (GeSHi was used everywhere few years ago), but it looks like no-one is working on it anymore so MediaWiki did an strong technological move to use Python via a sub process.
This kind of move (dropping a existing natively written tool for a tool from another language) shows how bad the ecosystem situation is.
Or a necessary one – emscripten's main use case is "everyone has a browser", but there's very few PHP hosting offerings where you can't shell out and just run straight native code (in your own little isolated sandbox).
Parent poster said that they couldn't do that on their host, though. Which breaks a MediaWiki feature (syntax highlighting for code blocks).
This problem isn't unique to PHP. I have seen this is many projects across all kinds of different languages and tooling.
Unfortunately, if there's no good alternative written in PHP, MediaWiki could have either reimplement it from scratch. In my opinion, GeSHi isn't the best implementation of a syntax highlighter, so I get their reason to not adopt it. Writing a syntax highlighter from scratch isn't a trivial task either.
None of this says that the PHP ecosystem is dying though. MediaWiki isn't going to suddenly move away from PHP. Nor will many, many of the other big name projects that are still built on top PHP, and as long as there are big name projects, PHP ecosystem will continue to evolve.
I will say choosing a Python sub-process at the sacrifice of portability (considering how many people simply run this on a PHP webhoster) is quite surprising.
I've done things with PHP that would give people nightmares. It's a far more capable language [1/2] than most realise and with version 8 bringing us JIT things just keep getting better. Would I use PHP if I was starting out today? Unlikely, but I know PHP inside out and can wield it to my wicked ends with ease so won't be dropping it anytime soon.
[1] https://stitcher.io/blog/php-in-2019
[2] https://stitcher.io/blog/php-in-2020
So just out of curiosity, if you hypothetically did start learning web development today from scratch, what would you spend time learning instead of PHP?
My personal view of it is that it is part of our eco-system and will not go away, how eager some of us may be to have it disappear, so seeing it getting better as a platform should make the world a little better for a lot of people that need to use it in systems that are built with parts in PHP.I cant see how that is a bad thing.
The thing I dont understand is, if you for some reason do not like to use a specific language or tech, why bother trying to convince others not to use it?
Few of the people I worked with have only one tool in their belt, and they can work in any language. We all have some favorable setup that we think is best for us/others to use in order to build better software with quicker iterations. But all of us (hopefully) also know that few, if any, stacks are 100% solid and consistent after a couple of years. There is always some parts that we wish would not exist, some script that magically does stuff that we do not dare to touch, some service that is written in some fancy language by that awesome dev that worked here 10 years ago or some really central part of our software that is written in Python, talking to a module written in C that needs to be compiled with a specific compiler that went dead 4 years ago. Even if we dream about the perfect system that just works (LIKE I WANT IT) and has a fantastic setup, it is only at specific snapshots of time systems work like that. Time, people, organizations, product requirements, marketing efforts, buzz, hacks, fixes, playfulness, boredom etc all makes system degrade over time and while it is important to manage these debts, it is more or less impossible to have a system in a state where it will always have the tech stack you want right now. That way, we will always have to address bugs in PHP, old Python-versions, rage over custom compiled nginx or whatever. Whether or not PHP is a good language or not is a meta-discussion IMO. If languages that are used by a lot of people gets better over time, that is awesome in my book. Having a perfect tech stack with only funny/new/fancy/awesome tech is at best an interesting mind experiment.
If PHP being slow stops you from being "good enough" then it's very likely that you can just isolate the part where PHP isn't doing a good job, re-write that in another language and keep the parts where PHP is working fine.
Because, if others use it, I have a higher chance of also having to use it.
I do not use Java and JS at work because of my like or dislike of these languages; I use them at work because, many years ago, whoever started the project I'm working at chose these languages. Had they chosen Python or Ruby or C# or anything else, I would have to use these languages. And it does not apply only to work: if I want to contribute to the Linux kernel, I have to do it in C; if I want to contribute to LibreOffice, I have to do it in C++; if I want to contribute to MediaWiki, I have to do it in PHP; and so on.
Convincing others to not use a poor language reduces the chance of myself having to deal with it later.
But I still think PHP is really cool when you just want to hack something together and indeed like many people said before run it anywhere without headache. You can output formatted text really easily. Other languages are way more formal about output. I hacked together a song recommendation and voting system for my marriage website in a few hours and people loved it.
It has type hints for function parameters and return types but not for arrays. This makes it useless to me.
I know everybody will say "just add comments so an IDE can interpret it" but this should be a feature of the language. Just adding comments to hint to an IDE is not a real solution.
It's still just a vector<void* > in C++ parlance. Nobody would take you seriously if you said "just add comments to indicate what your void* might be" in a large codebase.
I know everybody will say "just add a type declaration so the compiler can interpret it" but this should be a feature of the language. Just adding type declarations to hint to a compiler is not a real solution.
If I have a basket of fruit, all the items in that basket container are fruit. I can't put anything other than fruit in it. It's a basket of fruit. I know how to interact with the fruit due to its type.
If I am able to put dung into my basket, my fruit is spoiled and I cannot assume how to interact with the objects in the basket.
This is a PHP array without types at the array level. I can put dung into it and have no idea how to interact with it.
Or are you saying that a container of any type is perfectly acceptable? Did the other languages (C++, C#, Java) get it wrong?
eg. on this line can you tell me what the array holds and how I interact with it? What does array $operations hold?
https://github.com/magento/magento2/blob/420a8b6209a4e62ede9...
So, if I type out that something's a Banana, and the compiler stops and tells me it's actually an Apple, why did I need to type anything?
> Did the other languages (C++, C#, Java) get it wrong?
I can only speak for Java, but here goes. Here's something that compiles without warning and crashes at runtime:
You and I know Dung doesn't belong in a basket, but Java sure doesn't. It will not warn about me comparing Fruit to Dung, nor is there a way to ask the compiler to warn me that I forgot to handle Banana: Here's another one: In the first code sample we established that the basket could only contain Apples, but now when you handle something from the basket, it's apparently any Fruit. And when you handleFruit an Apple, there's no warning that the compiler is making a choice between the two acceptable handleFruit functions.Anyway, just like me, this Bucket<Dung> is full of shit. Time to dump it all out. I could put it in the compost, or in the veggie garden. Anywhere that contains Dung. Likewise, the Fruit could go in a Bowl, or a Cupboard.
Here's a first pass at it:
It compiles, but it's missing the only safety check I really cared about - the contents must match (even if the containers vary!) Let's introduce another type variable X to assert this: Now it asserts what I want it to assert, but it doesn't compile.I can't call how Java handles the above stuff as 'wrong', since that's stating it too objectively. I can only say I disagree with the above design decisions (if they were deliberate) or I find fault with them (if they just turned out that way).
You can't do that in C++. You can slice objects but you'll get a warning in any good compiler.
I would like to know the type of the object I am working with else it'd be "auto everything" in C++ and it makes the code unreadable.
That's basically what I am finding objectionable about PHP because you've got types added as return types from functions, and also types for parameters and you can enable strict checks for the types but none of it makes any sense when you can just get an array of unknown/any type.
It's like a C++ vector of void pointers that you can cast to whatever you'd like it to be and that's really bad. It's also not very maintainable, particularly in large codebases.
It's a strange oversight in PHP given the type "safety" enforced elsewhere. I suspect they just aren't doing it because so much code would break.
I would like to see this typed array introduced so you can look at horrible codebases like the Magento example (there's loads of it) and see at a glance what you're dealing within instead of "an array of unknown type".
I will use your FertiliseGarden function shortly, thanks.
people forget though that wordpress, drupal, joomla and magento are all written in php and most likely accounts for 70% or so of all the websites online today.
php is going to be around despite all the negativity and fanboyism of other languages. you can't go wrong with knowing php if you always want something to fall back on if you need a job. while coding wordpress websites isn't the greatest job in the world, it is a job and be thankful for that especially during these times.
I hope you like working on legacy projects full of spaghetti code.
I stopped coding it professionally almost 20 years ago (!), but it was a great foundation to a ton of stuff, and going back through the release notes and modern frameworks I'm actually thinking I might use it for a few side projects.
Don't let anybody put you off, I say if it appeals to you that you should go and learn it and get some work with it.