PHP in 2022(stitcher.io)
stitcher.io
PHP in 2022
https://stitcher.io/blog/php-in-2022
317 comments
I learned to use php when I was like 14. I’m 27 now and still derive such joy when making my own little projects that will never see the light of day. I try to be humble as far as just being a php trash coder, but I don’t feel too ashamed honestly, as it is the most mainstream thing really. I will always be grateful to php for being accessible and yeah, I guess easy. I don’t know why php is the only one I really stuck with exactly, but it is weirdly dear to me. Nearly half my life I’ve never gone too far past being a lowly php coder, and not a great one at that, but I still like what I can make at the end of the day. It’s a side creative thing for me. Laravel was a revelation for me over the last few years, it just makes some things make sense that never did for me as a self-taught hobbyist.
In a world where everything is fast becoming a JavaScript front end with “some” backend and with the improvements PHP has seen in recent years I don’t see why you’d consider yourself a “lowly” php developer.
I’m mainly a C# guy myself as far as the backend goes, but I don’t view PHP as being bad in 2022. I think people who do are stuck in the past to be perfectly honest.
It’s sort of like disliking JavaScript because it really sucked the soul out of you before typescript eventually made it nice to work with.
But being mad at any programming language is sort of silly isn’t it? If it works it works.
I’m mainly a C# guy myself as far as the backend goes, but I don’t view PHP as being bad in 2022. I think people who do are stuck in the past to be perfectly honest.
It’s sort of like disliking JavaScript because it really sucked the soul out of you before typescript eventually made it nice to work with.
But being mad at any programming language is sort of silly isn’t it? If it works it works.
> why you’d consider yourself a “lowly” php developer.
PHP has always been considered as a somehow bad language in all corporations I've worked at to date. The same applies to other script languages such as python, ruby or nodejs - but PHP was the most undervalued of them all.
It's kinda strange because the language is really performant and relatively easy to use.
Maybe that's exactly why the big brain architects don't like it. They do tend to love things correlated with pointless complexity after all
PHP has always been considered as a somehow bad language in all corporations I've worked at to date. The same applies to other script languages such as python, ruby or nodejs - but PHP was the most undervalued of them all.
It's kinda strange because the language is really performant and relatively easy to use.
Maybe that's exactly why the big brain architects don't like it. They do tend to love things correlated with pointless complexity after all
People dislike PHP because its standard library had many inconsistencies and interesting design decision that no sane programmer would ever even think off, like all random numbers being odd (https://stackoverflow.com/questions/31612082/why-does-mt-ran...).
Many of these decisions revolve around the authors not wanting their functions to fail under any circumstances. This is nice for beginners but quickly hurts more than it helps in larger projects as it obfuscates bugs.
Many of these decisions revolve around the authors not wanting their functions to fail under any circumstances. This is nice for beginners but quickly hurts more than it helps in larger projects as it obfuscates bugs.
Let me preface this by saying that I pass zero judgment to any people who use PHP by choice or otherwise, and that I don't assume I'm "better" or smarter than anyone else for their programming tool choice.
But, if you genuinely want to know why some of us hate on PHP, I can tell you the reasons that I would never choose PHP for a production backend (now, I do think PHP is a fantastic scripting/sysadmin language- better than Python for sure, but I don't know Perl well enough to judge against that).
PHP is single-threaded. I feel like that's a pretty decent reason all by itself to not want to use it in an enterprise environment.
PHP is not really async, either. Yes, there are are run-loop libraries, and some libraries even claim to be async all by themselves, but these solutions are awkward and cumbersome and easy to use incorrectly.
PHP's array data type is ridiculously bad. In every conceivable way. If you want to use it as a contiguous, linear, collection, then it's slow and bug-prone (e.g., using array_filter, but forgetting to wrap it in array_values). If you want to use it as a dictionary, then it will sneakily convert your keys into numbers which doesn't matter until it does (like when trying to operate over filenames in a directory and someone named a file "1". Then you try to do some operation that expects a string and your code explodes several hours into its operation... Ask me how I know).
PHP's iterators and other, more professional-grade, data structures are not as "first class" as plain-old array, so nobody uses them. IIRC (it's been a while), you theoretically need to enable them in your php.ini and/or install them at the OS level, which kind of kills the whole "PHP is so easy to deploy! Just FTP a file and you're done!"-thing.
I prefer static typing to dynamic typing. PHP's static typing is weak (as in not strict enough) and not expressive enough for me (no generics, no sum types, no extending classes/types).
PHP does not allow for custom equality definitions. Also, since everything is references, I believe you can blow the stack if you try to check that two objects are equal that reference each other.
The architecture of every HTTP request getting a fresh instance of PHP is actually pretty nice. And a ton of work has been put into the language/runtime to make sure it's stupid-fast at ramping up and parsing the request data. HOWEVER, as soon as you slap one of these popular frameworks (Laravel, Symfony, etc) on top, you've basically ruined it and made it slow, with all of the extra framework initialization junk. I remember seeing engineering effort go into "compiling" Symfony code to make it load quickly (I don't remember how Laravel works). But think about that for a second- we're going to choose an interpreted language that can't cache any state beyond a single request, and we're going to add a COMPILE STEP to it?! So that we can work against the init-process-teardown cycle that it's designed for? Are we really sure we actually wanted to use PHP?
I used to have more specific complaints about strings and the numeric types, etc, but it's been a little while since I've had to write any PHP (I haven't used version 8, but I was using 7.4, I think, so I'm still fairly immune to the "You only remember PHP before it became awesome in 7+." criticism).
I'm more than sure that any regular PHP dev has no problem dismissing all of my complaints. Just like when I went to the doctor and told him my elbow hurts when I bend my arm. He told me to stop bending my arm! Problem solved. ;)
But, if you genuinely want to know why some of us hate on PHP, I can tell you the reasons that I would never choose PHP for a production backend (now, I do think PHP is a fantastic scripting/sysadmin language- better than Python for sure, but I don't know Perl well enough to judge against that).
PHP is single-threaded. I feel like that's a pretty decent reason all by itself to not want to use it in an enterprise environment.
PHP is not really async, either. Yes, there are are run-loop libraries, and some libraries even claim to be async all by themselves, but these solutions are awkward and cumbersome and easy to use incorrectly.
PHP's array data type is ridiculously bad. In every conceivable way. If you want to use it as a contiguous, linear, collection, then it's slow and bug-prone (e.g., using array_filter, but forgetting to wrap it in array_values). If you want to use it as a dictionary, then it will sneakily convert your keys into numbers which doesn't matter until it does (like when trying to operate over filenames in a directory and someone named a file "1". Then you try to do some operation that expects a string and your code explodes several hours into its operation... Ask me how I know).
PHP's iterators and other, more professional-grade, data structures are not as "first class" as plain-old array, so nobody uses them. IIRC (it's been a while), you theoretically need to enable them in your php.ini and/or install them at the OS level, which kind of kills the whole "PHP is so easy to deploy! Just FTP a file and you're done!"-thing.
I prefer static typing to dynamic typing. PHP's static typing is weak (as in not strict enough) and not expressive enough for me (no generics, no sum types, no extending classes/types).
PHP does not allow for custom equality definitions. Also, since everything is references, I believe you can blow the stack if you try to check that two objects are equal that reference each other.
The architecture of every HTTP request getting a fresh instance of PHP is actually pretty nice. And a ton of work has been put into the language/runtime to make sure it's stupid-fast at ramping up and parsing the request data. HOWEVER, as soon as you slap one of these popular frameworks (Laravel, Symfony, etc) on top, you've basically ruined it and made it slow, with all of the extra framework initialization junk. I remember seeing engineering effort go into "compiling" Symfony code to make it load quickly (I don't remember how Laravel works). But think about that for a second- we're going to choose an interpreted language that can't cache any state beyond a single request, and we're going to add a COMPILE STEP to it?! So that we can work against the init-process-teardown cycle that it's designed for? Are we really sure we actually wanted to use PHP?
I used to have more specific complaints about strings and the numeric types, etc, but it's been a little while since I've had to write any PHP (I haven't used version 8, but I was using 7.4, I think, so I'm still fairly immune to the "You only remember PHP before it became awesome in 7+." criticism).
I'm more than sure that any regular PHP dev has no problem dismissing all of my complaints. Just like when I went to the doctor and told him my elbow hurts when I bend my arm. He told me to stop bending my arm! Problem solved. ;)
There’s a lot of debate about this kind of stuff on the internals mailing list. In fact, the array string to number thing was just recently discussed and why it is the way it is[0]. It would take an entirely new type to support keeping it as a string.
0: https://marc.info/?l=php-internals&m=164155164316739&w=2
0: https://marc.info/?l=php-internals&m=164155164316739&w=2
I think unambiguously janky design choices like this[1] in PHP's early history is what's given it such a bad reputation, while it might be a decent language now such a reputation is hard to shake. I'll be honest the only time I'd reach for PHP over a comparable language with a less chequered history like Python is if I was dealing with a project that was already closely tied up in the PHP ecosystem.
[1] https://www.i-programmer.info/news/98-languages/6758-the-rea...
[1] https://www.i-programmer.info/news/98-languages/6758-the-rea...
Unfortunately the bad design choices from the past are mostly here to stay - I mean, when you have the thing you want to find (the "needle") as the first parameter in about half of your "find something in something else"-type functions and the "haystack" as the first parameter in the other half, are you really going to break backward compatibility just to make things consistent? Of course not! So PHP will never be my favourite language (although I work with it every day), but it gets the job done, so...
Since you mentioned Python: I would never think of using Python instead of PHP, at least not for a web-based project. Performance-wise PHP is (I think) better thanks to all the work Facebook sponsored, and it has all the "batteries" needed for web development included, so the only reason for choosing Python would be that it's maybe more "elegant".
Since you mentioned Python: I would never think of using Python instead of PHP, at least not for a web-based project. Performance-wise PHP is (I think) better thanks to all the work Facebook sponsored, and it has all the "batteries" needed for web development included, so the only reason for choosing Python would be that it's maybe more "elegant".
Clarification: While Facebook sponsored a lot of work it was on their competing HHVM system, which spured other contributors that competed with HHVM (Zend mostly) to invest more in PHP and develop the performance improvements in PHP 7 and 8.
The performance improvements where not directly sponsored by Facebook.
The performance improvements where not directly sponsored by Facebook.
Yeah most of the PHP hate came from old school PHP 3 code co-mingled with HTML 2/3 that didn't take advantages of the simple OOP added. PHP 4 took decent steps but couldn't shake that stigmata. PHP 5 and some good MVC frameworks (written in 4 and 5) made great advances and 7/8 and the spinoffs make the language pretty good for any scripting or web job. These days I prefer JVM based languages but if I needed a quick web task with minimal overhead PHP would still be in the top 3 options.
But some old timers (genX) still today bemoan php as if it had no progress made.
But some old timers (genX) still today bemoan php as if it had no progress made.
Yes, sorry, I don't mean to make out php as this scrappy underdog or that we are under constant attack or anything... I see it more like, ummm, a pumpkin spice latte of languages, something viewed as a lesser choice because or in spite of its popularity? There are all these other amazing options, why pick this? Of course, with programming languages, you have many objective criteria where a coffee drink is totally subjective. Languages are also a huge investment time-wise instead of being able to try different flavors each day. Not a perfect analogy, but maybe you still see a little what I was going for as far as lighthearted stigma. PHP is and has been doing so well for so long, but I couldn't argue a huge case for it personally besides... it was there. It clicked at the time. I grew up with it.
I am balancing my love for it with the public perception I have seen over the years (fortunately I think much of the vitriol has waned sorta), in terms of how bashful I feel whenever discussing anything coding-related as to not overstate what I know/do. Most people, I think, grow out of php, so I see myself as a bad stereotype in still using it. But it has done a lot for me in terms of confidence building, being able to make things, the creative process of turning nothing into something, even though admittedly if I'd picked a different language I could likely say the same. But as far as staying with it, I feel like I look lazy for it, it just does what I want it to do. I am grateful for it. I hope this made sense.
I am balancing my love for it with the public perception I have seen over the years (fortunately I think much of the vitriol has waned sorta), in terms of how bashful I feel whenever discussing anything coding-related as to not overstate what I know/do. Most people, I think, grow out of php, so I see myself as a bad stereotype in still using it. But it has done a lot for me in terms of confidence building, being able to make things, the creative process of turning nothing into something, even though admittedly if I'd picked a different language I could likely say the same. But as far as staying with it, I feel like I look lazy for it, it just does what I want it to do. I am grateful for it. I hope this made sense.
> I think people who do are stuck in the past to be perfectly honest.
I've recently tried to help out a friend who got stuck with a half-finished PHP project and a deadline to deliver, I have not touched PHP in 10 years and it still has the stench of a bad language from the get go - "modules" requiring VM config, "include" files ... what is this 90s ?
PHP might have had a huge patchwork competent people did to keep things working once projects using it grew enough, but coming back to it after 10 years it still felt like it was built on a foundation of shit.
I've recently tried to help out a friend who got stuck with a half-finished PHP project and a deadline to deliver, I have not touched PHP in 10 years and it still has the stench of a bad language from the get go - "modules" requiring VM config, "include" files ... what is this 90s ?
PHP might have had a huge patchwork competent people did to keep things working once projects using it grew enough, but coming back to it after 10 years it still felt like it was built on a foundation of shit.
I think the criticism hurled at PHP is misplaced. It serves the niche it was designed for very well. As long as you have namespaces, the include files should not be a problem for you. You can design a class loader and use that. The only thing you need to tell php.ini is an include path and then rest of the configuration is app dependent, like it is for any platform. Where do you find VM config for modules?
Also, any language that is used in real life is built on a foundation of sh*t only. The component loading with python is so bad that I have programs keeping their own version of python and IDE suggesting I create VM for my project. The situation with C is so bad that no one can solve my linker problems unless I switch the toolchain version. For a long time Javascript was a (purpose built) toy language to sprinkle pixie dust on web pages. Any sufficiently complex problem requires either deep knowledge or following convention (tribal knowledge specific to the context)
Also, any language that is used in real life is built on a foundation of sh*t only. The component loading with python is so bad that I have programs keeping their own version of python and IDE suggesting I create VM for my project. The situation with C is so bad that no one can solve my linker problems unless I switch the toolchain version. For a long time Javascript was a (purpose built) toy language to sprinkle pixie dust on web pages. Any sufficiently complex problem requires either deep knowledge or following convention (tribal knowledge specific to the context)
well to be fair, any user is quite capable of building a pile of shit using any language, and if you were mucking with include statements manually it sounds like that's likely what was going on
The reason for PHP's hate is detailed in this great vintage article: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
That's from 2012 and many of the issues have been fixed since then, but it was the truth a decade ago and tainted the experience for many devs who have sine moved on to other languages.
That's from 2012 and many of the issues have been fixed since then, but it was the truth a decade ago and tainted the experience for many devs who have sine moved on to other languages.
I'm one of those web devs that tries everything under the sun, and I also happen to have worked for a lot of companies (more than a dozen already, I'm on my 40s).
Laravel is such a *joy*. I've never had this feeling of using something so easy and productive. I've been recently building a side project with LiveWire and oh-my-god. I really wish I had discovered it before. From the templating system (you get components out of the box! no more "includes" if you don't want to) to the validations, to the queues system... everything is so well integrated and so easy to use.
For the last decade I've worked mostly with Django and SPAs, I'm not going back to that any time soon. Django templates are extremely limited for nowadays requirements, and SPAs are 1000x more complex to build and maintain so in my opinion they're not worth the price/effort. I think Livewire, Hotwire, Unpoly, Htmx, etc are what 90% of web apps need.
Laravel is such a *joy*. I've never had this feeling of using something so easy and productive. I've been recently building a side project with LiveWire and oh-my-god. I really wish I had discovered it before. From the templating system (you get components out of the box! no more "includes" if you don't want to) to the validations, to the queues system... everything is so well integrated and so easy to use.
For the last decade I've worked mostly with Django and SPAs, I'm not going back to that any time soon. Django templates are extremely limited for nowadays requirements, and SPAs are 1000x more complex to build and maintain so in my opinion they're not worth the price/effort. I think Livewire, Hotwire, Unpoly, Htmx, etc are what 90% of web apps need.
Laravel and Livewire is the best-kept secret ever because everybody is too busy being biased against PHP.
Php/Laravel/Livewire == Elixir/Phoenix/LiveView == C#/.NET/Blazor == Ruby/Rails/Hotwire/Turbo
It's also slowly being integrated into JS frameworks although they're still behind as the focus has been clientside and static generation so far.
It's also slowly being integrated into JS frameworks although they're still behind as the focus has been clientside and static generation so far.
== Everything else/HTMX. Well currently HTMX is still a "low level" clientside library, but in a similar vein to Ruby/Rails/Hotwire/Turbo.
Feels like BE-first dev and non-SPA/JS centric client webdev is slowly regaining ground. Exciting.
Feels like BE-first dev and non-SPA/JS centric client webdev is slowly regaining ground. Exciting.
I've found Unpoly to be a nice middleground between those framework specific solutions and htmx
Or we're too busy using Phoenix LiveView ;P
One of the companies I worked for used Elixir/Phoenix. It is an extremely cool piece of tech but it is nowhere near as productive as Laravel, Rails, etc. Missing libraries, difficult to hire for, bad editor support, and overall feels very niche which such a small community. That company eventually moved out of it.
Hey, that's why we need more people! It's getting better and better all the time. And nothing really beats its ease at making conncurent web apps. But yes, if you're an IDE person, you're going to have a bad time and that is not likely to chnage any time soon (I don't think?)
Or Rails/Hotwire.
I like Laravel, but i don't like Livewire that much. Livewire is really neat when building simple interactive stuff, but when building larger more dynamic parts it gets pretty sluggish and the livewire component codebase starts to feel harder to maintain.
Last time I tried to use Livewire with Vue, it had some issues which caused Vue to lose reactivity. (Maybe Livewire removed the DOM where the Vue instance was rendered. There was some options that prevented livewire from replacing elements with given id/classname.) But if i remember correctly, you cant have livewire element which has vue components as child elements.
Maybe i was doing stuff wrong or the livewire<->Vue compatibility is a bit better nowadays. Or maybe its because I'm too used to Vue.
It felt like the Laravel community jumped to the Livewire hypetrain quite fast and it feels like the livewire recommendation to use alpinejs in someparts is required. And most of the examples for alpinejs requires you to write inline code. (It is possible to split the code to own js files, but then again you are building something that gets closer to Vuejs.)
It feels weird to recommend to write scripts using inline javascript. That requires more CSP modifications for security and also the scripts wont get cached and are loaded every time the page loads. (If I'm correct.)
TL;DR Livewire is great for small features.
Last time I tried to use Livewire with Vue, it had some issues which caused Vue to lose reactivity. (Maybe Livewire removed the DOM where the Vue instance was rendered. There was some options that prevented livewire from replacing elements with given id/classname.) But if i remember correctly, you cant have livewire element which has vue components as child elements.
Maybe i was doing stuff wrong or the livewire<->Vue compatibility is a bit better nowadays. Or maybe its because I'm too used to Vue.
It felt like the Laravel community jumped to the Livewire hypetrain quite fast and it feels like the livewire recommendation to use alpinejs in someparts is required. And most of the examples for alpinejs requires you to write inline code. (It is possible to split the code to own js files, but then again you are building something that gets closer to Vuejs.)
It feels weird to recommend to write scripts using inline javascript. That requires more CSP modifications for security and also the scripts wont get cached and are loaded every time the page loads. (If I'm correct.)
TL;DR Livewire is great for small features.
I think livewire works better with Alpine. Also, I think Livewire is great for interactions that require a backend request (such as posting a comment, refreshing some data, etc). If an interaction can be performed without reaching for the server, then Alpine is a better option.
In my opinion, when everything breaks down (and not saying this is your case, just what I think) is if you try to do every interaction with Livewire (thus reaching for the server when you shouldn't) or when trying to mix in SPA tools (such as Vue, React, etc...) with it. I suppose you'll end up with the worst parts of every solution.
In my opinion, when everything breaks down (and not saying this is your case, just what I think) is if you try to do every interaction with Livewire (thus reaching for the server when you shouldn't) or when trying to mix in SPA tools (such as Vue, React, etc...) with it. I suppose you'll end up with the worst parts of every solution.
Did also plaid with Ruby on Rails, or even Sinatra, and how would your rank the dev XP compared to Laravel?
I did use Rails for several months while helping a friend with his business/sideproject/startup kick-off and despite I really liked it, I much prefer Laravel + Livewire and PHP (https://tallstack.dev/) over Rails + Hotwire + Ruby, but it's up to personal preferences:
- I prefer things to be more explicit than implicit and lean more towards configuration over convention.
- I lean more towards having types/typing information than not having it
- PHP is way, way, way more used than Ruby
- Performance (just talking about development environment performance) is a lot better in PHP (no server restarts, etc)
- Availability of third party libraries is a lot stronger on the PHP side, probably due to it being more popular
- Tooling and editor support. This is a big one for me, and I've found out things to work a lot better with VSCode for PHP than for Ruby. Probably related to it being both, more popular and more explicit.
- Overall, Laravel feels even more complete than Rails and just fits better my brain.
But, I think Rails is still great, and I would use it over building a microservices mesh of Go servers on kubernetes with React frontends, etc, etc.
- I prefer things to be more explicit than implicit and lean more towards configuration over convention.
- I lean more towards having types/typing information than not having it
- PHP is way, way, way more used than Ruby
- Performance (just talking about development environment performance) is a lot better in PHP (no server restarts, etc)
- Availability of third party libraries is a lot stronger on the PHP side, probably due to it being more popular
- Tooling and editor support. This is a big one for me, and I've found out things to work a lot better with VSCode for PHP than for Ruby. Probably related to it being both, more popular and more explicit.
- Overall, Laravel feels even more complete than Rails and just fits better my brain.
But, I think Rails is still great, and I would use it over building a microservices mesh of Go servers on kubernetes with React frontends, etc, etc.
I'll take Rails over Laravel any day. Verbose, doc-block-riddled, pseudo-Java PHP is the polar opposite of elegant, composable Ruby.
Well, probably you are right, but for me ecosystem, libraries, tooling, editor support, performance, etc is far more important than language syntax. But we all have our preferences and that's ok.
I started at 16 and I'm 34. Went from working on gaming websites to running giant ERP backends for mobile apps, web apps, and api users in high throughput environments.
All I need to get to work is VSCode and some linux VM or container. PHP has an obnoxious amount of depth. You can become an expert on just ORMs or just SSO or just Collections or just routing and still be learning something new everyday. I am actually "self tought". Whatever that means.
All I need to get to work is VSCode and some linux VM or container. PHP has an obnoxious amount of depth. You can become an expert on just ORMs or just SSO or just Collections or just routing and still be learning something new everyday. I am actually "self tought". Whatever that means.
> I am actually "self tought". Whatever that means.
What does that mean? I know what taught means, but tought? No idea.
What does that mean? I know what taught means, but tought? No idea.
A charitable interpretation would be that he meant "self-taught". It's not that difficult.
I started doing my first web development with PHP (4 & later 5) around the same time! Actually ended up learning a lot about how the entire LAMP stack worked + a lot of tricks and theory behind how to make things secure (PHP had very few safeguards back then). I'm still reaping the benefits of a lot of this knowledge to this day.
I have moved on to other languages like JS and Python since ~2012. Looking at the article, I feel like modern PHP is almost a completely different beast compared to when I used it back then >_<
I have moved on to other languages like JS and Python since ~2012. Looking at the article, I feel like modern PHP is almost a completely different beast compared to when I used it back then >_<
PHP was my first love. It still is. Professionally I have moved on to other languages. But whenever I have an urge to create something for personal use, PHP is always the most productive way to get it done. With Laravel, I can even make it look polished and put it on the web.
PHP is such a joy that I am really thinking about switching back to it for my day job.
PHP is such a joy that I am really thinking about switching back to it for my day job.
In my experience, a lot of the hate that PHP gets is unjustified. I can only speak from personal experience, but most people I know that complain about PHP were just burnt out from dealing with other developers' code. Having such a low barrier to entry created many novice and hobbyist PHP developers to hit the market, and start producing terrible code due to not fully understanding software development practices. I know I never had an issue with PHP, and could get work done very quickly, but once I had to start working through other's spaghetti code it burnt me out and I moved on to other languages with a bit higher barrier to entry.
yup, same. started at like 16 and just never found a replacement for writing web apps that was as easy to pick up with lots of built in power. the documentation has always been _extremely_ helpful too, shout outs to the php.net team for making it so easy to learn.
I'm just leaving my current role, a fast growing start up with a completely custom framework. Currently at half a million active accounts but there's really no bottleneck with the PHP. Can easily keep throwing more boxes and hardware at it and I feel pretty comfy that it will be fine at 20 million active accounts. Also background jobs processing which is sort of async cause it lives on top of SQS and fires a sub process for every new message.
My iteration cycle is very fast. No need to sit there and wait for compiles. PHP is C-like and written in C so the hate is funny to me. Our code is unit tested, documented, and extremely well organized. I even connect to our database on my dev box through an SSH tunnel managed by a tool I made for us in.... PHP which uses AWS IAM to authorize a private key for 60 seconds and then auto connect. That's how I connect to our EC2 instances too.
I'm now jumping to another successful start up with a small team running Laravel. Again super organized and well documented.
My iteration cycle is very fast. No need to sit there and wait for compiles. PHP is C-like and written in C so the hate is funny to me. Our code is unit tested, documented, and extremely well organized. I even connect to our database on my dev box through an SSH tunnel managed by a tool I made for us in.... PHP which uses AWS IAM to authorize a private key for 60 seconds and then auto connect. That's how I connect to our EC2 instances too.
I'm now jumping to another successful start up with a small team running Laravel. Again super organized and well documented.
I congratulate you on your successful projects but I don't understand what you mean by "PHP is C-like and written in C so the hate is funny to me". The language of the runtime is not particularly relevant unless you want to write custom extensions (which I remember being an absolutely atrocious experience back when I had to do in in ~2007, hopefully it improved since then) and the language itself is only very superficially C-like.
In fact the most C-like thing I remember about it is that many standard library functions where extremely thin wrappers around the libc, so thin in fact that you could get a segfault if you weren't careful.
In fact the most C-like thing I remember about it is that many standard library functions where extremely thin wrappers around the libc, so thin in fact that you could get a segfault if you weren't careful.
Was implying it's efficient and fast. It's extremely unlikely you will ever need to write an extension.
> PHP is C-like and written in C so the hate is funny to me.
You didn't realize how many people hate C? (Like any other popular language, yes)
You didn't realize how many people hate C? (Like any other popular language, yes)
I've being used PHP since it was Personal Home Page (3.x or something). The reason I moved away from it, is it is language make up. Some point around 4 it try to become Java OO style (ok ES6 is trying to do that too). The main reason moving away from it is because would like to have language that has function as a first class citizen, and JS seems to fit the bill. Once I found the joy of developing with proper closure and using function as a first class citizen PHP just doesn't appeal to me. The best things about PHP is it's templating system. And with EJS or similar there is really no reason to use PHP anymore.
PHP supports first class functions though?
While PHP is adding a First class callable syntax in 8.1, first-class-functions have been available in PHP since 5.3.0 (Released Jun 2009) going by the Wikipedia definition:
> This means the language supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures.
Ref: https://stackoverflow.com/a/59293198/368328, https://3v4l.org/rQGk2
> This means the language supports passing functions as arguments to other functions, returning them as the values from other functions, and assigning them to variables or storing them in data structures.
Ref: https://stackoverflow.com/a/59293198/368328, https://3v4l.org/rQGk2
I'm glad the community around modern PHP is thriving, but filler articles like these are getting on my nerves. Reiterating a bunch of content that has already been covered extensively on the web in the past months (and in 10+ previous posts on your own blog), slapping a misleading title on it and filling it up with call-to-action's for your own personal video/newsletter/courses isn't good content. The author had some really good articles in the past, but this reads like fluff just to fill up his blog. Quality over quantity.
I’m the author, and I think you’re partially right.
This article wasn’t done (and I’m still going to finish it, a “looking forward” section is missing)
I published it to get some feedback from the occasional reader, which I do more often. You can see I haven’t tweeted or posted it anywhere, I wanted to wait a couple of days still; so it’s a little unfortunate it got picked up here so soon. Of course I’m happy with the positive reception overall, but I agree that it’s not done yet.
On the part of self promotion within my own content: that’s just the way I’ve been doing it for years. I don’t feel guilty about mentioning other things I’ve made that I’m proud of and what I believe are high value as well. So on that part I don’t agree.
I do appreciate the overall feedback though, thanks for taking the time to share it
This article wasn’t done (and I’m still going to finish it, a “looking forward” section is missing)
I published it to get some feedback from the occasional reader, which I do more often. You can see I haven’t tweeted or posted it anywhere, I wanted to wait a couple of days still; so it’s a little unfortunate it got picked up here so soon. Of course I’m happy with the positive reception overall, but I agree that it’s not done yet.
On the part of self promotion within my own content: that’s just the way I’ve been doing it for years. I don’t feel guilty about mentioning other things I’ve made that I’m proud of and what I believe are high value as well. So on that part I don’t agree.
I do appreciate the overall feedback though, thanks for taking the time to share it
You're not wrong, but Brent's articles are just about the cream de la cream for PHP. I'm glad to see him on the HN front page. I've been coding in PHP since 1999, so I've seen the language evolve from not-Perl to what we have today. For maybe two or three years now I've relied on to Brent to bring me up to the newest state of the art without having to parse changelogs and release notes (which I usually get to around March or April, a few months after the yearly December release).
For those of us in the PHP industry, I feel that the most concise way to stay up to date is with Brent's commentary and the Jetbrains PhpStorm blog.
For those of us in the PHP industry, I feel that the most concise way to stay up to date is with Brent's commentary and the Jetbrains PhpStorm blog.
He wrote some decent articles before, and he might write some good ones in the future, but this right here, this ain't it.
Unlike other "x in 2022" articles (for example https://www.ncameron.org/blog/rust-in-2022-2/), this one doesn't actually give any insight into the future of the language. Not only that, but there is no original content in it. He's simply repeating what he's been writing about for the past year. Maybe he should've called it PHP in 2021? Oh wait, he already did that (https://stitcher.io/blog/php-in-2021) and it's eerily similar to this article. If there is nothing new to write about, why write?
I'm glad you bring up the PHP Annotated Monthly blog, it's a great resource and definitely one of the blogs to follow to keep up to date with PHP.
Unlike other "x in 2022" articles (for example https://www.ncameron.org/blog/rust-in-2022-2/), this one doesn't actually give any insight into the future of the language. Not only that, but there is no original content in it. He's simply repeating what he's been writing about for the past year. Maybe he should've called it PHP in 2021? Oh wait, he already did that (https://stitcher.io/blog/php-in-2021) and it's eerily similar to this article. If there is nothing new to write about, why write?
I'm glad you bring up the PHP Annotated Monthly blog, it's a great resource and definitely one of the blogs to follow to keep up to date with PHP.
> He wrote some decent articles before, and he might write some good ones in the future, but this right here, this ain't it.
On the contrary, I appreciate the author trying to summarize something instead of having to go through the last 10 posts.
I started my career in PHP ~15 years ago trying to do OOP in PHP 4.x. That was "fun".
In the meantime I switched to other stacks but I've been keeping a distant eye on how PHP was evolving and I still am involved with PHP projects to a certain degree, though rarely at code level.
I really appreciate the effort put into fixing most of the things I hated about the language, though at times it felt like the language and some of the frameworks were trying too hard to copy the Java ecosystem, all while Java itself was starting to modernize.
I'm curious what is the value proposition of the latest PHP version(s). Why would I choose PHP when starting a greenfield project? I know one of the easiest answers is that there's a huge amount of developers worldwide that know PHP, but apart from this obvious reason is there anything else that would make someone choose PHP ahead of other stacks?
In the meantime I switched to other stacks but I've been keeping a distant eye on how PHP was evolving and I still am involved with PHP projects to a certain degree, though rarely at code level.
I really appreciate the effort put into fixing most of the things I hated about the language, though at times it felt like the language and some of the frameworks were trying too hard to copy the Java ecosystem, all while Java itself was starting to modernize.
I'm curious what is the value proposition of the latest PHP version(s). Why would I choose PHP when starting a greenfield project? I know one of the easiest answers is that there's a huge amount of developers worldwide that know PHP, but apart from this obvious reason is there anything else that would make someone choose PHP ahead of other stacks?
Share-nothing architecture, good, stable ecosystem build around Composer, Laravel and Symfony and as you said a lot of devs.
Otherwise, I think differences in syntax etc. are rather subjective and everyone has their preferences. For example, I really like PHP "arrays" because it removes cognitive load of choosing between different data structures. When writing business rules 90% of time I don't really care about optimization or memory, but about readability and communication.
Overall, PHP is rather dumb language and I love it for being dumb.
Python package management currently is a nightmare, but projects like Poetry seem on a good track to make it better. JavaScript is better than Python at package management, but it has issues with many small packages maintained by random people. Java ecosystem also seems quite a lot more complex, especially when you compare Composer and Maven. Compilation aspect also changes the way you work.
I have no experience with Ruby, C#, .NET etc.
Otherwise, I think differences in syntax etc. are rather subjective and everyone has their preferences. For example, I really like PHP "arrays" because it removes cognitive load of choosing between different data structures. When writing business rules 90% of time I don't really care about optimization or memory, but about readability and communication.
Overall, PHP is rather dumb language and I love it for being dumb.
Python package management currently is a nightmare, but projects like Poetry seem on a good track to make it better. JavaScript is better than Python at package management, but it has issues with many small packages maintained by random people. Java ecosystem also seems quite a lot more complex, especially when you compare Composer and Maven. Compilation aspect also changes the way you work.
I have no experience with Ruby, C#, .NET etc.
I can agree with the share-nothing architecture as a good selling point that keeps things simple but there are use cases where this is actually a limitation.
Parts of the community seem to want to go over that limitation so things like Swoole and Roadrunner were developed. I guess it's interesting to have both options available even though much of the ecosystem won't readily function in both contexts.
While the ecosystem seems a bit weaker that what I would expect considering the number of developers (comparing to Java, Ruby, Python) I don't have a strong opinion on package management. I feel like all major platforms have gotten into pretty good shape on this front. Like you mentioned, if I start a new Python project I can just choose Poetry and avoid most of the drama.
Parts of the community seem to want to go over that limitation so things like Swoole and Roadrunner were developed. I guess it's interesting to have both options available even though much of the ecosystem won't readily function in both contexts.
While the ecosystem seems a bit weaker that what I would expect considering the number of developers (comparing to Java, Ruby, Python) I don't have a strong opinion on package management. I feel like all major platforms have gotten into pretty good shape on this front. Like you mentioned, if I start a new Python project I can just choose Poetry and avoid most of the drama.
Essentially you have 3 types of web backends
1) CGI and similar share-nothing architecture like PHP, unaware of process model, threaded or processes, everything starts from zero. Any state needs to be handle outside of the runtime. Stateless thus a good conceptual fit for stateless protocol like REST.
2) Threaded frameworks like Java Spring or Python frameworks, the framework forks for you, but the architecture is leaky, you can share data between threads intentionally or unintentionally. Benefits from things like connection pools to be used between requests. Can be easier when need to handle a single mutex of a resource compared to 1), e.g only one job instance should run simultaneously. However most of the time you write code as if it was share-nothing, because fewer complications (no need to worry about locks, concurrent collections etc) and reduces risks of introducing any hard to debug and expensive mutex.
3) Single threaded event driven architecture, no need to worry about race condition thus you can keep global state within the application between requests, no locks or anything but with a big caveat, as soon as you start running your application as multiprocess, like cluster, that global state can no longer be used for data sharing, only for caches like database connection, thus the best way of writing application code is to write it as share nothing to avoid any state related bugs.
BUT single threaded event driven architecture also has a huge drawback, you can essentially freeze the entire application by programmer error or introduce hard to detect mini freezes because it is single threaded.
Proposition: the larger the single threaded event driven application becomes the higher the chance of freezing your application.
I think this is why nodejs shepherds you to write micro services and conversely PHP shepherds you to build monoliths because you don't care about the process model when writing PHP.
Conclusion: You should almost always design your code as share nothing. The only benefit of picking either of 1), 2) or 3) is for performance considerations outside of team expertise and community. 2) and 3) can have better performance than 1) due things like to connection pooling but 3) is bad choice in respect to longlivity because of the monolith mismatch. 1) is easier to reason about because the process model is irrelevant thus increasing longlivity.
1) CGI and similar share-nothing architecture like PHP, unaware of process model, threaded or processes, everything starts from zero. Any state needs to be handle outside of the runtime. Stateless thus a good conceptual fit for stateless protocol like REST.
2) Threaded frameworks like Java Spring or Python frameworks, the framework forks for you, but the architecture is leaky, you can share data between threads intentionally or unintentionally. Benefits from things like connection pools to be used between requests. Can be easier when need to handle a single mutex of a resource compared to 1), e.g only one job instance should run simultaneously. However most of the time you write code as if it was share-nothing, because fewer complications (no need to worry about locks, concurrent collections etc) and reduces risks of introducing any hard to debug and expensive mutex.
3) Single threaded event driven architecture, no need to worry about race condition thus you can keep global state within the application between requests, no locks or anything but with a big caveat, as soon as you start running your application as multiprocess, like cluster, that global state can no longer be used for data sharing, only for caches like database connection, thus the best way of writing application code is to write it as share nothing to avoid any state related bugs.
BUT single threaded event driven architecture also has a huge drawback, you can essentially freeze the entire application by programmer error or introduce hard to detect mini freezes because it is single threaded.
Proposition: the larger the single threaded event driven application becomes the higher the chance of freezing your application.
I think this is why nodejs shepherds you to write micro services and conversely PHP shepherds you to build monoliths because you don't care about the process model when writing PHP.
Conclusion: You should almost always design your code as share nothing. The only benefit of picking either of 1), 2) or 3) is for performance considerations outside of team expertise and community. 2) and 3) can have better performance than 1) due things like to connection pooling but 3) is bad choice in respect to longlivity because of the monolith mismatch. 1) is easier to reason about because the process model is irrelevant thus increasing longlivity.
I seems to me that php/js/python will have a large consolidation in the next decade.
What do you mean by a large consolidation? As in users will coalesce around one of these ecosystems, or something else?
More like a lot of their flaws will resolve around a similar set of ideas.
> I'm curious what is the value proposition of the latest PHP version(s).
I think more and more people have started to realise that typed languages make better, more reliable software. The incremental additions to PHP's type system are just a move towards this, I think and can be seen in other languages such as Typescript.
I'm just not a fan of dynamically typed languages anymore, even for small scripts.
> Why would I choose PHP when starting a greenfield project?
I think it depends on your greenfield project, but there are many domains where problems are just solved related to e-commerce or shuffling around content online.
To this point, PHP benefits just from the fact that it has been around for so long, and will continue to be supported far into the future.
Many PHP frameworks like Symfony have LTS releases that will ensure software is supported years into the future, with strong support from agencies.
I think more and more people have started to realise that typed languages make better, more reliable software. The incremental additions to PHP's type system are just a move towards this, I think and can be seen in other languages such as Typescript.
I'm just not a fan of dynamically typed languages anymore, even for small scripts.
> Why would I choose PHP when starting a greenfield project?
I think it depends on your greenfield project, but there are many domains where problems are just solved related to e-commerce or shuffling around content online.
To this point, PHP benefits just from the fact that it has been around for so long, and will continue to be supported far into the future.
Many PHP frameworks like Symfony have LTS releases that will ensure software is supported years into the future, with strong support from agencies.
I think that says more about your particular mental model of programming than about programming in general. In the couple of decades I’ve been coding, I’ve seen good use of both dynamically/weakly-typed and strongly typed languages.
Sure— thinking you’re going to save time writing more complex applications by avoiding boilerplate is flatly wrong. However, if boilerplate would be a double-digit percentage of your code, you probably will save time avoiding it because any unlikely dynamic typing issues will be easily resolved. But if it’s small enough to be inconsequential and you’re in the typed-language zone, why not use your typed language, anyway?
Avoid dogma and use the right tool for the job, I say.
Sure— thinking you’re going to save time writing more complex applications by avoiding boilerplate is flatly wrong. However, if boilerplate would be a double-digit percentage of your code, you probably will save time avoiding it because any unlikely dynamic typing issues will be easily resolved. But if it’s small enough to be inconsequential and you’re in the typed-language zone, why not use your typed language, anyway?
Avoid dogma and use the right tool for the job, I say.
> I think that says more about your particular mental model of programming than about programming in general.
Well, I originally started programming only using dynamic types.
Then I moved to typed languages, and I could avoid whole categories of errors. I don't see it as dogma, I think typed languages are just qualitatively better at creating software. I also think this is starting to become industry experience, as efforts like Typescript, and the incremental additions to PHP's type-system show.
Well, I originally started programming only using dynamic types.
Then I moved to typed languages, and I could avoid whole categories of errors. I don't see it as dogma, I think typed languages are just qualitatively better at creating software. I also think this is starting to become industry experience, as efforts like Typescript, and the incremental additions to PHP's type-system show.
Categorically better for everything and not categorically better for everything you write?
How about for the type of task PHP is often used for? A nearly default CRUD web app w/loads of fields and tables? Rapid prototyping? How about a bunch of simple, standalone interface interactions in JS? The extra grammar won't provide much architectural or conceptual clarity in those super common coding tasks because they're already dead simple, or in the case of the rapid prototype, don't need to be durable. Most data transformation— e.g. from the database into hashes— is taken care of by worn-smooth libraries that won't likely cock things up. For these tasks, front-loading complexity for little subsequent benefit is a questionable choice. Maybe you're so used to working with types that you're just as fast,time isn't a factor? Great. If you're not, or another developer you're working with isn't, and time is tight, it's probably a bad choice.
What many of these systems are starting to offer is the option of adding type hinting which is exactly what they should be doing. Python's type hints have been great in a new nontrivial project I'm putting together with multiple developers. If I had to use them for every bit of disposable utility script I write and every little prototype proof-of-concept I stand up then I'd be much less productive.
I reckon skipping situation-specific cost/benefit analysis before asserting something is always better is definitely dogma. ¯\_(ツ)_/¯
How about for the type of task PHP is often used for? A nearly default CRUD web app w/loads of fields and tables? Rapid prototyping? How about a bunch of simple, standalone interface interactions in JS? The extra grammar won't provide much architectural or conceptual clarity in those super common coding tasks because they're already dead simple, or in the case of the rapid prototype, don't need to be durable. Most data transformation— e.g. from the database into hashes— is taken care of by worn-smooth libraries that won't likely cock things up. For these tasks, front-loading complexity for little subsequent benefit is a questionable choice. Maybe you're so used to working with types that you're just as fast,time isn't a factor? Great. If you're not, or another developer you're working with isn't, and time is tight, it's probably a bad choice.
What many of these systems are starting to offer is the option of adding type hinting which is exactly what they should be doing. Python's type hints have been great in a new nontrivial project I'm putting together with multiple developers. If I had to use them for every bit of disposable utility script I write and every little prototype proof-of-concept I stand up then I'd be much less productive.
I reckon skipping situation-specific cost/benefit analysis before asserting something is always better is definitely dogma. ¯\_(ツ)_/¯
> Categorically better for everything and not categorically better for everything you write?
For everything.
As I mentioned, I started out using dynamically typed languages. I don't agree with your idea that types somehow make it harder to develop things quickly--even the throwaway things.
With types I get to grips with a new API quickly via autodiscoverability, and types provide guard-rails to know I'm using the API properly.
With types, I can avoid whole categories of errors, as even the "simple" things like, for example, processing a CSV file can mess up, when someone has accidentally entered a date instead of an ID and that ends up failing for the user.
It's not dogma to have an opinion that types provide a qualitatively better programming experience all around.
For everything.
As I mentioned, I started out using dynamically typed languages. I don't agree with your idea that types somehow make it harder to develop things quickly--even the throwaway things.
With types I get to grips with a new API quickly via autodiscoverability, and types provide guard-rails to know I'm using the API properly.
With types, I can avoid whole categories of errors, as even the "simple" things like, for example, processing a CSV file can mess up, when someone has accidentally entered a date instead of an ID and that ends up failing for the user.
It's not dogma to have an opinion that types provide a qualitatively better programming experience all around.
Of course, you and I both can assemble thousands of tasks for which types are better suited. They would probably comprise the overwhelming majority of a random sampling of everyday coding tasks for professional developers. Having an opinion about what works best for you certainly isn't dogma— but deciding that your perspective is better for everyone else, too, regardless of the person, their needs, and the circumstances, is unambiguously dogmatic.
Many coders will never touch the complexity of most full-time developers' simplest code, and they deserve tools that meet their needs, too. How much future burden will explicit type declaration relieve for an indy self-taught web designer taking strings and floats from a database through an ORM and putting them into a for loop for a web-based coffee shop menu hosted on WordPress? I'd say none. Considering that WordPress runs 37% of websites and 62% of CMSs, I'd argue that there's plenty of room for blunt instruments to do blunt work. Insisting people jump through the types hoop for posterity is not reasonable.
As a long-time developer turned designer, I'm confident that using a "pack" layout strategy in many GUI libraries will consistently produce worse results than properly assembling a quick grid layout. I have my collaborators avoid it because using it == guaranteed re-write... but there's a lot of selection bias there. If teams involve someone like me, that probably means usability is paramount. As crucial as usability is, sometimes speed, convenience, and not needing barely-related expertise is more important. A developer making a dialog on a small internal utility should probably use pack even if I wouldn't. I have the patterns, organization, and syntax in my head to pull simple grid-based layouts faster than they will use 'pack.' For them, it's a bit of mental overhead for an already irritating task with no real payoff. Saying that languages shouldn't even make pack available to developers would be plainly unreasonable.
Even in the tasks you cited— I was a developer in a large library with a ton of older electronic assets. I processed significant amounts of CSV and other messy text files in many dozens of projects using everything from C, shell scripts, and Perl in the earlier days to Python, Elixir, and JS in the latter. I can count how often difficult-to-pin-down data type ambiguity burned me using zero fingers. I guarantee you having to futz around with types rather than throwing in an instance check or the like would have reduced my efficiency. If I had finicky or complex or relational data that needed to maintain integrity through a nontrivial pipeline, then I wouldn't think twice about implementing them.
In general, asserting that your way of doing something is universally better than other common ways of doing something is almost guaranteed to be dogmatic. For it not to be, you must provide a universally applicable truth that trumps individual use cases and people's preferences. "It avoids entire categories of bugs, near their source" doesn't work for people who will likely never encounter those categories of bugs. Insisting others are wrong for not agreeing with the accepted best practices of people who do regular professional dev work is absolutely dogmatic.
Many coders will never touch the complexity of most full-time developers' simplest code, and they deserve tools that meet their needs, too. How much future burden will explicit type declaration relieve for an indy self-taught web designer taking strings and floats from a database through an ORM and putting them into a for loop for a web-based coffee shop menu hosted on WordPress? I'd say none. Considering that WordPress runs 37% of websites and 62% of CMSs, I'd argue that there's plenty of room for blunt instruments to do blunt work. Insisting people jump through the types hoop for posterity is not reasonable.
As a long-time developer turned designer, I'm confident that using a "pack" layout strategy in many GUI libraries will consistently produce worse results than properly assembling a quick grid layout. I have my collaborators avoid it because using it == guaranteed re-write... but there's a lot of selection bias there. If teams involve someone like me, that probably means usability is paramount. As crucial as usability is, sometimes speed, convenience, and not needing barely-related expertise is more important. A developer making a dialog on a small internal utility should probably use pack even if I wouldn't. I have the patterns, organization, and syntax in my head to pull simple grid-based layouts faster than they will use 'pack.' For them, it's a bit of mental overhead for an already irritating task with no real payoff. Saying that languages shouldn't even make pack available to developers would be plainly unreasonable.
Even in the tasks you cited— I was a developer in a large library with a ton of older electronic assets. I processed significant amounts of CSV and other messy text files in many dozens of projects using everything from C, shell scripts, and Perl in the earlier days to Python, Elixir, and JS in the latter. I can count how often difficult-to-pin-down data type ambiguity burned me using zero fingers. I guarantee you having to futz around with types rather than throwing in an instance check or the like would have reduced my efficiency. If I had finicky or complex or relational data that needed to maintain integrity through a nontrivial pipeline, then I wouldn't think twice about implementing them.
In general, asserting that your way of doing something is universally better than other common ways of doing something is almost guaranteed to be dogmatic. For it not to be, you must provide a universally applicable truth that trumps individual use cases and people's preferences. "It avoids entire categories of bugs, near their source" doesn't work for people who will likely never encounter those categories of bugs. Insisting others are wrong for not agreeing with the accepted best practices of people who do regular professional dev work is absolutely dogmatic.
I started on the other end (my first language was C89) and I am with you on types. Just being able to read a plaintext file and know what type every variable and parameter is just makes reading the code easier to me. My primary language is python at the moment, and I don't think I could continue without the type annotations that you can add in coupled with mypy (a static type checker that you can run on the cli as part of a build).
Every time I see a regular Map with nested maps, I get a little annoyed.
Every time I see a regular Map with nested maps, I get a little annoyed.
[deleted]
php is my language of choice, I love modern php, but I struggle with the same question. As a language, I think php is great, and for a solo project it is an obvious choice for me because of my proficiency and the quality of the language... but would I start a greenfield project with php? No.
I've worked across a variety of different companies and a consistent theme is the existence of "php developers" in these companies, and the bad quality software they produce. I'm currently working at a company (founded within the last 5 years) and their php codebase is AWFUL (no structure, 1k+ LOC methods, no tests, no ci, no documentation etc.)[1].
The problem is not php, it's that a lot of PHP developers are doing the same thing they did 10 years ago, despite the industry having moved on. As a Software Engineer, I think there's a very valid case for php over Ruby or Python or Node, however as a CTO or a team lead, I'd really, really struggle to justify it, which pains me to say. If you're trying to hire php developers, you'll be hiring a lot of people who haven't changed how they work since the late 2000s. I'd rather hire code school graduates to write Ruby than a php developer with a decade of experience.
[1] People can write bad code anywhere, but pre-historic php is especially terrible. A company with bad golang is an order of magnitude more penetrable than a company with bad php.
I've worked across a variety of different companies and a consistent theme is the existence of "php developers" in these companies, and the bad quality software they produce. I'm currently working at a company (founded within the last 5 years) and their php codebase is AWFUL (no structure, 1k+ LOC methods, no tests, no ci, no documentation etc.)[1].
The problem is not php, it's that a lot of PHP developers are doing the same thing they did 10 years ago, despite the industry having moved on. As a Software Engineer, I think there's a very valid case for php over Ruby or Python or Node, however as a CTO or a team lead, I'd really, really struggle to justify it, which pains me to say. If you're trying to hire php developers, you'll be hiring a lot of people who haven't changed how they work since the late 2000s. I'd rather hire code school graduates to write Ruby than a php developer with a decade of experience.
[1] People can write bad code anywhere, but pre-historic php is especially terrible. A company with bad golang is an order of magnitude more penetrable than a company with bad php.
I completely agree with this but I avoided mentioning it as I wanted to get some objective technical answers, decoupled from any of the usual operational concerns: number of people, mindset of people, seniority, etc.
I think the main cause is the low barrier for entry. It's great that anyone can get started quickly and be successful but it also means that the resulting mess can be at a level that you rarely see in other stacks where the barrier for entry is a bit higher.
I can clearly see that the PHP ecosystem is there (mature libraries for mocks, tests, etc) but like you said, there are people that just don't care. The language and ecosystem evolved faster than a big chunk of the developer community and I don't think everybody will catch-up anytime soon, as old PHP code bases can still generate a nice revenue doing maintenance.
I think the main cause is the low barrier for entry. It's great that anyone can get started quickly and be successful but it also means that the resulting mess can be at a level that you rarely see in other stacks where the barrier for entry is a bit higher.
I can clearly see that the PHP ecosystem is there (mature libraries for mocks, tests, etc) but like you said, there are people that just don't care. The language and ecosystem evolved faster than a big chunk of the developer community and I don't think everybody will catch-up anytime soon, as old PHP code bases can still generate a nice revenue doing maintenance.
> Why would I choose PHP when starting a greenfield project?
LAMP stacks are super ubiquitous, open source, cross-platform, and in many cases to deploy your app you don't need to configure anything, add any modules or dependencies... just copy your files in place. A small project (e.g. contact form with a CAPTCHA) could be just a small file named whatever you want, which you can place anywhere in the public directory, and it'll work.
If you don't want to maintain the server you can get a managed VPS and things will probably run and continue to run for years without any intervention on your part, even through software updates.
... The exception is that PHP breaks backwards compatibility often, but even then most hosting services let you choose between different PHP versions which they'll maintain for a while. Installing older versions from package managers is very easy as well.
That said, I don't think this is a strong reason to use PHP in most projects. I do think it could be one of the strongest ones to justify its use in some specific projects.
LAMP stacks are super ubiquitous, open source, cross-platform, and in many cases to deploy your app you don't need to configure anything, add any modules or dependencies... just copy your files in place. A small project (e.g. contact form with a CAPTCHA) could be just a small file named whatever you want, which you can place anywhere in the public directory, and it'll work.
If you don't want to maintain the server you can get a managed VPS and things will probably run and continue to run for years without any intervention on your part, even through software updates.
... The exception is that PHP breaks backwards compatibility often, but even then most hosting services let you choose between different PHP versions which they'll maintain for a while. Installing older versions from package managers is very easy as well.
That said, I don't think this is a strong reason to use PHP in most projects. I do think it could be one of the strongest ones to justify its use in some specific projects.
Haven't thought of this, I guess for some people it makes sense especially for small, personal projects. I'm more biased towards startups with a plan to grow or larger projects.
In my case if the hosting provider doesn't have something like DigitalOcean's droplets I'll still rely on docker compose instead of the default stack deployed on the system whatever stack I'm choosing. But yeah that's raising the bar too much for most people especially for a couple of scripts or pages.
In my case if the hosting provider doesn't have something like DigitalOcean's droplets I'll still rely on docker compose instead of the default stack deployed on the system whatever stack I'm choosing. But yeah that's raising the bar too much for most people especially for a couple of scripts or pages.
> Why would I choose PHP when starting a greenfield project?
For me, the answer is Laravel.
For me, the answer is Laravel.
For someone who has never used PHP: what is so good about it?
Laravel provides structure to PHP apps. It includes a terrific router (Symphony) and a slew of functions missing or clumsy in PHP.
Basically the Rails for PHP, but with an arguably bigger ecosystem.
If I'm forced to choose PHP that's the choice I would also make in most cases, probably because it reminds me of some of the things I liked about Rails.
> Why would I choose PHP when starting a greenfield project?
Ease? I have not professionally used php since php4, and last set it up in php5.x.
Last night I wanted to send some data to an http server, a small payload of json, that would be saved into a DB and queried later. Took me all of 5m to realise that my php test script that receives the file can be copied over to my el-cheapo webhost account unchanged and work fine.
No extra "database" modules to download, then install on a host I've no shell access to, sending email worked out the box, etc.
Php reduces the friction. I remember trying to use Python for something (with Django, I think) in 2011 and it was absolute hell to get deployed onto my webhost; fingers burned, I won't touch it again.
Php is basically batteries included, and works everywhere. I'm sure the Python, Node or Ruby alternatives are elegant, and neat, etc ... but if I wanted that, it means the project is expected to be large-ish, and for anything more than a few thousand lines of code I'm switching to a compiled language.
Ease? I have not professionally used php since php4, and last set it up in php5.x.
Last night I wanted to send some data to an http server, a small payload of json, that would be saved into a DB and queried later. Took me all of 5m to realise that my php test script that receives the file can be copied over to my el-cheapo webhost account unchanged and work fine.
No extra "database" modules to download, then install on a host I've no shell access to, sending email worked out the box, etc.
Php reduces the friction. I remember trying to use Python for something (with Django, I think) in 2011 and it was absolute hell to get deployed onto my webhost; fingers burned, I won't touch it again.
Php is basically batteries included, and works everywhere. I'm sure the Python, Node or Ruby alternatives are elegant, and neat, etc ... but if I wanted that, it means the project is expected to be large-ish, and for anything more than a few thousand lines of code I'm switching to a compiled language.
If you use CGI, you can have it just as easy with any language.
I mean value proposition specifically to the latest version? Some syntax improvements here and there, nothing big.
The value proposition *is* the ecosystem. Do I prefer coding Python to PHP? Sure (although it's not night and day difference by any stretch of imagination). Do I prefer Laravel or Django? Laravel. Do I prefer WordPress or ....? Actually, there's no equivalent, it's the one ton gorilla in that space.
When it comes to the 'classical' web (but also fun new toys like Laravel Livewire), there's very little that can compete with PHP as far as I'm concerned and the IMHO minor warts are certainly not worth losing the ecosystem for.
The value proposition *is* the ecosystem. Do I prefer coding Python to PHP? Sure (although it's not night and day difference by any stretch of imagination). Do I prefer Laravel or Django? Laravel. Do I prefer WordPress or ....? Actually, there's no equivalent, it's the one ton gorilla in that space.
When it comes to the 'classical' web (but also fun new toys like Laravel Livewire), there's very little that can compete with PHP as far as I'm concerned and the IMHO minor warts are certainly not worth losing the ecosystem for.
There are definitely parts of PHP and its ecosystem that have been trying to copy Java. On the flip side, PHP is quite similar to Java when it comes to its value proposition, so I can appreciate why the devs have chosen that path. Like Java, PHP is stable and slow-moving. It takes backward compatibility seriously, and it has a huge community. PHP is to small-time "webmasters" and lifestyle businesses what Java is to governments and large corporations.
If you want to build something once and get passive income out of it for the better part of a decade, PHP has your back. Pinboard is a prime example of this business model.
If you're a fast-moving startup who will replace your entire codebase every six months, you might be better served by JS.
If you want to build something once and get passive income out of it for the better part of a decade, PHP has your back. Pinboard is a prime example of this business model.
If you're a fast-moving startup who will replace your entire codebase every six months, you might be better served by JS.
Why would one pick PHP over Java except because "you already know PHP"?
> If you're a fast-moving startup who will replace your entire codebase every six months, you might be better served by JS.
Noooooo... :)
> If you're a fast-moving startup who will replace your entire codebase every six months, you might be better served by JS.
Noooooo... :)
> Why would one pick PHP over Java except because "you already know PHP"?
If it's a lifestyle business or hobby project, it usually costs less to host a PHP app somewhere than to find a place where you can get decent performance out of the JVM. Even a small droplet can be a lot of money and effort for some people in some parts of the world. I often see kids pick up PHP for this reason alone. Then they stick with what they know.
If it's a lifestyle business or hobby project, it usually costs less to host a PHP app somewhere than to find a place where you can get decent performance out of the JVM. Even a small droplet can be a lot of money and effort for some people in some parts of the world. I often see kids pick up PHP for this reason alone. Then they stick with what they know.
> Why would I choose PHP when starting a greenfield project?
Because you don't know better. If all you have is a hammer, everything looks like a nail.
Ruby + Rails is miles ahead of PHP + Laravel. If you want more static typing (which I currently believe is a good thing) I really like Kotlin (+ KTor or + Javalin). If you are okay without OO and like static typing Haskell + IHP is pretty complete. If you are okay with learning about low-level stuff, Rust + Actix is really nice.
All of this may require learning new things, and coming from PHP that's a good thing. PHP and JavaScript are not languages that help you become a better programmer. They are messy and lack important features (sum-types).
Because you don't know better. If all you have is a hammer, everything looks like a nail.
Ruby + Rails is miles ahead of PHP + Laravel. If you want more static typing (which I currently believe is a good thing) I really like Kotlin (+ KTor or + Javalin). If you are okay without OO and like static typing Haskell + IHP is pretty complete. If you are okay with learning about low-level stuff, Rust + Actix is really nice.
All of this may require learning new things, and coming from PHP that's a good thing. PHP and JavaScript are not languages that help you become a better programmer. They are messy and lack important features (sum-types).
Ruby + Rails is miles ahead of PHP + Laravel.
Wtf are you saying Willis.. but i guess it's a matter of preference, also consider that in PHP you can also use symfony which is my preference, but regardless of everything, you either come here with a list of things that make ruby on rails miles ahead or people is just going to classify your ideas as worthless
Wtf are you saying Willis.. but i guess it's a matter of preference, also consider that in PHP you can also use symfony which is my preference, but regardless of everything, you either come here with a list of things that make ruby on rails miles ahead or people is just going to classify your ideas as worthless
> Wtf are you saying Willis..
Is that a metaquote or something? Mr. Belvedere doing an impression of "the children's favorite programme?"
Is that a metaquote or something? Mr. Belvedere doing an impression of "the children's favorite programme?"
Yeah it was a quote but i translated literally from Italian 1:1 and i guess it was hard to catch in English https://youtu.be/bJd1RktjYTU
The phrase is "what you talkin bout Willis" - I think it's from the American TV show Different Strokes.
You can write JavaScript via Typescript, and you now have one of the best and most popular languages there is (including sum types). There are still a lot of warts, but it’s actually a really nice language IMO.
No good backend frameworks comparable to Rails/Laravel/Django in JavaScript though (and I say this as someone who works with JS backends in my day job).
There is AdonisJS, a JS framework inspired by Laravel. I don't know if it has 1:1 feature comparison with Laravel, but for someone who uses Laravel daily like me, it seems nice.
I like TypeScript as a language to write, but find the compilation process to be almost impossible to tolerate. Every time I return to an old project and try to compile it again, something is broken: from a dependency deciding to change their own compilation process for one incompatible with mine, to some deep dependency of my own compilation process changing which conflicts with some other part of my process. I spend more time on my project's compilation process than the project itself: something that is only true of TypeScript.
Things are improving as more and more "batteries included" projects are launched, and it's better today than it was a year ago, so I'm happy about the positive change and I am optimistic about the future, but right now I can't begin to imagine labelling TypeScript as even close to being one of the "best" languages, because delivering software with it is a nightmare. TypeScript is great to write but hell to turn into JavaScript.
Things are improving as more and more "batteries included" projects are launched, and it's better today than it was a year ago, so I'm happy about the positive change and I am optimistic about the future, but right now I can't begin to imagine labelling TypeScript as even close to being one of the "best" languages, because delivering software with it is a nightmare. TypeScript is great to write but hell to turn into JavaScript.
Have you seen ReScript and/or ReasonML? They are much nicer IHMO, but, yes, not as popular.
Typescript hits that sweet spot of popularity/portability/type-safety, and although ReasonML is superior in nearly any technical criteria imaginable, I still reach to TS when I'm starting new.
I've played with them quite a bit from the first time they were mentioned on HN. I really like OCaml. But the tooling and ergonomics are heavily in TypeScript's favor at this point, and at least for me, that makes a bit difference in day-to-day work. Anyway, my favorite of that variety of languages is PureScript. It's almost perfect.
I wholly agree about PureScript. Elm's also nice. I like the fact that it is a little dumb down (same could be said for early Java and Go), it creates code everyone can read. While it is still very Haskelly in day-to-day practice. In fact I'd say PureScript and Elm are stronger typed than Haskell (as e.g. `head` in Elm evals to a Maybe).
> PHP and JavaScript are not languages that help you become a better programmer.
One can do some really beautiful programming in both modern JavaScript and modern PHP. Both these languages can and have helped millions of programmers become better programmers. Today's JavaScript and PHP are no longer the hacked up languages they once were.
One can do some really beautiful programming in both modern JavaScript and modern PHP. Both these languages can and have helped millions of programmers become better programmers. Today's JavaScript and PHP are no longer the hacked up languages they once were.
fraktl(1)
Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language?
PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course.
That, and also the fact that it may be pretty much the only dynamic language in use today with ARC and not a GC. Funny how PHP devs are often unaware of this.
Anyway I wish the language at least evolved faster and we wouldn't wait for 8.0 to have global `const` definitions instead of the archaic `define()` for example.
PHP is not a likable language but it's probably not going away any time soon. Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course.
That, and also the fact that it may be pretty much the only dynamic language in use today with ARC and not a GC. Funny how PHP devs are often unaware of this.
Anyway I wish the language at least evolved faster and we wouldn't wait for 8.0 to have global `const` definitions instead of the archaic `define()` for example.
> Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner.
I don't see that as its biggest killer feature. In fact most projects built on PHP using a framework won't use the feature, as every request will be routed through a front controller. This has been true for at least a decade.
I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient.
I don't see that as its biggest killer feature. In fact most projects built on PHP using a framework won't use the feature, as every request will be routed through a front controller. This has been true for at least a decade.
I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient.
> I think the killer feature of PHP is its shared-nothing architecture, tear-down at every request (or every x requests if you're using php-fpm) which has proved remarkably successful as it is so resilient.
I agree. Shared nothing is definitely the killer feature.
Even if php-fpm is tear down at every x requests, each request still starts afresh in which each needed PHP file is required and loaded again. This is not slow because of opcode caching means that parsing etc. does not need to be done afresh. PHP just pulls from the opcode cache. At the end of the request the request is torn down. The interpreter instance might be reused again for performance (though that may be torn down every x request also as you implied with php-fpm for instance).
When you want to find out why something did not work in PHP you just need to go back to the start of the request and work your way from here. With a stateful system like Django (Python) or nodejs (JavaScript) you need to worry about the state of the full server in addition to what happen in a specific request.
This is an ideal model of course because large PHP implementations uses caching (in things like redis) to speed things up and the cached state could be the one introducing a bug. However, in practice, PHP tries to put in most of the state in a relational db so debugging a PHP script is much simpler due to this shared nothing feature.
I agree. Shared nothing is definitely the killer feature.
Even if php-fpm is tear down at every x requests, each request still starts afresh in which each needed PHP file is required and loaded again. This is not slow because of opcode caching means that parsing etc. does not need to be done afresh. PHP just pulls from the opcode cache. At the end of the request the request is torn down. The interpreter instance might be reused again for performance (though that may be torn down every x request also as you implied with php-fpm for instance).
When you want to find out why something did not work in PHP you just need to go back to the start of the request and work your way from here. With a stateful system like Django (Python) or nodejs (JavaScript) you need to worry about the state of the full server in addition to what happen in a specific request.
This is an ideal model of course because large PHP implementations uses caching (in things like redis) to speed things up and the cached state could be the one introducing a bug. However, in practice, PHP tries to put in most of the state in a relational db so debugging a PHP script is much simpler due to this shared nothing feature.
It's a blessing and a curse. Makes it amazingly easy to start with, which is how many PHP developers started (with perhaps folder root index.php rewrites and that's it), but later it makes it confusing, especially if "it always worked" for you, when you want to do dynamic routing.
I see the same pain for some next.js devs these days, even though it does allow parameters in roues in [name].js file form, I saw some people generating routers from file trees and finding it an acceptable compromise. Well, each to their own, I guess.
I see the same pain for some next.js devs these days, even though it does allow parameters in roues in [name].js file form, I saw some people generating routers from file trees and finding it an acceptable compromise. Well, each to their own, I guess.
Could you elaborate on the shared-nothing architecture?
I found this article a while ago
> Every web request starts from a completely blank slate. Its namespace and globals are uninitialized, except for the standard globals, functions and classes that provide primitive functionality and life support. By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1.
> An individual web request runs in a single PHP thread. This seems at first like a silly limitation. But since your program executes in the context of a web server, we have a natural source of concurrency available: web requests. Asynchronously curl’ing to localhost (or even another web server) provides a shared-nothing, copy-in/copy-out way of exploiting parallelism. In practice, this is safer and more resilient to error than the locks-and-shared-state approach that most other general-purpose languages provide.
https://slack.engineering/taking-php-seriously/
> Every web request starts from a completely blank slate. Its namespace and globals are uninitialized, except for the standard globals, functions and classes that provide primitive functionality and life support. By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1.
> An individual web request runs in a single PHP thread. This seems at first like a silly limitation. But since your program executes in the context of a web server, we have a natural source of concurrency available: web requests. Asynchronously curl’ing to localhost (or even another web server) provides a shared-nothing, copy-in/copy-out way of exploiting parallelism. In practice, this is safer and more resilient to error than the locks-and-shared-state approach that most other general-purpose languages provide.
https://slack.engineering/taking-php-seriously/
How does this differ from how other web frameworks work? I thought almost all of them are shared-nothing.
In its early years up until around 2006, PHP was mostly "HTML on steroids", that is, an HTML preprocessor with lots of goodies like "batteries-included" DB access, form handling, image processing, text processing, all accessed via a single Apache module. You simply rename your .html file to .php, and put some magic between "<?php" and "?>".
Then came along templating engines like Smarty, and they introduced a new templating language for a language that was already built for templating. For some reason, "<?= $foo ?>" was considered much worse than "{$foo}".
Then came along templating engines like Smarty, and they introduced a new templating language for a language that was already built for templating. For some reason, "<?= $foo ?>" was considered much worse than "{$foo}".
That's exactly what has puzzled me for a long time: a language with HTML templating as unique selling point needs a templating "engine" after all?
smarty.net has a pamphlet up there where pros/cons (but actually only pros) are discussed [1]. Failing to understand that "<?php ...>" syntax is a SGML processing instruction with well-defined ways to embed into a hosting markup language like HTML, they go even so far as to say
> Another issue with PHP tags is that they share the <> characters of HTML tags. In the application code this isn't an issue, but mixed with HTML, <?php ?> tags are a maddening process to tell them apart from the HTML tags. This also blurs the line between application and presentation separation since any PHP logic can be injected into a template.
Yeah no, now you need new escaping syntax if you ever wanted to have verbatim {$whatever} in your HTML.
Notably missing is a discussion about HTML-aware, injection-free templating such as for preventing {$bla} expanding into <script>alert('Pwnd')</script> when sourced from user input, which is what SGML and other HTML-aware template engines can do, and which in the name of everything that's holy should've been implemented in PHP 2 to save the web from becoming a botnet.
[1]: https://www.smarty.net/syntax_comparison
smarty.net has a pamphlet up there where pros/cons (but actually only pros) are discussed [1]. Failing to understand that "<?php ...>" syntax is a SGML processing instruction with well-defined ways to embed into a hosting markup language like HTML, they go even so far as to say
> Another issue with PHP tags is that they share the <> characters of HTML tags. In the application code this isn't an issue, but mixed with HTML, <?php ?> tags are a maddening process to tell them apart from the HTML tags. This also blurs the line between application and presentation separation since any PHP logic can be injected into a template.
Yeah no, now you need new escaping syntax if you ever wanted to have verbatim {$whatever} in your HTML.
Notably missing is a discussion about HTML-aware, injection-free templating such as for preventing {$bla} expanding into <script>alert('Pwnd')</script> when sourced from user input, which is what SGML and other HTML-aware template engines can do, and which in the name of everything that's holy should've been implemented in PHP 2 to save the web from becoming a botnet.
[1]: https://www.smarty.net/syntax_comparison
>and which in the name of everything that's holy should've been implemented in PHP 2 to save the web from becoming a botnet.
Hack did this correctly with XHP templating. Unfortunately, Hack was killed by PHP7, and of all the features it took from Hack, context-aware native templating was not among them.
Hack did this correctly with XHP templating. Unfortunately, Hack was killed by PHP7, and of all the features it took from Hack, context-aware native templating was not among them.
> For some reason, "<?= $foo ?>" was considered much worse than "{$foo}".
A stigma that remains to this day, even though the spec is very clear about those kinds of short tags and the flags that affect them. PHP developers are absolutely terrified that some imaginary environment flag they have control over is going to brick their application, but are happy to bring in an entirely new templating language as a dependency instead. I'm sure Smarty was borne of a need, but I was never sure what it brought to the table except different tags for existing features.
A stigma that remains to this day, even though the spec is very clear about those kinds of short tags and the flags that affect them. PHP developers are absolutely terrified that some imaginary environment flag they have control over is going to brick their application, but are happy to bring in an entirely new templating language as a dependency instead. I'm sure Smarty was borne of a need, but I was never sure what it brought to the table except different tags for existing features.
It was one of the first freely available languages that allowed you to do image manipulation so sites like DeviantArt would use it.
Its concept of "one endpoint is one script" is one of its biggest killer features
Is that still a thing in PHP world? I recently ended up working on a 'modern' PHP project using Laravel and it was all routers and views and models and auto-generated scaffolding code, just like Rails and Django. There was no sign left of that 'old' approach.
Is that still a thing in PHP world? I recently ended up working on a 'modern' PHP project using Laravel and it was all routers and views and models and auto-generated scaffolding code, just like Rails and Django. There was no sign left of that 'old' approach.
There's a lot of popular examples of more or less abandoning the old ways, but the old ways still work.
I'm of the strong opinion that modern PHP with frameworks and auto-include and a ton of modelling is the wrong way to do it, but everyone else can do it that way, and I can still do things the old way and I can be happy.
PHP has this amazingly zen model of computing. At the end of the request, everything is thrown away to start fresh. This means anything you don't output is garbage. I don't think it makes a lot of sense to make sculptural models of your data and page structure only to throw them away. It's best to keep things simple.
There's some times and places where it makes sense to use more features, but starting with a kitchen sink framework makes it very hard to get simple where it's needed, but you can always pull in a little bit of something more complex into a simple thing.
I'm of the strong opinion that modern PHP with frameworks and auto-include and a ton of modelling is the wrong way to do it, but everyone else can do it that way, and I can still do things the old way and I can be happy.
PHP has this amazingly zen model of computing. At the end of the request, everything is thrown away to start fresh. This means anything you don't output is garbage. I don't think it makes a lot of sense to make sculptural models of your data and page structure only to throw them away. It's best to keep things simple.
There's some times and places where it makes sense to use more features, but starting with a kitchen sink framework makes it very hard to get simple where it's needed, but you can always pull in a little bit of something more complex into a simple thing.
You know, I kind of agree with you. When using Laravel I felt a lot of the time I was fighting against PHP rather than leveraging it. Back in the 'old' days when I was using PHP4 in the way you describe, PHP made sense as a choice compared to, say Python, for certain use cases. Today, I have a hard time coming up with an argument why using modern PHP and Laravel makes more sense than Rails or Django. Maybe we need a post-modern PHP movement focusing on bringing PHP back to its roots.
> Today, I have a hard time coming up with an argument why using modern PHP and Laravel makes more sense than Rails or Django. Maybe we need a post-modern PHP movement focusing on bringing PHP back to its roots.
Over Django: - Because if not doing SPAs, it provides infinitely better tools for the frontend, such as an integrated assets pipeline, a good template language with componetisation support - Because it is faster - Because during development every change is not a restart - Because it has an integrated queue system - Because you have popular frontend solutions such as Livewire
The only better thing I've found in Django is the admin.
Over Rails: - Because it is faster - Because PHP is far, far, far more popular tan Ruby - Because it has integrated authentication - Because it is easier to hire for
just some reasons from the top of my mind. I don't have a ton of experience with Rails and I think it is still great, but IMHO Laravel is better. I have worked with Django for about 10 years, and other than the Admin, I don't miss anything when working with Laravel. Language wise PHP vs Python is just syntax, I don't care as both ecosystems are pretty healthy.
Over Django: - Because if not doing SPAs, it provides infinitely better tools for the frontend, such as an integrated assets pipeline, a good template language with componetisation support - Because it is faster - Because during development every change is not a restart - Because it has an integrated queue system - Because you have popular frontend solutions such as Livewire
The only better thing I've found in Django is the admin.
Over Rails: - Because it is faster - Because PHP is far, far, far more popular tan Ruby - Because it has integrated authentication - Because it is easier to hire for
just some reasons from the top of my mind. I don't have a ton of experience with Rails and I think it is still great, but IMHO Laravel is better. I have worked with Django for about 10 years, and other than the Admin, I don't miss anything when working with Laravel. Language wise PHP vs Python is just syntax, I don't care as both ecosystems are pretty healthy.
It's not. You usually hear that kind of reasoning exclusively from people that last interacted with PHP decades ago.
PHP is either a flawed scripting language for some or a "poor man's java" for others.
I had to learn JEE(JSP,JSF,CDi,JPA) for some project lately, so now I understand a bit more why Doctrine, Synfony and co are the way they are, coming from Go, Ruby, Python and JS... Well I prefer just writing some JEE stuff rather than using a PHP framework in that case, because I realized the Java cargo culting was just insane in the PHP community and how PHP is poorly equipped to replicate that JEE stack...
PHP isn't going away though, billions of PHP scripts out there to maintain, and CMS are built in PHP mostly because of hosting providers still defaulting to Apache servers because cost.
Nothing is too little too late though, when I read about the evolution of Java, I realize I'm lucky to suffer through it today rather than 15 years ago...
> Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course.
JSP on Tomcat works mostly the same way. and nothing prevents anybody from using python or ruby, (or C++) in FastCGI mode. PHP has that whole "templating stuff" though.
I had to learn JEE(JSP,JSF,CDi,JPA) for some project lately, so now I understand a bit more why Doctrine, Synfony and co are the way they are, coming from Go, Ruby, Python and JS... Well I prefer just writing some JEE stuff rather than using a PHP framework in that case, because I realized the Java cargo culting was just insane in the PHP community and how PHP is poorly equipped to replicate that JEE stack...
PHP isn't going away though, billions of PHP scripts out there to maintain, and CMS are built in PHP mostly because of hosting providers still defaulting to Apache servers because cost.
Nothing is too little too late though, when I read about the evolution of Java, I realize I'm lucky to suffer through it today rather than 15 years ago...
> Its concept of "one endpoint is one script" is one of its biggest killer features that no other language has been able to deploy in such an accessible manner. Well, Perl and old-style CGI aside, of course.
JSP on Tomcat works mostly the same way. and nothing prevents anybody from using python or ruby, (or C++) in FastCGI mode. PHP has that whole "templating stuff" though.
> PHP has that whole "templating stuff" though.
That might be underestimating the feature, it was very much the core proposition of the language and likely why it's so well suited for web applications.
That might be underestimating the feature, it was very much the core proposition of the language and likely why it's so well suited for web applications.
Yes, that's exactly why I'm pointing it out. Neither Python or Ruby have(or had) that.
The big guys, who know what they're doing use PHP because it makes devops stupid simple. Throw it on the server, its ready. That's always been PHP's killer feature.
Is it? Last time I used PHP (around 5.x-7.x) it was exactly the other way around. For production you needed php-fpm, nginx, opcode cache... it was a nightmare compared with go or even java.
Is it better now?
Does anyone really deploy PHP directly on servers still..? Running it in a Docker container is the simplest thing possible, runs anywhere, and has top-notch performance.
I meant Docker. The fact that I needed multiple processes (nginx+fpm) made PHP setup tricky compared with e.g. Java with embedded server.
I know what you mean; that has been a problem in the past. In case you have to again, I'd recommend looking into either Roadrunner or Swoole. That makes it possible to have your application run more or less standalone in a single container, hosted by a native application server. This boosts performance incredibly, and exposes a single HTTP port, as it should be.
For Symfony: https://github.com/k911/swoole-bundle
For Laravel: https://laravel.com/docs/8.x/octane
For Symfony: https://github.com/k911/swoole-bundle
For Laravel: https://laravel.com/docs/8.x/octane
aha, that looks good. Thanks
The opcode cache is built in now. A webserver and php-fpm are still a good idea.
I think the thing is, you install those once, and then you can run an infinite number of websites.
They also share the same resources, so even your little blog can take as much (or more) traffic than your production application.
They also share the same resources, so even your little blog can take as much (or more) traffic than your production application.
More funny is how developers keep being unware that ARC is a GC algorithm implementation.
Then they tell learning CS theory is not required.
Then they tell learning CS theory is not required.
I do know ARC is also a garbage collector, but is there an agreed name for the other GC's? There is a significant difference and performance implications with ARC vs. the other ones, that's what I meant.
You mean being the worse implementation of any GC algorithm, unless it makes use of tracing GC like optimizations, e.g. hazard pointers with deferred collection? Maybe.
Naturally there are agreed names for other GC's, that is what widely acknowledged books in CS like "The Garbage Collection Handbook" [0], or papers like "A unified theory of garbage collection" [1] go about describing.
[0] - https://gchandbook.org/
[1] - https://dl.acm.org/doi/10.1145/1028976.1028982
Naturally there are agreed names for other GC's, that is what widely acknowledged books in CS like "The Garbage Collection Handbook" [0], or papers like "A unified theory of garbage collection" [1] go about describing.
[0] - https://gchandbook.org/
[1] - https://dl.acm.org/doi/10.1145/1028976.1028982
> pretty much the only dynamic language in use today with ARC and not a GC
Python uses RC, with GC available but only used for cycles.
Python uses RC, with GC available but only used for cycles.
Slow change is good for small projects that you want to build once and use for decades without much maintenance.
A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die before it evolves into something sensible. Not that I believe PHP will die any time soon, but just replying to your "slow is good".
There is no real producticity gain through not having semicolons and somewhat leaner syntax. That was never the bottleneck: ecosystem, libraries are.
There is a real productivity gain when you remove all things that cause a mental tax on reading. After Swift I don't want to look back at the C-like syntax languages any more (just that occasionally I have to).
You may think so subjectively. But there is no objective study whatsoever that would support that.
I do like dollar vars, because I know immediately when it's a variable and don't have to rely on syntax highlighting.
> A language that uses archaic syntax with dollar vars, semicolons, is pretty verbose itself may die
Careful there :-) Modern javascript has semicolons and is introducing pretty horrendous syntax for private variables (an octothorpe) and possibly for the pipe operator (percent sign, was it?) and for tuples and records, yet is showing no signs of dying.
Careful there :-) Modern javascript has semicolons and is introducing pretty horrendous syntax for private variables (an octothorpe) and possibly for the pipe operator (percent sign, was it?) and for tuples and records, yet is showing no signs of dying.
I have never written JS with semicolons after 2015 idk why you are saying Modern JS has semicolons? I simply didn't get it. Am I missing something.
I mean, it clearly has them; it's part of the syntax. You can skip them, and the parser will insert them for you; but the language has them.
yea but its optional so does it matter? In PHP its compulsory, right?
Sometimes the extra options can produce unexpected problems. For example, in JavaScript, this would return nothing and may result in an unreachable code warning:
There are no hidden gotchas like this in PHP though since semicolons are always used:
function go() {
return
5 + 3;
}
console.log(go())
There are no hidden gotchas like this in PHP though since semicolons are always used:
function go() {
return
5 + 3;
}
var_dump(go());
It's still in major use across the industry so I don't think it's too little too late. Maybe late, but not too late. I think it's pragmatism is partly why it's still so popular. No need to rush to the next best thing as PHP is perfectly capable of taking you from side-project to enterprise software with millions of users.
There is a garbage collection:
https://www.php.net/manual/en/features.gc.php
> This section explains the merits of the new Garbage Collection (also known as GC) mechanism that is part of PHP 5.3.
> First of all, the whole reason for implementing the garbage collection mechanism is to reduce memory usage by cleaning up circular-referenced variables as soon as the prerequisites are fulfilled. In PHP's implementation, this happens as soon as the root-buffer is full, or when the function gc_collect_cycles() is called. In the graph below, we display the memory usage of the script below, in both PHP 5.2 and PHP 5.3, excluding the base memory that PHP itself uses when starting up.
https://www.php.net/manual/en/features.gc.php
> This section explains the merits of the new Garbage Collection (also known as GC) mechanism that is part of PHP 5.3.
> First of all, the whole reason for implementing the garbage collection mechanism is to reduce memory usage by cleaning up circular-referenced variables as soon as the prerequisites are fulfilled. In PHP's implementation, this happens as soon as the root-buffer is full, or when the function gc_collect_cycles() is called. In the graph below, we display the memory usage of the script below, in both PHP 5.2 and PHP 5.3, excluding the base memory that PHP itself uses when starting up.
PHP's garbage collector is ARC, unlike any other dynamic language that I know of.
ARC is more performant but can introduce memory leaks via circular references, which is probably not a big problem for short-lived scripts anyway.
ARC is more performant but can introduce memory leaks via circular references, which is probably not a big problem for short-lived scripts anyway.
Python uses ARC plus a tracing GC for dealing with cycles, same as PHP: https://devguide.python.org/garbage_collector/
Perl uses ARC with no tracing GC, so you have to handle cycles yourself: https://www.perlmonks.org/?node_id=1173079
TCL uses ARC, and apparently doesn't need a tracing GC because it is impossible to create cycles in it: https://wiki.tcl-lang.org/page/Garbage+collection
Perl uses ARC with no tracing GC, so you have to handle cycles yourself: https://www.perlmonks.org/?node_id=1173079
TCL uses ARC, and apparently doesn't need a tracing GC because it is impossible to create cycles in it: https://wiki.tcl-lang.org/page/Garbage+collection
ARC is not more performant, it's more deterministic. "regular" GCs have better throughput. RC in general also handles other resources (like files) a bit better than GC.
I'm not sure if you did not read what I quoted, or I misunderstand something.
Yes, PHP has reference counting, but it also has specific process that kicks in to clean up circular references.
Yes, PHP has reference counting, but it also has specific process that kicks in to clean up circular references.
How is it more performant? If you have multiple threads than you will get serious atomic operation or other synchronization overhead.
PHP is share-nothing architecture. Nobody really uses threads in mainline PHP.
Whole class of problems around multi-threading, mutexes, dead locks etc. are really foreign to PHP developers.
Whole class of problems around multi-threading, mutexes, dead locks etc. are really foreign to PHP developers.
Yeah, I should have mentioned that in the general case RC is not more performant (otherwise threaded managed languages would use it).
PHP has a GC since 2009 (version 5.3). Its goal is precisely to collect reference cycles.
> Is it just me or PHP's evolution is a bit "too little, too late" for an almost 30-years old language?
No. While PHP won't be the language of choice for academia or some new hipster startup that wants to woo junior engineers with the promise of "we're using the latest cool shit", the trio of PHP, Java and .NET with their associated ecosystems has managed the fine balance of evolution speed between uprooting everything on the regular (like NodeJS which went through at least three major build toolings with zero compatibility and the Javascript language itself with at least four ways of creating modules) and becoming a live fossil (like Perl) pretty well.
No. While PHP won't be the language of choice for academia or some new hipster startup that wants to woo junior engineers with the promise of "we're using the latest cool shit", the trio of PHP, Java and .NET with their associated ecosystems has managed the fine balance of evolution speed between uprooting everything on the regular (like NodeJS which went through at least three major build toolings with zero compatibility and the Javascript language itself with at least four ways of creating modules) and becoming a live fossil (like Perl) pretty well.
A typical Java project has way more complexity (and confusion and sadness and pain) than your typical node.js project in the enterprise world. I have stomach cramps thinking about the stuff my eyes have seen. .NET is not innocent either.
For PHP, just look at the Drupal, Joomla and Wordpress codebases to see how many ways there are to include files. For a current example, see the hate Laravel receives on how it does DI from Symfony-likers. There's also the Laminas (Zen) crowd going all-Java.
If something is popular, there WILL be many ways to do the same thing. Look at how Python is evolving.
For PHP, just look at the Drupal, Joomla and Wordpress codebases to see how many ways there are to include files. For a current example, see the hate Laravel receives on how it does DI from Symfony-likers. There's also the Laminas (Zen) crowd going all-Java.
If something is popular, there WILL be many ways to do the same thing. Look at how Python is evolving.
> A typical Java project has way more complexity (and confusion and sadness and pain) than your typical node.js project in the enterprise world.
Personally, in my career I've seen and worked with projects in SAP, Java (Tomcat), .NET, PHP and various JS-based projects - of all these, the JS projects had the most variety of bullshit (although SAP still gets the cake for "stuff I'll never willingly work with again" simply because how mind-boggling the entire environment is).
At least it's easy enough to get a bunch of Java developers to agree on what package manager and build tool they will be using - it will mostly be Maven and that's it.
For a nodejs project, you will first have to decide on the framework to choose, then on the build tool because not every framework works with every build tool, then you will lose a lot of time until Webpack finally does what you want, and in a year half the libraries you use will be unsupported.
Personally, in my career I've seen and worked with projects in SAP, Java (Tomcat), .NET, PHP and various JS-based projects - of all these, the JS projects had the most variety of bullshit (although SAP still gets the cake for "stuff I'll never willingly work with again" simply because how mind-boggling the entire environment is).
At least it's easy enough to get a bunch of Java developers to agree on what package manager and build tool they will be using - it will mostly be Maven and that's it.
For a nodejs project, you will first have to decide on the framework to choose, then on the build tool because not every framework works with every build tool, then you will lose a lot of time until Webpack finally does what you want, and in a year half the libraries you use will be unsupported.
Are you sure? There's gradle and others. Also which server? Wildfly, jboss, jetty, glassfish, soemthing else? Which java distribution? Perhaps you want to use vertx, tapestry, undertow instead of good old Spring? Maybe Grails? Which testing framework? Some people love their JSF (yes!), is it still really, like for real supported? Should you use JSP? I mean from configuration to configuration so much changes that I don't touch undockerized Java projects. It's just too much work. In one case one experienced Java dev struggled to get me a working dev env for a week. Even IDE extensions sometimes play a role in the build in Java world. Give me a break.
> That, and also the fact that it may be pretty much the only dynamic language in use today with ARC and not a GC.
Python and Perl use reference counting too. Ruby, Lua and JS (at least v8) are GC'd. PHP isn't unique in that regard.
Python and Perl use reference counting too. Ruby, Lua and JS (at least v8) are GC'd. PHP isn't unique in that regard.
I think that’s my biggest problem having moved from PHP to Typescript. I just expect my language to have certain features now, and while PHP is catching up, it still isn’t there yet.
And even if they do, what then? It’ll just be feature parity, so there’s no need to switch back either way.
And even if they do, what then? It’ll just be feature parity, so there’s no need to switch back either way.
Isn't ARC over a GC evident in PHP with its opcode cache? I don't think I have run into a PHP dev who thinks PHP has a GC
the very fact that you don't have to think about memory management it means that there is something else taking care of it. Call it GC or otherwise, no PHP dev will be think about memory management at all, unless they are building some long-lived, large data processing
> no PHP dev will be think about memory management at all
Not nowadays, for sure. In 2009-2010 it was still something to keep in mind, and careful array handling was common so the it wouldn't baloon hundreds of megabytes for not so large data structures. I wasn't working on big data (tm) at that time, but running database imports via ETL processes in PHP required a few optimization passes.
I really can appreciate nowadays the huge memory and performance improvements that PHP went through from the 5.x days to the recent 8.1 release.
Sidenote: Shout outs to Nikita Popov who came to the scene and revitalized the language for me back then, for his proposals and features implemented in a time when PHP felt stagnant language wise https://www.npopov.com/aboutMe.html#accepted-php-proposals
Not nowadays, for sure. In 2009-2010 it was still something to keep in mind, and careful array handling was common so the it wouldn't baloon hundreds of megabytes for not so large data structures. I wasn't working on big data (tm) at that time, but running database imports via ETL processes in PHP required a few optimization passes.
I really can appreciate nowadays the huge memory and performance improvements that PHP went through from the 5.x days to the recent 8.1 release.
Sidenote: Shout outs to Nikita Popov who came to the scene and revitalized the language for me back then, for his proposals and features implemented in a time when PHP felt stagnant language wise https://www.npopov.com/aboutMe.html#accepted-php-proposals
i've been working with PHP for almost 20 years and to be honest i've never had to think about memory management until the last 10 years or so and only in case of long running processes (e.g. cronjobs)
PHP is my go to language for building simple backends that store data as json in a file and synchronize access using flock(...). There are a ton of cheap hosting providers that support PHP and all you have do to is copy your files over and everything works.
I love to focus my energy on building a great frontend with React or Vue.
I love to focus my energy on building a great frontend with React or Vue.
In the past I built a few things on Google App Engine. Honestly one of my greatest regrets in life. I ported a few to PHP so I won't get screwed again when I need to change hosting provider. Still need to port some and am dreading doing it but it will be for the better.
Huh. I deploy a lot of stuff to GAE and love it. But my approach is to just write regular Django apps, add a half dozen lines of GAE-specific stuff to the settings and that's it. No trouble at all running the same apps somewhere else with only trivial changes. That's worked really well for me for work where we're already on GCP and GAE lets us run our lower traffic services reliably for very little money.
I was using Datastore and other GAE specific stuff.
It's a shame companies, especially large ones with strategic architecture teams who should know better, haven't identified the short term cost savings of using cloud provider specific services is not worth the long term cost of vendor lock in.
And for startups their recently minted MBA CEOs are too willing to load up on "tech debt" on the race to revenue.
And really, it's not a bad trade - financially. But it will frustrate your eng team, for a bit - especially if you don't actually get the revenue stream going.
And really, it's not a bad trade - financially. But it will frustrate your eng team, for a bit - especially if you don't actually get the revenue stream going.
You have any good simple examples of your backend? Sounds like what I've been attempting to explain to others. How many concurrent requests and what size of data can you run with a setup as described?
Because you asked I got around to publishing it on Github: https://github.com/HASMAC-AS/LightStore
Storing stuff in a json file sounds horrible to me. Why would you want that?
Because your data is teeny tiny, not performance critical, and `json.load` and `json.dump` is easy and usually less brittle then you're language's marshalling library.
Why save 10 minutes on setting up a proper database? Data is never teeny tiny, data is never not performance critical :) These decisions only bite you in the ass.
All my side projects have teeny tiny amounts of data. JSON file in the order of KB. Performance is great.
I have one project with a dozen users that handles around 50 reads per second and maybe 30 writes per day, no issues at all. Setting up a DB for that would just bite the next dev in the behind since it would need a lot more maintenance then an apache server with php.
I have one project with a dozen users that handles around 50 reads per second and maybe 30 writes per day, no issues at all. Setting up a DB for that would just bite the next dev in the behind since it would need a lot more maintenance then an apache server with php.
Setting up a database takes way longer than 10 minutes. Data can be teeny tiny. Data can not be performance critical. You literally know nothing about the commenter’s application.
PHP supports complex data structures using associative arrays which map to the application requirements. Which can be easily saved in JSON. A SQL database with rows and fields does not always work well with these data structures. Often, as long as the data size is manageable, a json saved in a mediumtext field in MySQL works just fine.
PHP gets a lot of criticism for its legacy of behind hacked together. One thing that does get as much criticism, and one reason I avoid it for even simple things, is since it's request-based, it doesn't have a good story for connection pooling. While working on a former employer's PHP SDK, I had to add proxy hooks to it, then document how to set up Apache or Nginx as a proxy so you can get outbound connection pooling. If you depend on any third-party APIs, this can be a big deal for performance.
I've wondered why there's no JSON-based equivalent of SQLite, like "MongoDB but it's just a file and a library."
I think because SQLite ate that market with the JSON extension. I've also seen LMDB used in the wild.
But ... SQLite is "just a file and a library".
Yes, but it's SQL. Some people want a "document database" that looks more like JSON. (Yes, I know you can store JSON in SQLite.)
I'm a fan of PHP and have been for years for several reasons:
1. Low barrier to entry;
2. Hard to leak resources since the model is to tear down everything after a request finishes;
3. Stateless API core which means the efforts of creating an environment for a request for (2) is extremely low. Compare this to, say, the bootstrap time for Python or Java (which is why those generally don't follow the request teardown model);
4. Almost no multithreading.
This makes it great for servicing HTTP requests IMHO.
I need to compare it to Hack/HHVM though since I used that for years and it's still playing catch up with features Hack has had for years eg:
1. Hack has had the async-await model for years;
2. The type system is actually really good. It made me appreciate how nullability being part of the type system is incredibly useful. Plus it's had generics for years; and
3. Better inbuilt collection types with less odd coercion behaviour (ie dict, keyset, vec).
I find PHP hate in 2022 to be tired. Look at something like Laravel and PHP is completely fine. The sins of the past and even the odd inconsistencies still left in the language (eg needle and haystack param ordering) don't really matter.
1. Low barrier to entry;
2. Hard to leak resources since the model is to tear down everything after a request finishes;
3. Stateless API core which means the efforts of creating an environment for a request for (2) is extremely low. Compare this to, say, the bootstrap time for Python or Java (which is why those generally don't follow the request teardown model);
4. Almost no multithreading.
This makes it great for servicing HTTP requests IMHO.
I need to compare it to Hack/HHVM though since I used that for years and it's still playing catch up with features Hack has had for years eg:
1. Hack has had the async-await model for years;
2. The type system is actually really good. It made me appreciate how nullability being part of the type system is incredibly useful. Plus it's had generics for years; and
3. Better inbuilt collection types with less odd coercion behaviour (ie dict, keyset, vec).
I find PHP hate in 2022 to be tired. Look at something like Laravel and PHP is completely fine. The sins of the past and even the odd inconsistencies still left in the language (eg needle and haystack param ordering) don't really matter.
> Compare this to, say, the bootstrap time for Python or Java
The bootstrap time for a request exists only in a web framework, not in the language. And since you can have the extremes of pure fastcgi or uwsgi, or full Django, you need a more specific comparison.
The bootstrap time for a request exists only in a web framework, not in the language. And since you can have the extremes of pure fastcgi or uwsgi, or full Django, you need a more specific comparison.
Java has a high bootstrap time for the JVM. PHP doesn't have that, but the "tear down everything" model might imply a high bootstrap time depending on the framework, because things need to be bootstrapped per request that are already there in Java.
Regarding bootstrap time, have you tried cold PHP, like a cgi script or a PHP script run from shell? Not fast at all. I guess you are comparing PHP with mod_php (or something similar that already has a running interpreter in memory). In that case, it would be fair to compare it against something with JVM in memory, like Tomcat or Jetty.
It seems that PHP (or at least the community) is taking a lot of inspiration from hack for its newer additions, and giving very little in the way of credit or comparisons.
It is weird than an article like this shows nothing for ctrl+f "hack"
It is weird than an article like this shows nothing for ctrl+f "hack"
I think the problem of PHP is the amount of old tutorials/solutions/conventions/etc. Maybe this is the direction all languages take. Eventually the only way to separate yourself from the past is to sever the name link so as to remove the confusion when trying to learn the modern way of interfacing with the language.
Having used Laravel I did feel that was the best version of PHP I had ever used, which while great, each time I use it, I still feel encumbered. It could just be the workflows that PHP provides don’t/haven’t meshed well with the type of endeavors I’ve tried to approach. Or maybe the language just carries too much history.
As an undergrad I made the mistake of attempting to use php solve some bioinformatics homework and ended up reimplementing the k-means algorithm. While that example may be more revealing of my ineptitude for data science it broaches the topic of “where does a language provide the right primitives for the work at hand?” And if the web is changing, is it still appropriate to use a language designed around a previous version of the web?
Having used Laravel I did feel that was the best version of PHP I had ever used, which while great, each time I use it, I still feel encumbered. It could just be the workflows that PHP provides don’t/haven’t meshed well with the type of endeavors I’ve tried to approach. Or maybe the language just carries too much history.
As an undergrad I made the mistake of attempting to use php solve some bioinformatics homework and ended up reimplementing the k-means algorithm. While that example may be more revealing of my ineptitude for data science it broaches the topic of “where does a language provide the right primitives for the work at hand?” And if the web is changing, is it still appropriate to use a language designed around a previous version of the web?
I agree that PHP hate is pretty boring. Nothing beats being able to FTP a few files to deploy a simple dynamic webpage. I still use it for that. But when it comes to building large web apps, I moved on years ago. While I have seen there have been a ton of improvements with some really nice frameworks, there is nothing so crazy innovating about any of it that would make me care to switch back.
I was a php developer for some time two years ago, before switching to go.
I was mainly solving high performance parallel processing and distributed problems.
There are things like ReactPHP which are an awesome achievement, but still every lib you use needs to be developed for ReactPHP.
After learning about go and goroutines I only find it painful to solve these problems in PHP, even using ReactPHP.
I was mainly solving high performance parallel processing and distributed problems.
There are things like ReactPHP which are an awesome achievement, but still every lib you use needs to be developed for ReactPHP.
After learning about go and goroutines I only find it painful to solve these problems in PHP, even using ReactPHP.
So you switched from a language X not designed to do Q to a language Y designed to do Q, presumably because language Y didn't exist when you started doing Q. I imagine that happens all the time, but seldom is it a fault of X. But what I find puzzling is why PHP, of all things, was your choice for these kinds of problems before Go appeared.
Isn't Go like 10 years old now?
More like thirteen. Apparently I misread the comment I was responding to as "for two years some time ago". Now I'm not sure why someone would have chosen PHP for such a task two years ago.
Sorry for unclear phrasing. I meant I used php from 2018-2020.
And honestly I don't know why to use php for the task.
I started at the company 2018 and the tech stack was given.
A good compensation and praising like "PHP has changed and now supports types etc." let me take the opportunity.
My bad, because it took me a lot of time. I needed to do benchmarks were actually PHP turned out to have comparable performance in the scenario under test (concurrent consuming of message Queues and heavily write operations to databases), however it took more than 4 times the effort to get there with php.
In the end I resigned and switched to a new opportunity doing golang solving similar issues.
My point is, that there are folks out there (ab)using PHP for all and everything. And finally php has made a lot of improvements but it is just catching up with other languages. There are still a lot of libraries, that still use older versions and probably never will get updated.
My bad, because it took me a lot of time. I needed to do benchmarks were actually PHP turned out to have comparable performance in the scenario under test (concurrent consuming of message Queues and heavily write operations to databases), however it took more than 4 times the effort to get there with php.
In the end I resigned and switched to a new opportunity doing golang solving similar issues.
My point is, that there are folks out there (ab)using PHP for all and everything. And finally php has made a lot of improvements but it is just catching up with other languages. There are still a lot of libraries, that still use older versions and probably never will get updated.
The problem with PHP in this case has nothing to do with types. So their reasoning was wrong from the very beginning. I suspect that no amount of "catching up" will help here, just like no amount of development will turn future axes into screwdrivers. They'll still work like perfectly good axes, though. Just like PHP will still be able to handle HTTP requests perfectly well.
Yeah not sure why anyone would use PHP nowadays, you can be as productive and more efficient in Go.
Plus you can build just about anything with Go! Whereas PHP is pretty strictly for web development.
Plus you can build just about anything with Go! Whereas PHP is pretty strictly for web development.
fraktl(3)
I use PHP for my backend work. I don't claim to be an expert, but I have been writing in it for over 20 years. I probably started by rewriting PHP-Nuke to emit actually valid XHTML (what a chore -never again). I've written a couple of CMSes in it, and many plugins.
I've done some fairly big stuff, in PHP.
Works a treat. Fast, solid, secure. Widely-supported, great way to have a high "bus factor," because so many people can understand it.
All that said, I never did really like the language. It has always been a necessary evil, for me.
I've done some fairly big stuff, in PHP.
Works a treat. Fast, solid, secure. Widely-supported, great way to have a high "bus factor," because so many people can understand it.
All that said, I never did really like the language. It has always been a necessary evil, for me.
if you are working on PHP projects - dont forget to look into swoole/openswoole. all major PHP frameworks are adopting it now.
this way you can do async and build websocket servers and such and build http applications with event loop and without apache/nginx and such. etc etc
this way you can do async and build websocket servers and such and build http applications with event loop and without apache/nginx and such. etc etc
It's still a language that's mainly used for web development, right?
Modern websites in big companies require pretty complex backends that require data processing queues and other background activities. Can PHP compete with languages such as Go, Python or Ruby in the future?
Modern websites in big companies require pretty complex backends that require data processing queues and other background activities. Can PHP compete with languages such as Go, Python or Ruby in the future?
I'll take this comment as a genuinely curious inquiry instead of the veiled insult that others seem to be taking it as.
PHP is primarily used for web development, yes. That doesn't preclude it from offline processing, however. It's quite nice for quick file processing scripts.
Modern websites do not necessarily require complex backends. It depends on the site and its purpose. A minimal static site is just as modern as an ecommerce behemoth. Or are you using "modern" as a synonym for "complex?"
PHP can compete with languages such as Go, Python, or Ruby in the right circumstances. PHP has a vibrant ecosystem that Go cannot (yet?) match. It has a different feel that may appeal to people that dislike Python's syntax. It can also compare quite well with Ruby, though Ruby on Rails and PHP on Laravel are almost similar enough to make that contest a wash.
PHP is primarily used for web development, yes. That doesn't preclude it from offline processing, however. It's quite nice for quick file processing scripts.
Modern websites do not necessarily require complex backends. It depends on the site and its purpose. A minimal static site is just as modern as an ecommerce behemoth. Or are you using "modern" as a synonym for "complex?"
PHP can compete with languages such as Go, Python, or Ruby in the right circumstances. PHP has a vibrant ecosystem that Go cannot (yet?) match. It has a different feel that may appeal to people that dislike Python's syntax. It can also compare quite well with Ruby, though Ruby on Rails and PHP on Laravel are almost similar enough to make that contest a wash.
To provide an actual data point: I successfully built one of the largest messaging APIs using PHP. We had a horizontally (and dynamically) scalable architecture, ran hundreds of worker nodes in Kubernetes, that processed thousands of messages per second.
The nice things about PHP were:
* Interoperability with the rest of our ecosystem, including the web platform: We could share code and install modules in all projects
* Availability of packages: For lots of common use cases, there are high-quality libraries available, such as process forking, socket communication, or message queues
* Easy to go from PoC to production: Start out with no-brainer arrays, then move to typed data structures easily
I find all the syntax critique on PHP to be completely irrelevant. It's a high-performance, dynamically typed scripting language. I can build the same things in it as with Go, Python or TypeScript, but the ecosystem is stable, tweaking it for production is easy, and it goes from "shoddy hackathon script" to "fully typed, production-grade application" smoothly. There's a single, pretty great package manager; type checking, although limited, works at runtime; code doesn't need to be compiled prior to running. All this makes it a good choice even for big projects to me.
* Interoperability with the rest of our ecosystem, including the web platform: We could share code and install modules in all projects
* Availability of packages: For lots of common use cases, there are high-quality libraries available, such as process forking, socket communication, or message queues
* Easy to go from PoC to production: Start out with no-brainer arrays, then move to typed data structures easily
I find all the syntax critique on PHP to be completely irrelevant. It's a high-performance, dynamically typed scripting language. I can build the same things in it as with Go, Python or TypeScript, but the ecosystem is stable, tweaking it for production is easy, and it goes from "shoddy hackathon script" to "fully typed, production-grade application" smoothly. There's a single, pretty great package manager; type checking, although limited, works at runtime; code doesn't need to be compiled prior to running. All this makes it a good choice even for big projects to me.
Why shouldn't PHP be able to compete here? I personally prefer Python over PHP for stylistic reasons but I have no doubt that PHP is capable of doing the same things as Python, even if the syntax looks a bit more outdated.
Because it wasn't designed for long-running processes or data processing at first. It evolved a lot, but I don't see it outside of simple backends for websites.
> It evolved a lot, but I don't see it outside of simple backends for websites.
I'd say that something like MediaWiki, Wordpress or Drupal exceeds the definition of "simple backend".
Personally, I even tend to write shell scripts in PHP simply because the language is far more sane than Bash (and god forbid naked old sh) and I don't have to fight whitespace with Python.
I'd say that something like MediaWiki, Wordpress or Drupal exceeds the definition of "simple backend".
Personally, I even tend to write shell scripts in PHP simply because the language is far more sane than Bash (and god forbid naked old sh) and I don't have to fight whitespace with Python.
Isn't it funny how (ba)sh always gets a pass and PHP is hated even though bash is a complete insanity?
Does anyone think bash is good though, like some people on this thread seem to believe about PHP?
Wordpress is a complex project, but its backend does not require any background processing.
It does, even Wordpress has a cronjob - scheduled publishes, UGC postprocessing, IP ban expirations, there's a lot going on behind the scene.
Don’t they trigger when a user opens a page?
That applies to Ruby and Python as well.
Not sure about Ruby, but Python is a pretty popular choice. There are tons of open source projects that are used by big players for data processing and complex backends.
Might be used for that, but Python certainly wasn't "designed for long-running processes or data processing at first" which was your original argument.
These 3 languages are pretty comparable in many ways.
These 3 languages are pretty comparable in many ways.
Unless you're doing matrix multiplications, PHP will work reasonably well. It's probably not the right tool for the job (because python's data ecosystem is too deeply entrenched in the ecosystem), but if your codebase is already in PHP, you can easily do long running processes in PHP (similar to how you'd write Rails jobs with ActiveRecord queries in Ruby).
> Can PHP compete with languages such as Go, Python or Ruby in the future?
No. I expect no seriously large projects are started in PHP anymore.
No. I expect no seriously large projects are started in PHP anymore.
Syntax sugar is nice. It helps PHP sidestep the age-old criticism about its crappy API, although the crappy API is still there if you want to use it.
What's really great about PHP these days is the development environment. Composer is a rock-solid package manager. Most frameworks and important libraries are gravitating toward shared standards defined by PSRs. Thanks to those shared standards, the APIs are stable and easy to understand. There's no colors/faker/left-pad drama. Everything just works out of the box and keeps on working. Everything is extensively documented. And somehow the runtime keeps getting faster without breaking backward compatibility.
What's really great about PHP these days is the development environment. Composer is a rock-solid package manager. Most frameworks and important libraries are gravitating toward shared standards defined by PSRs. Thanks to those shared standards, the APIs are stable and easy to understand. There's no colors/faker/left-pad drama. Everything just works out of the box and keeps on working. Everything is extensively documented. And somehow the runtime keeps getting faster without breaking backward compatibility.
> There's no colors/faker/left-pad drama.
Yet. Composer packages have the same attack surface as NPM packages, the only thing that is different is that there are (outside of frameworks like Drupal and Symfony) no automated post-install scripts that get executed during a "composer install".
The fundamental difference is that lots of what is popular in the NPM world isn't needed in the Composer world at all due to PHP's extensive stdlib (meaning, less people having to maintain trivialities like left-pad and thus less potential for people to get hacked/sell out/get burned out in frustration).
Furthermore, most highly popular PHP projects have extensive corporate, consulting or foundational backing - Symfony, Drupal, PHPUnit, Laravel, Typo3, MediaWiki, Wordpress to name the biggest players - and each of these provides to developers what the stdlib is missing, so there are strict QA and release procedures to prevent a repeat of the current colors/faker events.
Yet. Composer packages have the same attack surface as NPM packages, the only thing that is different is that there are (outside of frameworks like Drupal and Symfony) no automated post-install scripts that get executed during a "composer install".
The fundamental difference is that lots of what is popular in the NPM world isn't needed in the Composer world at all due to PHP's extensive stdlib (meaning, less people having to maintain trivialities like left-pad and thus less potential for people to get hacked/sell out/get burned out in frustration).
Furthermore, most highly popular PHP projects have extensive corporate, consulting or foundational backing - Symfony, Drupal, PHPUnit, Laravel, Typo3, MediaWiki, Wordpress to name the biggest players - and each of these provides to developers what the stdlib is missing, so there are strict QA and release procedures to prevent a repeat of the current colors/faker events.
Totally agreed. Despite PHP's reputation as a beginner-oriented, haphazardly designed language, the ecosystem as a whole feels much more mature and well-organized with multiple stakeholders and strong safeguards.
Won’t be long before php is java
You mean the most successful enterprise language and 2nd/3rd most used language overall?
TBH, I don't think PHP is going in that direction.
TBH, I don't think PHP is going in that direction.
No, just in terms of features and syntax. Too bad you can't remove all the bad stuff from php, or any old tech.
This was one of my requests to that new search engine posted here a few days ago.. Filter on minimum version of technology. Should actually just be a field in stackexchange.. packages/languages references + version. And a marker to set if the information is obsolete.
This was one of my requests to that new search engine posted here a few days ago.. Filter on minimum version of technology. Should actually just be a field in stackexchange.. packages/languages references + version. And a marker to set if the information is obsolete.
PHP and Java are indeed superficially similar (this was claimed 20 years ago, too).
You can't get rid of old stuff in the name of BC, but you often simply don't have to use that old stuff. For example, people hate on JavaScript (and PHP too I believe) for the semantics of their "==" operator, but it's a moot point since these languages have had "===" since many years.
You can't get rid of old stuff in the name of BC, but you often simply don't have to use that old stuff. For example, people hate on JavaScript (and PHP too I believe) for the semantics of their "==" operator, but it's a moot point since these languages have had "===" since many years.
If you are enough aware of the differences that you know you should use `===`, the difference becomes moot, because this is not the only unityped footgun on the language, and one of the easiest ones to deal with. The practical problem with `==` is for beginners, and the reason most people refer to it is because it showcases a very large and deep flaw of the language, not because of itself.
> If you are enough aware of the differences that you know you should use `===`
Every beginner knows that because all recent books literally say "don't use ==, use ===", modern IDEs will point it out for you and 1st code review feedback will point it out.
What usage of this moot point showcases for me is mostly author's blind bashing without real knowledge.
Every beginner knows that because all recent books literally say "don't use ==, use ===", modern IDEs will point it out for you and 1st code review feedback will point it out.
What usage of this moot point showcases for me is mostly author's blind bashing without real knowledge.
If you only know "don't use ==, use ===", you will just fall for the next unityped trap. If you know why you shouldn't use `==`, you know enough so that even if you don't go for `===`, using `==` safely is the least of your problems.
> for the next unityped trap
Many languages are unityped and carry the same problems, yet they are hyped rather than bashed (e.g. Python, Ruby).
> If you know why you shouldn't use `==`, you know enough so that even if you don't go for `===`, using `==` safely is the least of your problems.
You have some weird false dichotomy going on. I'm personally in the state "I remember why == is bad (type coercion ...)" but I don't remember all the details to be able to use == correctly. I bet many people are in a similar situation.
Many languages are unityped and carry the same problems, yet they are hyped rather than bashed (e.g. Python, Ruby).
> If you know why you shouldn't use `==`, you know enough so that even if you don't go for `===`, using `==` safely is the least of your problems.
You have some weird false dichotomy going on. I'm personally in the state "I remember why == is bad (type coercion ...)" but I don't remember all the details to be able to use == correctly. I bet many people are in a similar situation.
Your two examples are not unityped, and most unityped languages are unityped all the way down and as a consequence do not have the same problems.
> No, just in terms of features and syntax. Too bad you can't remove all the bad stuff from php, or any old tech.
You can, it just takes ages and dedication and will cause a lot of friction. See: Python's changes between 2.x and 3.x, .NET's breaking changes between 1.x and 2.x+
You can, it just takes ages and dedication and will cause a lot of friction. See: Python's changes between 2.x and 3.x, .NET's breaking changes between 1.x and 2.x+
More like COBOL honestly
use swoole/openswoole with php - async away.
A lot of people here have mentioned Laravel. I think one of the key things about Laravel is that the creator, Taylor Otwell, is only focused on Laravel. Imagine if DHH didn't ever have Basecamp (or 37 Signals) and only focused on Rails and the Rails ecosystem. The Laravel team now has several full time employees working on making the entire Laravel experience as painless as it can be.
Of course Taylor and the Laravel team have paid products, but they are all 100% focused on the Laravel ecosystem and developer experience!
Some of the things that the Laravel ecosystem has as first party packages / services:
Paid:
• Vapor - Serverless Platform. Run your vanilla Laravel apps on Lambda.
• Forge - Server Management. Builds Laravel ready servers on any cloud.
• Envoyer - Zero Downtime Deployment. Deploy your apps with push-to-deploy.
• Nova - Administration Panel. Completely code-driven admin panels.
• Spark - SaaS App Scaffolding. Basically a SaaS starter kit.
Free:
• Horizon - Queue Monitoring. Like Sidekiq
• Jetstream - App Scaffolding. SaaS starter kit with teams, invitations, api, etc.
• Echo - Realtime Events. Think Pusher, Socket.io, etc.
• Sail - Local Docker environment.
• Valet - Dev Environment for Macs.
• Mix - Webpack Asset Compilation. A sane wrapper around webpack.
• Cashier - Subscription Billing Integration. Stripe + Paddle.
• Dusk - Browser Testing and Automation. First party browser automation for tests.
• Sanctum - API / Mobile Authentication.
• Laravel Scout - Full-Text Search. Wrapper around Algolia, Melisearch, or full-text database searching
• Socialite - OAuth Authentication. Log in with GitHub, Google, etc. Dozens of community packages as well.
• Telescope - Debug Assistant.
That's all first party. It's unbelievable to me how many batteries are included. Then you start looking at the surrounding ecosystem beyond that and it gets even crazier.
Laravel as a community is an extremely welcoming place, and I have found that most people care deeply about their code and architecture, but don't pick each other to death on details that don't matter. I think all in all it's a pretty pragmatic group.
If you haven't checked out PHP lately because you think we're writing a file-per-page and FTPing them up somewhere, you should give Laravel a look.
Of course Taylor and the Laravel team have paid products, but they are all 100% focused on the Laravel ecosystem and developer experience!
Some of the things that the Laravel ecosystem has as first party packages / services:
Paid:
• Vapor - Serverless Platform. Run your vanilla Laravel apps on Lambda.
• Forge - Server Management. Builds Laravel ready servers on any cloud.
• Envoyer - Zero Downtime Deployment. Deploy your apps with push-to-deploy.
• Nova - Administration Panel. Completely code-driven admin panels.
• Spark - SaaS App Scaffolding. Basically a SaaS starter kit.
Free:
• Horizon - Queue Monitoring. Like Sidekiq
• Jetstream - App Scaffolding. SaaS starter kit with teams, invitations, api, etc.
• Echo - Realtime Events. Think Pusher, Socket.io, etc.
• Sail - Local Docker environment.
• Valet - Dev Environment for Macs.
• Mix - Webpack Asset Compilation. A sane wrapper around webpack.
• Cashier - Subscription Billing Integration. Stripe + Paddle.
• Dusk - Browser Testing and Automation. First party browser automation for tests.
• Sanctum - API / Mobile Authentication.
• Laravel Scout - Full-Text Search. Wrapper around Algolia, Melisearch, or full-text database searching
• Socialite - OAuth Authentication. Log in with GitHub, Google, etc. Dozens of community packages as well.
• Telescope - Debug Assistant.
That's all first party. It's unbelievable to me how many batteries are included. Then you start looking at the surrounding ecosystem beyond that and it gets even crazier.
Laravel as a community is an extremely welcoming place, and I have found that most people care deeply about their code and architecture, but don't pick each other to death on details that don't matter. I think all in all it's a pretty pragmatic group.
If you haven't checked out PHP lately because you think we're writing a file-per-page and FTPing them up somewhere, you should give Laravel a look.
Yeah, curiously, I think Laravel is just getting started in a way. Taylor seems to have a superb vision about what it is that he wants to achieve with it and in what way, and I don't think the 'rest of us' have fully grasped the 'end-game', and what the implications will be.
I mean, he took the most popular, but somewhat 'not cool anymore' backend programming language with a huge pool of developers, and proceeded to build _the_ way to build server applications with it. If that's not strategic brilliance, I don't know what is.
EDIT: For context. My exposure to Laravel is jumping into some projects and becoming productive in a day without prior exposure to PHP. Largely due to superb documentation and the batteries included approach.
I mean, he took the most popular, but somewhat 'not cool anymore' backend programming language with a huge pool of developers, and proceeded to build _the_ way to build server applications with it. If that's not strategic brilliance, I don't know what is.
EDIT: For context. My exposure to Laravel is jumping into some projects and becoming productive in a day without prior exposure to PHP. Largely due to superb documentation and the batteries included approach.
> Yeah, curiously, I think Laravel is just getting started in a way.
That would be amazing. I agree, I think Taylor has good vision. His overriding principle seems to be "make people's lives easier," which makes for a pretty good ecosystem.
That would be amazing. I agree, I think Taylor has good vision. His overriding principle seems to be "make people's lives easier," which makes for a pretty good ecosystem.
What somewhat more interesting is the marketplaces surrounding some of these. There's a marketplace of nova add-ons, some free, some paid.
Some of these are definitely given more love than others, of course. I'd probably pay for some extended 'dusk' package to provide a better experience overall, but... unsure there's enough of a market to justify that?
I recently learned that the 'envoy' stuff is already free in Laravel - envoyer seems to be a hosted SaaS built with it, but you can define your own 'envoy' stuff to run however you want. https://laravel.com/docs/8.x/envoy
Some of these are definitely given more love than others, of course. I'd probably pay for some extended 'dusk' package to provide a better experience overall, but... unsure there's enough of a market to justify that?
I recently learned that the 'envoy' stuff is already free in Laravel - envoyer seems to be a hosted SaaS built with it, but you can define your own 'envoy' stuff to run however you want. https://laravel.com/docs/8.x/envoy
Love it, Aaron. I've always felt more confident using Laravel knowing that it's backed by a competent entrepreneur. These paid services ensure the longevity of Laravel. We've paid for Spark and Nova, and we have Vapor & Forge subscriptions.
Rails has people who do it full time as well, AFAIK Shopify workers like Rafael Faranca and I'm sure there are quite a few others. Besides them Rails has an army of volunteer committers, its one of the bigger open source framework communities, and the commit distribution is much healthier than Laravel's: Laravel looks like a one man show compared to Rails.
As for all these packages - Ruby has equivalents. It's hard to say what should come included in the framework and how opinionated Rails should be - many people think its already too opinionated.
Wow, Php almost catches up with majority of programming languages!
Can't wait for:
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
- Pattern matching in switch statements (done horribly wrong)
- If, while, and switch expressions
- Inferred type system
- Consistent array method argument order
- Actually usable higher order functions and reflection
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Big reminder: Read beyond decade old articles. This is precisely the tired parroted line people in this post are talking about when they say they don't understand the modern hate.
Does modern PHP have any of:
- Pattern matching in switch statements
- If, while, and switch expressions
- Inferred type system
- Consistent array method argument order
- Actually usable higher order functions and reflection
?Sum types, too, since the enums are C enums.
You could have googled and hated better. Why bother trolling if you won't even give it 40 seconds of using search engines?
PHP was a pretty cool language back in the days. Bizarre (yet fast) stdlib and ugly syntax, but super quick to write web stuff, supported by every shared hosting.
Nowadays, it seems to mimic Java, while having inferior libraries, I'm not sure what's the advantage.
Nowadays, it seems to mimic Java, while having inferior libraries, I'm not sure what's the advantage.
PHP in 2022 has much going for it, the only dark clouds on the horizon is the increasing framework oligarchy within the PHP community, which may reduce innovation and foster a "one size fits all" culture.
Maybe I am just too old and tired, but current PHP has nothing to do with original PHP, version by version it changed direction and the last versions are just yak shaving.
I strongly believe that a programming language should be stable over a longer period of time while bug fixes and behind the scene improvements are fine, but for the developer it should not be a moving target, the manual should not triple in size and developers that know very well version x-1 should have zero problems with version x. There is a huge cost of change and if some people don't care, real life does.
I strongly believe that a programming language should be stable over a longer period of time while bug fixes and behind the scene improvements are fine, but for the developer it should not be a moving target, the manual should not triple in size and developers that know very well version x-1 should have zero problems with version x. There is a huge cost of change and if some people don't care, real life does.
I have worked with many programming languages and what attracts me to PHP the most is the simplicity of its tooling.
Javascript is what PHP should be since day 1.
> Javascript is what PHP should be since day 1.
ReasonML or ReScript is what JS should have been since day 1.
ReasonML or ReScript is what JS should have been since day 1.
It's not fun sir. What's the point of those $$$ mark for variables ? Make no sense at all.
Easy adoption for all levels of programmers is what make it work for enterprise applications now.
Easy adoption for all levels of programmers is what make it work for enterprise applications now.
For one thing, it makes the distinction between language keywords and variables clear - no problems in using `$switch` or `$var`, and even more important, the core devs don't have to take as much care when developing new language features.
Not that I usually use variable names like these, but it quickly becomes automatic to use a dollar sign.
Hey, here’s someone who never saw Perl and doesn’t know how PHP evolved.
Scheme is what JS should have been since day 1.
This is in fact an alternative universe I have thought about quite a bit.
I'm more on the strong-typed side of life nowadays. But otherwise I think it is a good choice. Also: HTML could be expressed in scheme as well. Scheme all the way down.
I'm more on the strong-typed side of life nowadays. But otherwise I think it is a good choice. Also: HTML could be expressed in scheme as well. Scheme all the way down.
Guile in the browser would make plenty of sense had someone not shoved the mess that was early JS into the world.
I see that you've not used Javascript before ES6. I remember a time when the only thing worse than PHP, was Javascript.
id this why js devs rewrite everything in typescript now?
Because it's flexible and type-safe. You have both productivity and scalability on both syntax level and infrastructure level. It's suitable for 99% of programmers and the businesses for now.
But now you need a ton of time to type things.
Only a problem if you're trying to be too inventive with it.
For most cases it's enough to just define interfaces, enums and maybe bundle some of this into discriminated unions. Throw in some generics for good measure. That's not a lot of work.
I've seen people do stuff like dependent types, but unless you're writing a library you don't actually need most of the type system's features.
For most cases it's enough to just define interfaces, enums and maybe bundle some of this into discriminated unions. Throw in some generics for good measure. That's not a lot of work.
I've seen people do stuff like dependent types, but unless you're writing a library you don't actually need most of the type system's features.
There is type inference. And also, it’s not a typing contest, if typing speed is your bottleneck in programming you are doing something really badly, I suggest plugging in the keyboard.
As long as wordpress still holds 40% of the sites PHP will be a major language.
In my opinion, all the modern 'script' languages are now adding static-typing one way or another, to make they much robust(python's mypy, typescript,PHP, etc).
I will pick PHP for backend website development, I just want to avoid the async-node-js as much as I can as it's much worse than other options I feel.
In my opinion, all the modern 'script' languages are now adding static-typing one way or another, to make they much robust(python's mypy, typescript,PHP, etc).
I will pick PHP for backend website development, I just want to avoid the async-node-js as much as I can as it's much worse than other options I feel.
What's wrong with async node js? I think the async API is pretty good.
Cool to see it's still kicking and making major improvements
enums in PHP! I've been waiting a long time for this
And now you can wait for them to be used by (std) libs. This kind of features are hard to bolt on later on.
I havent used pho for 10+ years now, but the point is - the tools mostly don't matter. What matters is the result.
Enums with functions. WTF
Many languages has functions in Enums. They are just a specialized Class/Struct. Rust, Swift and Java among many languages has this.
Enums are just special classes no? Why can't they have functions defined on them?
Java enums also have functions.
If they didn't we would need to write separate helper classes.
Can you give a reason why we should not have them?
Can you give a reason why we should not have them?
Java enums are essentially an in-built singleton pattern where only the given entries can exist. They are not necessarily analogous with sum types, even though rust sort of washes the two together.
It's not unreasonable to group functions with the type they operate on.
>>Packagist, now with over 3 million registered versions and more than 300.000 packages
I see PHP continues to import all of the problem of npm into the PHP community, I moved away from php about the time packagist started to gain ground.
I see PHP continues to import all of the problem of npm into the PHP community, I moved away from php about the time packagist started to gain ground.
Packagist actually gets a lots of things right that NPM gets wrong:
1. NPM has a global namespace that was shoe-horned into an organization thing later. Packagist has been namespaced since day one. Using a namespace avoids almost all of typo-squatting issues etc.
2. NPM hosts the code at its end. This means you could review some code on GitHub and it might not match the code that you get. Packagist fetches the code from GitHub (same guarantees as Go)
3. NPM: The package version is defined _inside_ the package.json file. This causes issues, because the NPM registry is not necessarily the source of truth for this data, resulting in weird edge cases, such as this bug[0]. Composer/Packagist on the other hand just syncs tags against GitHub.
4. The whole NPM ecosystem needs a whole lot of additional tooling to actually publish packages on NPM. NPM doesn't support robot accounts (PATs are not bots), so you must provide a token with complete write access to your account to your CI system, which then must build and push a package to NPM. This process being without 2FA has led to a lot of compromises. Every release also needs chores to bump the version in package.json (which doesn't have to match the version in package-lock.json). Packagist side-steps all these issues by setting a webhook on your repo (no write access needed) that can trigger a sync on Packagist end. Ideally, this should just work with an RSS feed, but webhooks are easier to build.
NPM has a lot of good ideas (ability to load multiple versions of the same package for eg), but Packagist isn't a terrible package manager - it works quite well, and you rarely see people tripping over composer like how happens with the Python ecosystem. The PHP community also prefers medium sized packages, so you don't get a thousand dependencies accidentally.
[0]: https://github.blog/2021-11-15-githubs-commitment-to-npm-eco...
1. NPM has a global namespace that was shoe-horned into an organization thing later. Packagist has been namespaced since day one. Using a namespace avoids almost all of typo-squatting issues etc.
2. NPM hosts the code at its end. This means you could review some code on GitHub and it might not match the code that you get. Packagist fetches the code from GitHub (same guarantees as Go)
3. NPM: The package version is defined _inside_ the package.json file. This causes issues, because the NPM registry is not necessarily the source of truth for this data, resulting in weird edge cases, such as this bug[0]. Composer/Packagist on the other hand just syncs tags against GitHub.
4. The whole NPM ecosystem needs a whole lot of additional tooling to actually publish packages on NPM. NPM doesn't support robot accounts (PATs are not bots), so you must provide a token with complete write access to your account to your CI system, which then must build and push a package to NPM. This process being without 2FA has led to a lot of compromises. Every release also needs chores to bump the version in package.json (which doesn't have to match the version in package-lock.json). Packagist side-steps all these issues by setting a webhook on your repo (no write access needed) that can trigger a sync on Packagist end. Ideally, this should just work with an RSS feed, but webhooks are easier to build.
NPM has a lot of good ideas (ability to load multiple versions of the same package for eg), but Packagist isn't a terrible package manager - it works quite well, and you rarely see people tripping over composer like how happens with the Python ecosystem. The PHP community also prefers medium sized packages, so you don't get a thousand dependencies accidentally.
[0]: https://github.blog/2021-11-15-githubs-commitment-to-npm-eco...
> The PHP community also prefers medium sized packages, so you don't get a thousand dependencies accidentally.
I think it was Laravel or Lumen? I tried that one once and was kinda amazed it pulled like 100 packages. In PHP ecosystem, I think that's considered a lot (to be fair, this is few years back). I've worked on fairly large projects (mostly Symfony + Doctrine and PHPUnit) and don't recall seeing so many dependencies.
Now compare this to initialization of any common JS framework starter.
I think it was Laravel or Lumen? I tried that one once and was kinda amazed it pulled like 100 packages. In PHP ecosystem, I think that's considered a lot (to be fair, this is few years back). I've worked on fairly large projects (mostly Symfony + Doctrine and PHPUnit) and don't recall seeing so many dependencies.
Now compare this to initialization of any common JS framework starter.
checked for a fresh laravel install: 110 packages, 40 of those are development dependencies. Of the 70, only 38 are non (symfony/laravel) dependencies.
The PHP ecosystem tends to use packages-for-interfaces, so that ups the count somewhat.
The PHP ecosystem tends to use packages-for-interfaces, so that ups the count somewhat.
Yes, I saw similar numbers (just not in empty projects, but I'm not familiar with Laravel/Lumen - there might have been a good reason for it).
The point is that Composer packages are far from being that granular, we have less dependencies by literally order of magnitude.
The point is that Composer packages are far from being that granular, we have less dependencies by literally order of magnitude.
I think a better measure really is lines of code. A comparison with react is _very unfair to laravel/rails_, with laravel being a full-featured framework, and yet react is still much worse:
laravel/framework:
[1]: create-react-app doesn't split out dev/prod dependencies https://stackoverflow.com/a/44872787/368328
laravel/framework:
no-dev-deps: 307,405 lines of PHP (36MB)
all-deps: 535,383 lines of PHP (58MB)
all-deps: 1,570,720 lines of Javascript + 96417 lines of typescript (348MB)
(no-dev-deps): 264123 lines of Ruby + 23614 lines of C + 17009 lines of JS (55MB)
(all-deps): 332083 lines of Ruby + 23614 lines of C + 18055 lines of JS (54MB)
[1]: create-react-app doesn't split out dev/prod dependencies https://stackoverflow.com/a/44872787/368328
Hating on PHP almost feels like racism. All the arguments are biased or false. I always get sad after clicking on PHP articles on HN.
I feel it's the opposite. Always a lot of people defending PHP in these threads, no criticism allowed. Gives a very misleading picture of the industry - in reality, PHP is not a loved language, it's below Powershell and just over C in the latest ranking[0] with 40% love / 60% dread.
[0]: https://insights.stackoverflow.com/survey/2021#technology-mo...
[0]: https://insights.stackoverflow.com/survey/2021#technology-mo...
This only adds fuel to my argument. Yeah let's post a results on how people FEEL about a language. How is that objective?
I could argue 100% of the 40% of the people actually uses PHP and 100% of the 60% people don't even use it.
I could argue 100% of the 40% of the people actually uses PHP and 100% of the 60% people don't even use it.
You can argue that, but it's not what the question was about. The survey question is:
> Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year? (If you both worked with the language and want to continue to do so, please check both boxes in that row.)
Of course nothing requires survey participants to be honest or to actually totally read and comprehend the question.
> Which programming, scripting, and markup languages have you done extensive development work in over the past year, and which do you want to work in over the next year? (If you both worked with the language and want to continue to do so, please check both boxes in that row.)
Of course nothing requires survey participants to be honest or to actually totally read and comprehend the question.
I've worked in PHP for years. It still makes me nauseous. I would never recommend anybody to learn PHP, it's simply a shitty language all around.
I would argue that racism comes from ignorance and insecurity.
A lot of frustration with PHP comes from using it a lot (not ignorant) and not enjoying it. They want to be better programmers than they language would allow.
Granted, PHP has improved a lot since I last used it (2004). I think a lot of the arguments were true, but are no longer valid.
A lot of frustration with PHP comes from using it a lot (not ignorant) and not enjoying it. They want to be better programmers than they language would allow.
Granted, PHP has improved a lot since I last used it (2004). I think a lot of the arguments were true, but are no longer valid.
And juvenile programming language tribalism. You could compile hundreds of pages of ranting about any language and their ecosystem if you wanted to. Some people need to learn that just because you prefer one thing over the other it doesn't mean all the other things suck.
I also suspect a lot of the people complaining about X language/platform/ecosystem are not even using them in production environments judging by their very idealized view on building software.
I also suspect a lot of the people complaining about X language/platform/ecosystem are not even using them in production environments judging by their very idealized view on building software.
Wait, what, really? PHP has come a long way, but is still littered with bad design, weird syntax and trying to be a bad Java with no threads and worse scalability.
You're perhaps joking, but victims of actual racism might not think that's funny.
I'm not joking and it's not supposed to bu funny. It's supposed to be confrontating.
Example: Someone saw some bad PHP code once in their lives and think all PHP code is bad. They saw someone say bad things about PHP so they think all PHP is bad. Or they think PHP is bad because they don't like how it looks.
Example: Someone saw some bad PHP code once in their lives and think all PHP code is bad. They saw someone say bad things about PHP so they think all PHP is bad. Or they think PHP is bad because they don't like how it looks.
Are you thinking about prejudice instead?
[deleted]
[deleted]
> All the arguments are biased or false.
All of them?
All of them?