18 ms·
PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "u
by tiffanyh 4y ago
PHP has so many hidden benefits:
- it's stateless by design (much easier to scale)
- it was "serverless" before Serverless
- surprisingly performant
- no "unknown unknowns". it's so tried-and-true, there's no surprises
- deployment is so simple, just drop a file on a web server. No middleware needed.
- No long compile times because there is no compiling needed.
EDIT: why the downvotes? If you don't agree, just reply so we can have a healthy dialogue.
EDIT2: I also think there is something unique about PHP documentation. It has plenty of real life examples, and the ability for users to leave comments allows you to hear directly from others "gotchas" that people have experienced. I feel like PHP documentation is very undervalued.
- candiodari 4y agoI really like the serverless aspect. I still think nothing has the deployment story that PHP applications have. Just upload some source and your website is up.
- themodelplumber 4y agoPixar should make a film called "Deployment Story" in which PHP is basically Woody (maybe it's even just the PHP stuffed elephant?), and Woody ends up in the box on the street, and then Woody's dev pal doesn't realize what they've really lost until some reflection is done. I'd watch that.
- thomaslangston 4y agoThis reads better when reflection is used in both meanings.
- koolba 4y agoThere has to be a Debian angle to this plot as well.
- quickthrower2 4y agoIt is also JSX before JSX was invented too :-)
- ed25519FUUU 4y agoDo PHP applications really require no system packages for any use-cases?
- paulryanrogers 4y agoWhat do you mean by system packages? There are PHP packages now and Composer. Though core and its bundled extensions are quite rich. So 3P packages aren't strictly necessary.
- lmm 4y agoPHP is pretty batteries-included, sometimes to a fault (it comes with things like 3 different MySQL drivers in the standard library). I'm sure there are cases where you'd want to install a C extension that depended on some system library, but I can't actually think of any right now.
- asddubs 4y agoimagick for imagemagick is a common one. but yeah, you can go really far with just relying on php standard features
- mekster 4y agoInterestingly, that has been the case for 25 years or so now but none except perl was able to do that?
- dogleash 4y agoPerl's not unique in that way. Any language can talk cgi. That's literally the purpose of cgi. Perl was just the popular scripting language of the day. If you're using something other than cgi to get your httpd to talk to your webapp, your answer lies in understanding the architectural decisions of that tool.
- felipellrocha 4y agoBecause there is no way this is true: > - no "unknown unknowns". it's so tired and true, there's no surprises
- Glyptodon 4y agoDid they get rid of the giant config file with all the interpreter options that can seem like they shouldn't exist? (I do like modern PHP well enough.)
- paulryanrogers 4y agoPHP.ini is alive and well. Some foot guns have been deprecated
- paxys 4y ago> - no "unknown unknowns". it's so tried-and-true, there's no surprises This part is laughable. People who have been programming PHP for 20 years (several of them at my company) still routinely discover hidden bugs, quirks or general behavior that is totally unintuitive and nowhere found in the documentation.
- johnisgood 4y agoPerhaps those people are stuck with PHP 5.
- merek 4y agoIn general, how could one know that something has no unknown unknowns? By definition, one wouldn't know.
- miffy900 4y agoThat's what makes the statement "no 'unknown unknowns'" a bit ridiculous though. How can you possibly assert that there are absolutely NO 'unknown unknowns'? You can never rule them out, and at best can only suspect there's a possibility either way, that they do or do not exist. You can never actually know with certainty.
- countvonbalzac 4y agoIs Hack better than PHP?
- nkozyra 4y agoIn 2022? Probably not. When it came out? Absolutely.
- jamesfinlayson 4y agoYeah there were a few years there where PHP frameworks were also adding Hack support... and then Hack started to diverge too much from PHP and now I don't think many (any?) PHP frameworks still support hack.
- zeroonetwothree 4y agoOnly if you are Facebook. Err I mean Meta.
- francislavoie 4y agoHack does have a lot of great features (some of which have already been ported to PHP, others are kinda impossible for technical reasons), but at this point, it's diverged so hard from PHP that they're separate languages. If you choose Hack, you lose the entire PHP ecosystem (composer) that could back you up and save you time. The only ones really using it are Facebook/Meta, so it would be a mistake to choose it for a new project, IMO. It doesn't really have a future.
- jrsj 4y agoI know Slack was using it at one point as well but I have no idea if they still are. That seemed to be as far as it got outside of Facebook though.
- soheil 4y ago> EDIT: why the downvotes? The anti-PHP cult is strong here on HN. List 5 benefits of React and watch your upvotes skyrocket.
- throwaway_4ever 4y agoReact gets an equivalent amount of disdain as PHP. Like 60% negative, 40% positive. (lots of preferences for server-side templating, htmx, Vue, Svelte, and Phoenix LiveView)
- fsdghrth3 4y agoReact is great. Vue is wannabe angular (not sure what version though was it 2, 3 or 4 now?) svelte is too busy shipping bugs to fix any and I don't even know what the others are.
- sidlls 4y agoWhat cult? PHP is technically, objectively inferior to almost every other web technology (which is impressive, actually, given how terrible most web technology actually is) in almost every use case one can think of. That doesn't mean it's bad or that nobody should ever use it, or that it isn't a superior solution in some cases. But in basically any non-trivial use case, it's a poor choice.
- hattmall 4y agoThat's not really true at all. PHP is like a Swiss army knife. It's not the very best at any one speciality. It is much better at many things than pretty much anything else though. You can use the Swiss army knife to put in screws, but a screwdriver is much better, but it's terrible at cutting zip ties.
- larve 4y agoThanks for commenting! I always have a hard time understanding what exactly is meant with comments like these. We can all agree that PHP has a wildly uneven standard library, had its fair share of security-relevant footguns, tends to have unexperienced developers. That's not extremely different from python and node.js, for example. The language significantly cleaned up its act, it has had classes, traits, closures, introspection, namespaces, packages for well over 10 years now, a robust third party library ecosystem and many successful projects to build upon (wordpress, drupal, woocommerce, phpbb, etc...). This makes it a pretty good choice for many applications. The stateless model and the resulting "no crazy stuff" approach makes it a much more reasonable choice for web development than say, python+django or ruby+rails to me. There's nothing I loathe more than trying to find which duck-typing, method-injecting package is causing a slow-burn memory leak in production. I also don't understand where the "most web technology is terrible" stance comes from. I find the quality of software engineering and the care put into developer UX and productivity in the web world quite inspiring. It has been a forcing function on all programmer tooling since the cambrian explosion in the earlier 2010s.
- wonderwonder 4y agoIts so easy to just get things done in php, even if its in an ugly way that you would never show to another developer. I built a saas for a fortune 1000 company after not programming for 5 years and never having done web development that ran several processes for them and they used it for a decade. It was the ugliest code in existence but it was so easy to just update and after it was up it just ran, forever. Deploying changes was just dragging over a file in Filezilla. Been thinking of building something new and considering learning node but PHP is right there. When I had to migrate to a new server I just copy - pasted the folders and away it went.
- zelphirkalt 4y ago> Deploying changes was just dragging over a file in Filezilla. Been thinking of building something new and considering learning node but PHP is right there. When I had to migrate to a new server I just copy - pasted the folders and away it went. These days most organizations will not tolerate just copying files over. There will be a process for testing the code and then stuff will probably be put in a container, to be even easier to run on another server. At that point the advantage of just sftp-ing files over disappears. It is no longer deemed safe enough to do so. Usually it is not the end of the world, if your website is down for a minute, but it does tarnish the public image of reliability, so organizations are not willing to put up with developers making a typo somewhere bringing down their website or causing at least an annoying error on the website. Instead of copying files over to another server, you would typically do some docker pull or other container engine pull some image or what have you. Then you would run that previously tested thing on the server.
- cutler 4y agoNot to meniton Kubernetes, AWS and Terraform. I don't think you really get PHP.
- larve 4y agoI think the point is that you can do both. Sometimes being able to yeet a PHP file to some PHP/wordpress hoster and get a project done in an afternoon is exactly what is needed, because even spending 2 or 3 days to set up a proper CI and deployment environment would be too much friction. There is a whole range of projects like that out in the wild, once you leave the realms of startups and big tech. It's about as easy to do "proper" deployment using bundles / containers / CICD / kubernetes / gitops with PHP as with any other stack. It's also possible to click a wordpress domain for $10/month and upload 2 php files and start making revenue. For a small business that is starting up, choosing between $10k of freelance work to get a nice github actions workflow on GKE + a monthly retainer of $2k for "maintenance" vs a one time $1k of freelance work to get a wordpress where you can configure the plugins and theme yourself is a no brainer. Many of those small business then grow much larger and reach a point where in hindsight you can say "should have gone with docker containers". But the original decision was not just perfectly valid, but probably the only reasonable one.
- miffy900 4y ago> - no "unknown unknowns". it's so tried-and-true, there's no surprises I've always been a fan of PHP too; it was my first programming language that I used to build a shipping application, but saying there are 'no unknown unknowns' in a language as quirky and old as PHP is akin to denying the sky is blue. PHP 4 + 5 had so many weird quirks, and they lasted a long time because PHP 7 took so long to ship (note there was no PHP 6). When 7 hit, they followed it up with many minor releases to try deprecating/removing/correcting some of those quirks, which itself introduced more unknowns when refactoring legacy code. Suddenly the quirks you were used to for so long were now gone or behaving differently (or more sensibly at least), but this required even more refactoring to account for. When a language is always changing or evolving you can never know in advance with certainty how new features or changes will change how existing code will work.
- pkrumins 4y agoI strictly use PHP5 with no updates as everything is well known and code I wrote in 2000 will work for decades. If it ain’t broke, don’t upgrade it!
- djbusby 4y agoAll the languages are changing: eg JS, Go stuff we did a few years ago don't work now. It's a not a situation unique to PHP.
- skrebbel 4y agoJS is famously backward compatible, what stuff are you referring to?
- pkrumins 4y agoAmen. You get it 100%. Come work for me!
- brightball 4y agoFirst 10 years of my career were heavy PHP. I’m solidly into Ruby and Elixir now, but I completely agree with you on the perks of PHP. People love to hate on it. https://www.brightball.com/articles/no-such-thing-as-real-programming https://www.brightball.com/articles/no-such-thing-as-real-pr... (Old article with a lot of dead links now, just FYI).
- brightball 4y agoReposting that made me realize I needed to fix my old URL redirect logic, so I did and the dead links work now.
- timack 4y agoNot sure about "no surprises" - just saw this on Twitter yesterday: https://twitter.com/LupinityLabs/status/1554217944179249153 https://twitter.com/LupinityLabs/status/1554217944179249153
- nyanpasu64 4y agoApparently exact minimal float-to-string conversion is more recent than I thought, and many languages used to print more (Python?) or less (PHP) decimal digits than necessary to uniquely identify the bit pattern. Python correctly prints 46000.80 + 553.04 as 46553.840000000004, but I don't know if it ever prints more digits than needed. One recent algorithm for printing floats exactly is https://github.com/ulfjack/ryu https://github.com/ulfjack/ryu, though I'm unaware what's the state-of-the-art (https://github.com/jk-jeon/dragonbox https://github.com/jk-jeon/dragonbox claims to be a benchmark and the best algorithm).
- deleted 4y ago[deleted]
- zeroonetwothree 4y agoThis is hardly specific to PHP. You should never compare IEEE floats using equality.
- unethical_ban 4y agoIsn't it the fault of the interpreter that it shows a rounded value without being promoted to?
- IshKebab 4y agoIt is absolutely the fault of PHP. You absolutely can compare IEEE floats using equality. Often it isn't what you want but this totally should work. In this case PHP is unexpectedly rounding floats for display. ~ python3 Python 3.9.13 (main, May 24 2022, 21:28:44) [Clang 13.0.0 (clang-1300.0.29.30)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> b = 46333.48000000001 >>> b 46333.48000000001 ~ php -a Interactive shell php > $b = 46333.48000000001; php > echo $b; 46333.48
- jader201 4y ago> why the downvotes? If you don't agree, just reply so we can have a healthy dialogue. I think downvote = disagree is expected. If someone thinks your comment is not making valid points, downvoting is a way to bury it below other comments. So that, naturally, the comments that the community most agrees with (in addition to adding quality content) bubbles to the top. https://news.ycombinator.com/item?id=658691 https://news.ycombinator.com/item?id=658691
- BFLpL0QNek 4y ago> it's stateless by design (much easier to scale) I noticed being stateless made it difficult to scale for any complex app. It’s been 7-10 years since I used it but Drupal used 60-128MB+ plus per request. As it was stateless it had to do a full bootstrap for every request coming in, set up a new database connection, module discovery etc, all which was heavy to do for every request. Most people scaled Drupal by putting Varnish in front preventing the origin from being hit so not really scaling Drupal as such, varnish is taking off some load where it can. Drupal is probably the extreme though. If you have a simple app with a few scripts, light use of a DB it’s not to bad. I’ve heard it’s come on a lot in the past 10 years and Laravel. I certainly had less issues using PHP than I do with JavaScript.
- dmitryminkovsky 4y agoHad same experience, had same thoughts. I bet I could make my way around the Drupal 7 bootstrap even these days, I looked at it so much... and so often thought... all this... every request?
- larve 4y agoYes, nothing comes for free. opcache, object cache + db pooling is something I always turn on. Then, for app performance: My approach is to usually design the app / refactor the app so static content can be fully cached. In ecommerce sites this can make an absolutely impressive difference. Then, leverage opcache and object cache and further separate cacheable path from dynamic path in dynamic SSR queries. Always drive using APM performance metrics as a guide. No need to optimize the DELETE /user endpoint called twice a week. Then, identify the heavy hitters in the dynamic DB queries, and basically write those in hand rolled SQL. It usually boils down to 4 or 5 queries doing 99% of the work (GET /posts, GET /categories, GET /products, etc...). I do this fairly late in the game, but think about it very hard up front. I like to use some kind of ORM for everything writing to the DB, and sql builders / pure SQL for reading. The split between cacheable / non-cacheable can be subtle depending on the application, and might require some non-obvious structures in the codebase. For real tricky performance issues (not something I had to do in PHP projects), I will either ducttape some AWS infrastructure or handroll a microservice in C++ or golang. This is something I had to do for realtime / transient loads.
- techsin101 4y ago- 9 ways to do same thing in PHP api - worst way to do templating - weird mental model of putting all logic and templating in one file
- Octoth0rpe 4y ago> weird mental model of putting all logic and templating in one file That's up to you though. You're welcome to put all your logic in one file and your templating in some other file.
- techsin101 4y agoI guess but that brings to next point, varying approaches to this problem in the wild, and since all are valid, codebases seem to have all of them.
- ipaddr 4y agoLike a react component?
- techsin101 4y agoi dont like react but even in react there is clear distinction, I've found tons of logic within templates of php like from <?php to ?>.. anything at anytime could cause anything. Kinda gives me global variable vibes
- bigtunacan 4y agoThat's an issue of design. You can't really blame the language for bad programming practices
- lmm 4y agoYou absolutely can and should. The language is responsible for the programming practices it promotes.
- jimbokun 4y agoI’ve always wondered why the more respectable dynamic languages, like Ruby and Python, don’t have a web framework with the PHP deployment model of “just upload this file to the server and refresh your browser to see changes.”
- larve 4y agoI really like the vercel and co approach to the dev cycle. It's as easy as (if not easier) PHP and you get a huge boost of monitoring / infra tools for a minor cost. I think we are seeing a lot of the "yeet and get shit done" approach with vercel and netlify that we used to with PHP.
- bigtunacan 4y agoI would say security by default is a good reason to not have this. I've been burned too many times on PHP projects because someone miss-configured an httpd conf file.
- kyriakos 4y agoFrom all the potential web security issues someone can have that one is probably the easiest and most likely you will get right.
- bigtunacan 4y agoThe whole reason for the principle, "Secure by default" is because someone is going to fuck up.
- Izkata 4y agoPython has had cgi forever: https://docs.python.org/3/library/cgi.html https://docs.python.org/3/library/cgi.html
- Blackthorn 4y agoThey do. It's just that everyone seems to have collectively decided that cgi shouldn't be used anymore.
- labrador 4y ago> I feel like PHP documentation is very undervalued PHP is documentation done right because of the comments, essentially "Stack Overflow" for PHP before stackoverflow.com was a thing. I've found an example of documentation done wrong recently with Microsoft .NET 6.0. Apparently, Microsoft has decided that code samples are no longer important
- psalminen 4y agoI've been migrating to Azure and their SDK documentation is next to nonexistent. The codebase is also uncommented and inconsistent. It's just been a dumpster fire.
- kyriakos 4y agoMicrosofts documentation is horrible. They churn out api after api and never document it correctly.
- wiennat 4y agoWhat's happen to MS these days? I remember the documents during .NET 2.x days were very good, well-organized and useful.
- djxfade 4y agoThis can go both ways. I have seen some very dangerous code examples in the comment section of the PHP docs.
- labrador 4y agoUsually followed by a comment that says don't do what the last comment said
- zelphirkalt 4y ago> PHP is documentation done right because of the comments, essentially "Stack Overflow" for PHP before stackoverflow.com was a thing. It's funny really, for a programming language to rely on comments made by random people, instead of having those aspects covered in the documentation itself. Shows a bit of lack of care. It seems half-assed as many things in the ecosystem seem. What happens, if they ever lose that database of comments? The whole world scratches their heads wondering how to use standard library functions? Ridiculous. I hope they have good backups. > I've found an example of documentation done wrong recently with Microsoft .NET 6.0. Apparently, Microsoft has decided that code samples are no longer important And for as long as important documentation resides in comments in PHP docs, the same can happen to PHP docs. Lets say they push out PHP 9 and some things change. Someone thinks "Ah those comments are not actually true any longer. Lets get rid of them." Bam, massive resource lost, because the knowledge has not been integrated into the documentation.
- rsch 4y agoAh I remember the experience of just dropping files on a server from a long time ago. I had one web host where magic_quotes_gpc was enabled. Good luck figuring out what the hell is going on with all these extra quotes in your variables. And I kept looking up how to do prepared SQL statements in PHP, finding the mysqli functions, and then eventually figuring out that mysqli wasn’t available on your average web host with PHP back then. (Yes it was that long ago. I also think a lot of the hate comes from that era) I remember the documentation as well, with usually all the gotchas in the comments. Which is great, but there were a lot of gotchas. like, A LOT.
- coding123 4y agoI won't downvote you, I think it's kinda crappy when people just do that without explaining. Also an opinion isn't something we shouldn't downvote, we should downvote poor responses. In any case, I definitely agree with all those pros. What I dislike about PHP is that as you start growing a codebase, especially with includes, your attack surface just grows and grows and grows. In other frameworks where a stack is involved attack surface generally grows as well, but since any PHP script has access to the request, it's much much worse.
- baryphonic 4y ago> PHP has so many hidden benefits: > - it's stateless by design (much easier to scale) I'll grant you this one. Though PHP in practice goes to great lengths to add state back in for performance reasons (e.g. memcached, or for a while APC). And Haskell is stateless, too, yet not a frequent choice for web work. > - it was "serverless" before Serverless This is retconning. It was never trivial to set up a LAMP stack, especially at scale. I can't tell you how many times I've seen the PHP "too many open database connections" error because someone just treated their Wordpress blog as "serverless" and it went to the top of HN. > - surprisingly performant I can't speak about the latest stuff, but PHP5 in ~2014-15 was abominably slow. There were certain "benchmarks" which indicated it was fast, but on closer inspection, these were simply calls where PHP provided thin wrappers around C calls. I had to once take an Excel file, parse it and then present certain fields to the user for the DB to be updated. This was possible in PHP, but it took excruciatingly long (like 8 minutes - in fact, sometimes Apache would just drop the connection), and third party library support was just awful. I implemented the same task in Python, and not only was the code much simpler and and easier to write, but the task took a second or two each time. > - no "unknown unknowns". it's so tried-and-true, there's no surprises The standard library is a toxic sludge of surprises. Nothing is consistent. "Will this function treat an array like a list or a dict? Who knows?" Maybe this is better now, but the last time I dabbled in PHP, I spent a while trying to get a workable debugger set up and gave up. Stepping through code is apparently impossible, and every now and then you hit some fatal error that immediately crashes your code. > - deployment is so simple, just drop a file on a web server. No middleware needed. What does this mean? First, PHP has middleware (e.g. memcached, Apache/Nginx). Second, the complexity of deploying a Python, Node, Rust, Go or Ruby application is not the "middleware." The complexity is ensuring that the update is correct, the update is applied consistently, can be rolled back, doesn't cause downtime, etc. I could also do updates by running webpack dev server in prod and dropping files in there for deployment. As easy as PHP, yet a terrible idea. > - No long compile times because there is no compiling needed. This is odd to say the least. PHP's biggest weakness IMO is that each thread must entirely parse and interpret its executing program on every single call. That is a ton of wasted work, and there are literally sections in the PHP docs about tools to circumvent this problem.[0] And the solutions involve caching, which mean we give up (1) the "stateless" benefit and (2) the "just drop in a file" benefit, or else we need to add a bunch of cache coherence logic. It would be so much easier if someone could compile the PHP code to a bytecode format and drop _that_ in, which could just start executing on an interpreter ASAP. Ultimately, I think the list is getting downvoted because it deviates so much from developers' experience with PHP. PHP started out as a sub-Turing templating tool that had a Perlish language bolted on, which then mutated to look a lot like Java. Eevee's classic blog rant[1] calls it a "fractal of bad design," but the reality is PHP has no design: it's just a kludge of duct tape and bolts. Also, maybe this is totally incorrect now with PHP6--er PHP7 and PHP8. But my experience with PHP4 and PHP5 was so horrific that I will not be working with it again. I've yet to find a PHP use case that is not better solved with a combination of a static site generator and something like AWS Lambdas or Cloudflare Workers. [0] https://www.php.net/manual/en/book.opcache.php https://www.php.net/manual/en/book.opcache.php [1] https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
- oxff 4y agoPHP documentation is one of the worst things I've ever seen. That people subject themselves to abuse such as "reading it" is comical to me. Enjoy scrolling down 15 years of comments to get the quick rundown.
- conradfr 4y agoThe documentation is good because it usually shows examples for all parameters types, something I miss regularly in the Elixir docs for example. I agree that the comments should be removed or at least hidden by default as they're usually not relevant anymore.
- sfmike 4y agoagreed reminds me of nomadlist and the sort of php philosophy of I wanted some function so with 1 php flat file I made a sort of website with app like behavior. If anything is this not programming to the masses? PHP PHP! :p
- deleted 4y ago[deleted]
- onion2k 4y ago- it's stateless by design (much easier to scale) That's sort of true, but the default state mechanism (session files) doesn't scale well, or even work across load balancers that don't maintain server affinity for each client. Scaling a PHP app isn't hard, but it can be non-trivial if you've written the code without considering scaling. Other serverside scripting languages (Python, Ruby with Rails) nudge you in the right direction in ways that PHP doesn't.
- heurisko 4y agoIt's trivial to configure PHP to store sessions in redis.
- deleted 4y ago[deleted]
- KronisLV 4y ago> EDIT2: I also think there is something unique about PHP documentation. It has plenty of real life examples, and the ability for users to leave comments allows you to hear directly from others "gotchas" that people have experienced. I feel like PHP documentation is very undervalued. This is perhaps one of the better things about it! It feels like lots of different languages and frameworks would benefit from comments at the bottom of the page, from the community, explaining various common use cases and gotchas. Somehow it feels like docs being on GitHub with people being able to contribute to them there somehow can have higher friction, versus a forum-like system.
- gbuk2013 4y agoBack in the day when I wrote PHP code it was not pleasant to work with UTF-8 - is it better now?
- anony999 4y agoHave you tried a more "modern" language recently? By trying I mean using it for more than 6-10 months. I've been one of the PHP "supporters" until I've found Go and Rust. PHP was really nice to get into programming and make a spaghetti website but the language itself and the ecosystem always felt like a hacking project. The killer feature of PHP has always been the hosting ecosystem. A simple FTP upload would do the job without knowing much about the hosting infrastructure. Recently we've got that kind of "serveless" experience for other languages as well but the deploying is proprietary and the providers are very few. I'm aware only of Google Cloud Run. As for JavaScript even its inventor said it's time to move on. It's time for a new language and a new DOM interface. Maybe we can fix the "language" issue with WASM but we are still left with the DOM.
- rr888 4y ago> JavaScript even its inventor said it's time to move on. I hadn't seen that quote, do you have a link?
- cutler 4y ago> PHP was really nice to get into programming and make a spaghetti website Facebook manages quite well with PHP. Maybe it's your fault you didn't learn how to use modern PHP practices which have been well-documented for over a decade now.
- artificialLimbs 4y ago
- zelphirkalt 4y ago> - it's stateless by design (much easier to scale) "By design" PHP encourages very very stateful procedural programming. It is one of the languages, where making things not mutate state seems like a mostly unused strategy. The amount of beginner code people find online and that mindset of "if it works it works shrug" continues to keep bad code alive. The thing that might be referred to here by "stateless" is that a PHP "application" runs the code from top to bottom, as if all was one long script. This primitive handling has its own issues of course, but I will admit, that sometimes it is useful, that you can change the code and do not need to restart PHP or anything, because you will get the new script executed when the next request comes in. > - it was "serverless" before Serverless Where "serverless" is just a buzzword. PHP runs on a server just like many other languages. You will need a machine acting as a server, you will need PHP installed, you will need some webserver, usually something like Apache or NGINX with fpm or some other shenanigan. Nothing really special there. > - surprisingly performant Which in part, I would claim, is due to its reckless way of handling types, introducing hidden bugs. The type system is quite underdeveloped and cannot give many guarantees. No generics, no general object type, which everything inherits from, but only an object type, which not every other object inherits from. Then that "mixed" type, which just makes things even more fuzzy in a signature of a procedure and encourages bad design again. Of course, if you throw all safety overboard, then you can get a bit more speed. Not really impressive. > - no "unknown unknowns". it's so tried-and-true, there's no surprises I just recently looked at defining constants in PHP. But I could not see in the docs, what the scope of a constant is. Simply not to be found. I just had to try it and hope. This is often the case with PHP and its half-baked docs. > - deployment is so simple, just drop a file on a web server. No middleware needed. But the webserver is the middleware you need. Like mentioned above, some Apache you need to configure, or some NGINX, or some other server. Maybe you have only ever deployed on managed infrastructure and never done the actual full deployment? Always enjoyed other people setting things up for you? I guess this is true for most of the people claiming, that PHP deployment is simpler than in other languages. > - No long compile times because there is no compiling needed. That again comes at the cost of safety. PHP types if you declare them in the code are not checked at compile time, but only when the code runs, making them merely annotations to read for another person. In the PHP world we have learned not much from the past decades of programming language design. It is understandable. Lots of people have build tons of almost breaking things on top of PHP's design flaws and would start a riot, if things ever changed. For the sake of backwards compatibility PHP will remain in its swamp of bad design choices. Sure, people can try to build on top of that, abstracting from it all through more modern web frameworks, plastering over all of the flaws. Sooner or later though, you will need to use some actual PHP code in there somewhere and the bad design will rear its head again.
- dbbk 4y agoI agree. I started learning PHP in 2006, and though obviously it's advanced enormously since then, I did wonder if I should switch to more 'modern' options. In particular I tried to switch to Node a few times. But I just found myself feeling like I was missing out on benefits from PHP and not really gaining anything new (particularly, like you say, stateless requests just makes logical sense). I do think people who react so viscerally negative to it in 2022 are only doing so from an old preconception and not judging it for what it is today. I build seriously large and complex applications and never once have I felt that I was fighting PHP or it was holding me back. I don't really get the hate.
- bearmode 4y agoModern PHP with a framework like Laravel is honestly a joy to work with.
- Tainnor 4y ago> - No long compile times because there is no compiling needed. I respect that some people accept dynamic typing as a better tradeoff for various reasons (I've worked with Ruby for many years before I discovered my love for type systems), but to me that statement reads similar to: "No long CI builds because we skip all the tests." :)
- artificialLimbs 4y agohttps://www.php.net/manual/en/language.types.declarations.php#language.types.declarations.strict https://www.php.net/manual/en/language.types.declarations.ph...
- Tainnor 4y agoThat's runtime type checking, which is a completely different thing and doesn't fit the analogy. Runtime type checking helps you fail fast, which hopefully prevents undefined behaviour and data corruption, and can help with fault localisation (some hardcore type theorists would even argue that runtime types aren't really "types" per se, but more like tags). Compile-time type checking is a soundness proof of your program, which is an entirely different thing.
- ChrisMarshallNY 4y agoDISCLAIMER: I am not actually a "backend" developer (although I have written some pretty big backends). I am not a JS fan. This is not because I have anything against the language; it's just that I have no real need for it, and have treated it as a "necessary evil," in my frontend work, so I don't believe that I have much of a platform to lob spitballs at it. PHP, on the other hand, is a language that I have used for over 20 years. I think it was 3 or 4, when I started. If I do backend work, these days, I'll be doing so, in PHP. I always like looking at the "fishtank graph"[0]. That sort of puts things in perspective. [0] https://w3techs.com/technologies/history_overview/programming_language/ms/y https://w3techs.com/technologies/history_overview/programmin...
- ksec 4y agoI only wish PHP has a cousin with modern syntax.
- cm2187 4y agoThe issue I have with php, having started building websites in the early 2000s with it, is that it is a language that doesn’t push you to write better code and progress. I am much more of a fan of static langages where the IDE guides you a lot more, gives you live feedback so that being curious is cheap, you don’t have to dive into some documentation to know what the other methods, parameters and overloads are, you can refactor code safely and effortlessly. So I am sure some professionals write brillant code in php, particularly in large organisations, but my guess is that the median code base quality out there is probably pretty lousy. Anything below the 80th percentile probably too. Also it’s for websites only.
- larve 4y agoI think PHPStorm has been very helpful as an IDE for over a decade. One of the things I do like about PHP is that while most legacy codebases out there are lousy (even when good developers are involved), and often lousy for totally legitimate reasons, PHP with its "don't even try to do clever" approach makes many things easier. Of course, I only dealt with so many legacy applications. My worst experiences have always been with python legacy code because there were strata of conflicting "better code" approaches piled on top of each other. Once you start abstracting into patterns, and you don't have the experience needed to get a sense of good architecture, it's easy to make a real tangled mess.
- ChrisMarshallNY 4y ago> I also think there is something unique about PHP documentation. It has plenty of real life examples, and the ability for users to leave comments allows you to hear directly from others "gotchas" that people have experienced. I feel like PHP documentation is very undervalued. I think it's the best documentation out there, and that part of the reason it's easy to document, is because the language uses a standard library, and functions, as opposed to the structure of the language, itself, to provide most of the utility. Functions are easy to document. They do a good job of "cleaning out the cruft," as well, so that there isn't much in the way of "no longer applies" stuff. Part of it, too, is that the language probably supports stuff all the way back to 4. They tend not to deprecate, and accrete, instead (not always a good thing). That means that examples and discussions maintain relevance, even years later. One of the biggest issues that people tend to have with PHP, is that it allows you to write bad code. I came from a C++ shop (another language that people love to hate). If you think you can write bad code in PHP, C++ says "Hold my beer." I am a big believer in Discipline. With Discipline, we can write excellent, maintainable, code in any language. I have written stuff in Assembly, FORTRAN, Pascal, PL/1, Perl, Bash, BASIC, C, C++, ObjC, and Swift, that is quite well-structured, maintainable, and well-documented.
- cztomsik 4y agothen take my upvote, I agree 100%, I'm saying exactly this to many people and they just roll their eyes (to be fair I don't use PHP anymore but I certainly don't share the despect which others have) fun thing I also wanted to add a point about documentation but you did it yourself, life is fun sometimes :)