PHP in 2019(stitcher.io)
stitcher.io
PHP in 2019
https://stitcher.io/blog/php-in-2019
490 comments
Agreed, Laravel provides the best dev experience in the PHP world.
The funny thing is that Laravel basically took the Ruby on Rails philosophy and applied it to PHP. Just looking at their site it's clear they have a very similar vision: simple, fast and fun. One can always find differences but the basic principles are the same.
IMO this is great kudos to the Laravel guys, whatever language I use I always look for the tooling that follows the KISS principle. In PHP you have Laravel, in Java/SCala you have PLay, etc.
I need to add that, because of the job, I did a lot of PHP, Ruby, Java, Javascript with many different frameworks and I can say that Rails is still the best for me when it comes to dev experience if you need to move fast. Laravel has come a long way but it's still not at the same level of maturity in terms of tooling and ecosystem. As a bonus with Rails you use Ruby which is designed for programmer productivity and fun.
Anyway, whatever language/framework you use just keep it simple, that's the most important decision you can make for the health of your project.
The funny thing is that Laravel basically took the Ruby on Rails philosophy and applied it to PHP. Just looking at their site it's clear they have a very similar vision: simple, fast and fun. One can always find differences but the basic principles are the same.
IMO this is great kudos to the Laravel guys, whatever language I use I always look for the tooling that follows the KISS principle. In PHP you have Laravel, in Java/SCala you have PLay, etc.
I need to add that, because of the job, I did a lot of PHP, Ruby, Java, Javascript with many different frameworks and I can say that Rails is still the best for me when it comes to dev experience if you need to move fast. Laravel has come a long way but it's still not at the same level of maturity in terms of tooling and ecosystem. As a bonus with Rails you use Ruby which is designed for programmer productivity and fun.
Anyway, whatever language/framework you use just keep it simple, that's the most important decision you can make for the health of your project.
It's funny, I remember when I started working on my first PHP framework, I knew about Drupal, CodeIgniter, Kohana, Symfony and Ruby on Rails. Back then, Symfony was the Ruby on Rails applied to PHP. And I wanted to have a more "php-like" approach to everything. That's when I made phponpie.com (the early attempt).
Fast forward to now. After 10 years there is https://qbix.com/platform . If you're reading this and know PHP / LAMP, I would encourage people here to try it and give me feedback. I've never really spent time growing the community or popularizing it like Laravel. But at every turn, it's made decisions that are as close to PHP and standards as possible.
In particular, the Db module may be better than Doctrine, for example.
Fast forward to now. After 10 years there is https://qbix.com/platform . If you're reading this and know PHP / LAMP, I would encourage people here to try it and give me feedback. I've never really spent time growing the community or popularizing it like Laravel. But at every turn, it's made decisions that are as close to PHP and standards as possible.
In particular, the Db module may be better than Doctrine, for example.
> I knew about Drupal, CodeIgniter, Kohana, Symfony and Ruby on Rails.
I was a huge fan of PyroCMS which was based on Code Igniter. I stopped using it when the all of the JS frameworks exploded. I went back last year to check on them and found out they moved to Laravel.
https://pyrocms.com/
The community since then has grown by leaps and bounds. Good to see the Pyro team still out there making a great CMS.
I was a huge fan of PyroCMS which was based on Code Igniter. I stopped using it when the all of the JS frameworks exploded. I went back last year to check on them and found out they moved to Laravel.
https://pyrocms.com/
The community since then has grown by leaps and bounds. Good to see the Pyro team still out there making a great CMS.
I used both Laravel and Symfony but I ended up with the second. I didn’t like the way Laravel’s ORM has its models structured plus the Symfony PHPStorm plugin is a miracle. Your mileage may vary and this is just me but I never quite understood why people ended up loving Laravel so much vs. Symfony.
I used Silex (the symphony micro framework which was merged back into Symfony), which means I'm now using Symfony. I too prefer it to Laravel. I thinks less opinionated maybe?
honestly its ok to have a different opinion, different people prefer different things.
honestly its ok to have a different opinion, different people prefer different things.
I feel Laravel is fantastic for Junior and medior programmers, while Symfony appeals more to seniors.
I’m a senior programmer and love Laravel. But maybe I’m a junior at heart ;)
All the worst projects I've inherited and rescued were Symfony. Developed by senior devs that overengineered. I'm sure newer Symfony is better and there's some good stuff out there but as a decade+ senior engineer I like Symfony components but not the framework. Love Laravel and Lumen and also some of the other microframeworks for some things. Enjoying Laravel Nova right now too.
Perfectly encompasses my experience with it as well. The community of Laravel-focused developers is extremely proactive in sharing best practices and very much encourages simplicity.
Yep. Laravel is basically PHP on Rails. They do a great job with it too.
I dunno... Their home page looks like something out of the Panera Bread playbook looking at the homepage. 'Web artisans'? Why is it 'clean' because it has an absurd amount of whitespace and comments of platitudes for the code example?
"Clever" "marketing" language like this is not unique to Laravel, most frameworks use language like it for tag-lines on their homepage. Pyramid, a framework for Python, even goes with the same "artisan" language. They're just trying to be fun, inspiring, etc
From the home page of a few other frameworks:
Django: "The web framework for perfectionists with deadlines."
Flask: "Web development, one drop at a time"
Express: "Fast, unopinionated, minimalist web framework for Node.js"
Pyramid: "You need a Python web framework that supports your decisions, by artisans for artisans."
Why is it clean? Build an application with Laravel and you'll find out. :) The documentation and community are excellent. I've used many frameworks across many different languages, and (imo) it really is very nice to work in.
It's funny how the most negativity comes from people with very little experience, or at least recent experience, in the thing that they don't like.
From the home page of a few other frameworks:
Django: "The web framework for perfectionists with deadlines."
Flask: "Web development, one drop at a time"
Express: "Fast, unopinionated, minimalist web framework for Node.js"
Pyramid: "You need a Python web framework that supports your decisions, by artisans for artisans."
Why is it clean? Build an application with Laravel and you'll find out. :) The documentation and community are excellent. I've used many frameworks across many different languages, and (imo) it really is very nice to work in.
It's funny how the most negativity comes from people with very little experience, or at least recent experience, in the thing that they don't like.
It’s not funny. People who have bought in something have (1) to rationalize their choice and (2) cheer so the project remains alive and a major contender.
That's not my experience at all. Most developers I know have worked with technologies before and come out saying, "I would rather use something else next time."
They should have used "Laravel: The Framework Thomas Kinkade Would Have Created."
Glad I'm not the only one who thinks "modern PHP" struggles to fit more than a couple of lines of real code on a screen surrounded, as it is, by space-wasting nonsense such as block comments, blank lines and K&R brace style. No wonder people prefer Ruby. Around the time of PHP5 the language ditched its own identity and sought to become the scripting version of Java. Give me back my procedural PHP4.
Lol, I agree their packaging looks a bit different but the contents of the package are basically the same.
Working with both Laravel and Rails will make it clearer that they try to follow the same principles of convention over configuration and programmer happiness :).
Working with both Laravel and Rails will make it clearer that they try to follow the same principles of convention over configuration and programmer happiness :).
PHP frameworks crack me up. They so often claim they're "powerful." What does that mean exactly, who is that language aimed at?
Then there is Laravel, why "artisans?" The word generally means pre-industrial. In my mind, that evokes devs doing edits on live code. Also, "Laravel" sounds like something to do with larvae.
Then there's Drupal, which for the longest time was "community plumbing," which did match the experience of having to call someone in for mysterious specialist emergencies.
Then there is Laravel, why "artisans?" The word generally means pre-industrial. In my mind, that evokes devs doing edits on live code. Also, "Laravel" sounds like something to do with larvae.
Then there's Drupal, which for the longest time was "community plumbing," which did match the experience of having to call someone in for mysterious specialist emergencies.
(Can't edit. I meant the word "powerful," not the language PHP).
I don't like their code and architecture though. The code is ugly because it is built around static methods instead of proper OOP, and uses magic methods a lot. It is not easy to read.
Also, they love to invent their own names for existing things. For example, they named a folder with interfaces as "Contracts", although there are only interfaces.
You are using "Ruby on Rails" as some sign of quality, but if it uses magic and static methods like Laravel, I would consider it ugly too. Also, I remember reading somewhere that they were hotpatching imported modules. Luckily in PHP you cannot do it.
Also, they love to invent their own names for existing things. For example, they named a folder with interfaces as "Contracts", although there are only interfaces.
You are using "Ruby on Rails" as some sign of quality, but if it uses magic and static methods like Laravel, I would consider it ugly too. Also, I remember reading somewhere that they were hotpatching imported modules. Luckily in PHP you cannot do it.
> it is built around static methods instead of proper OOP
The fake case against Laravel that never dies . The truth is found in the docs: https://laravel.com/docs/5.8/facades
> Facades provide a "static" interface to classes that are available in the application's service container. Laravel ships with many facades which provide access to almost all of Laravel's features. Laravel facades serve as "static proxies" to underlying classes in the service container, providing the benefit of a terse, expressive syntax while maintaining more testability and flexibility than traditional static methods.
The fake case against Laravel that never dies . The truth is found in the docs: https://laravel.com/docs/5.8/facades
> Facades provide a "static" interface to classes that are available in the application's service container. Laravel ships with many facades which provide access to almost all of Laravel's features. Laravel facades serve as "static proxies" to underlying classes in the service container, providing the benefit of a terse, expressive syntax while maintaining more testability and flexibility than traditional static methods.
What isn't fake is that Laravel uses magic methods everywhere, especially in the ORM layer.
There are way too many magic things happening under the hood for my taste.
There are way too many magic things happening under the hood for my taste.
Laravel is moving away from magic methods to using facades, FWIW.
The static methods you are seeing are by and large facades -- convenience methods -- but Laravel is still absolutely "proper OOP."
https://laravel.com/docs/5.8/facades
"Contract" is not a term they invented; it's a term from "design by contract programming," and Laravel enforces the "contracts" through interfaces.
https://en.wikipedia.org/wiki/Design_by_contract
(And, no, they did not invent the term "facade," either.)
https://laravel.com/docs/5.8/facades
"Contract" is not a term they invented; it's a term from "design by contract programming," and Laravel enforces the "contracts" through interfaces.
https://en.wikipedia.org/wiki/Design_by_contract
(And, no, they did not invent the term "facade," either.)
If you think Rails is ugly you're going to have to frame this with what you think is beautiful so we know where you're coming from.
Rails does take a lot of established concepts like MVC and mangles them pretty badly, but the Rails version of MVC works well in practice if you're willing to overlook how unconventional it is. The beauty is not in the adherence to dogma, but the day-to-day experience of using it when you know how it works.
It takes surprisingly little code to do some complex things in Rails. I'm working with GraphQL now and it's stupid easy to build out an API with Rails.
Laravel might seem all sorts of "wrong" to someone who has expectations of "how things should be", but the Laravel way, when accepted for what it is, works. It provides structure and cohesion which in the PHP world is in extremely short supply.
Rails does take a lot of established concepts like MVC and mangles them pretty badly, but the Rails version of MVC works well in practice if you're willing to overlook how unconventional it is. The beauty is not in the adherence to dogma, but the day-to-day experience of using it when you know how it works.
It takes surprisingly little code to do some complex things in Rails. I'm working with GraphQL now and it's stupid easy to build out an API with Rails.
Laravel might seem all sorts of "wrong" to someone who has expectations of "how things should be", but the Laravel way, when accepted for what it is, works. It provides structure and cohesion which in the PHP world is in extremely short supply.
There are comparable things with other frameworks too.
For example I wrote a course on building a SAAS app with Flask. It's available at: https://buildasaasappwithflask.com/
It covers everything about user registration, profiles, subscription billing, 1 time billing, invoicing, and about 50 other things you would likely want to do in a SAAS app or any application really.
The course comes with the source code along with 15+ hours of video explaining every line of code in stages, life time free updates and life time support for close to half the price of what Spark charges just for the source code for 1 site license (with the Flask course you can use the code in however many projects you want).
Spark's business model seems interesting though. I don't use it personally but do you just get the source code and nothing else? How do they limit you to 1 site if you end up with a local copy of the scaffolding / code base?
For example I wrote a course on building a SAAS app with Flask. It's available at: https://buildasaasappwithflask.com/
It covers everything about user registration, profiles, subscription billing, 1 time billing, invoicing, and about 50 other things you would likely want to do in a SAAS app or any application really.
The course comes with the source code along with 15+ hours of video explaining every line of code in stages, life time free updates and life time support for close to half the price of what Spark charges just for the source code for 1 site license (with the Flask course you can use the code in however many projects you want).
Spark's business model seems interesting though. I don't use it personally but do you just get the source code and nothing else? How do they limit you to 1 site if you end up with a local copy of the scaffolding / code base?
Nice! It looks very nice and complete.
I've found this other one in Go lang https://buildsaasappingo.com (I'm not affiliated nor tested it)
I think it is a good idea to turn something that you need for yourself into a side income, I've though about doing this same thing myself in a different language.
What can you tell about your experience building this course, is it worth it ? rewarding ? Did you find difficult to promote it ? what are the main channels to adquiere customers ?
And if you don't mind sharing some numbers, how many people purchased it so far?
I'd like to get an idea on how profitable (or not) and personally rewarding are type of courses, to motivate myself and write one of these one day.
thank you!
edit: I'm thinking maybe that was too many questions, sorry if so, you could create a "meta-course" on explaining all these things and I'd buy it! :)))
What can you tell about your experience building this course, is it worth it ? rewarding ? Did you find difficult to promote it ? what are the main channels to adquiere customers ?
And if you don't mind sharing some numbers, how many people purchased it so far?
I'd like to get an idea on how profitable (or not) and personally rewarding are type of courses, to motivate myself and write one of these one day.
thank you!
edit: I'm thinking maybe that was too many questions, sorry if so, you could create a "meta-course" on explaining all these things and I'd buy it! :)))
That's how the course came into existence.
I built a number of SAAS apps (and apps that had similar functionality) for a few freelance clients. Then I eventually thought "hmm, lots of repeated patterns here, maybe I can make this into a course", so then I made the course.
As for the process. Funny you mention it. The changelog just had me on as a guest for their "backstage" podcast last week where we talked about content creation and the process of recording courses. That's at: http://changelog.com/backstage/4
It covers most of your questions but it doesn't cover nitty gritty details on sales figures and revenue. Thousands of people have signed up for the course but I still do quite a bit of freelancing. Freelancing and course creation is my full time job.
I find it really rewarding at a personal level. I just like creating things, but it is a lot of work. It's not just hitting record and being done in 2 days. Expect it to take 3-6 months of full time work to make a course. Then there's having to keep it updated (because tech changes so fast) and ongoing 24/7 support.
Couple people have asked me to make a course on making courses. Maybe one day but at the moment there's still a bunch of technical courses I still want to make, a million blog posts to write (I have 85 draft posts that are unpublished) and some side projects in the works.
I built a number of SAAS apps (and apps that had similar functionality) for a few freelance clients. Then I eventually thought "hmm, lots of repeated patterns here, maybe I can make this into a course", so then I made the course.
As for the process. Funny you mention it. The changelog just had me on as a guest for their "backstage" podcast last week where we talked about content creation and the process of recording courses. That's at: http://changelog.com/backstage/4
It covers most of your questions but it doesn't cover nitty gritty details on sales figures and revenue. Thousands of people have signed up for the course but I still do quite a bit of freelancing. Freelancing and course creation is my full time job.
I find it really rewarding at a personal level. I just like creating things, but it is a lot of work. It's not just hitting record and being done in 2 days. Expect it to take 3-6 months of full time work to make a course. Then there's having to keep it updated (because tech changes so fast) and ongoing 24/7 support.
Couple people have asked me to make a course on making courses. Maybe one day but at the moment there's still a bunch of technical courses I still want to make, a million blog posts to write (I have 85 draft posts that are unpublished) and some side projects in the works.
wow, serendipity I guess :)
Definitively I'll check the podcast, thanks a lot!
Definitively I'll check the podcast, thanks a lot!
No problem. If you still have questions after the podcast shoot me an email and I'll do my best to answer everything.
Hey thanks for mentioning my book. Like nickjj after building 2 SaaS in Go, I noticed that there were lots of pieces that could be extracted into a library.
I'm currently building another with that library.
I'm currently building another with that library.
Every time I try out Flask, Aiohttp or even Express.js I appreciate more the stuff Django normally does for me.
Django abstracts away a bit too much, if you ask me. For a simple REST API it's complete overkill. I prefer Flask or Falcon[0], in which you don't just get better performance[1] but also a lower level of control.
[0] https://falconframework.org/
[1] https://klen.github.io/py-frameworks-bench/ or https://github.com/the-benchmarker/web-frameworks
[0] https://falconframework.org/
[1] https://klen.github.io/py-frameworks-bench/ or https://github.com/the-benchmarker/web-frameworks
Why exactly do you want a lower level of control?
You want the complete opposite; have as many problems solved for you already with battle-tested ways to break out of the happy path when you need to.
Every sufficiently large Flask app becomes a half-assed reinvention of half of Django, except without the hundreds of thousands of eyeballs and man-centuries of bug fixing.
You want the complete opposite; have as many problems solved for you already with battle-tested ways to break out of the happy path when you need to.
Every sufficiently large Flask app becomes a half-assed reinvention of half of Django, except without the hundreds of thousands of eyeballs and man-centuries of bug fixing.
I agree with your parent. When I started with (Python) webdev some years ago I picked Flask, but nowadays I use Django, as it has superb documentation and useful things built-in. In particular I miss the user-management, authentication and authorization in Flask.
Personally I consider Django without any additional apps less complex than Flask with apps (or "plugins" in Flask jargon) to handle basic stuff like auth.
If performance is a concern, both of them are insufficient and I would rather pick another language like Rust, Go or even Java.
Personally I consider Django without any additional apps less complex than Flask with apps (or "plugins" in Flask jargon) to handle basic stuff like auth.
If performance is a concern, both of them are insufficient and I would rather pick another language like Rust, Go or even Java.
I started with Flask, moved to Django, and now at work am back on Flask. It all depends on what you are building; if you are going to need some ORM, standard auth, etc, Django is a no brainer. However if you are going to be building out much of your own idiosyncratic architecture, Flask gets out of your way and avoids including lots of things you don't need.
For performance, we are building some parts of our system with Clojure. It feels extremely well suited, albeit with some initial learning curve.
For performance, we are building some parts of our system with Clojure. It feels extremely well suited, albeit with some initial learning curve.
How are you implementing REST using Faclon if I might ask ? fully custom ? or is there anything like DRF hanging around ?
Dito.
Really well done site for the course. The flow of the single page to the sign up is compelling.
Seem's like it'd have to be the "honor system". They could certainly add somethings to detect the software being used on multiple domain, but you could ultimately remove that if you were motivated to.
Tokens are issued from within the Spark customer dashboard and the token is required in order to pull the repo during install. It’s basically the honor system.
Thanks.
I noticed they have a public repo with a tool that manages a way to download the spark code base.
I'm guessing without a token you can't access whatever code that public tool pulls down, meaning you need an active token to get future updates of the code base? Pretty cool system if that's the case (there's motivation to keep your purchase to receive updates).
I'm not asking to try and rip him off. I was just curious about the mechanism of protecting the download. Sounds like the only real difference here is the download is done over a command line tool instead of a web interface. Other than that, it's no different than serving a protected file?
I noticed they have a public repo with a tool that manages a way to download the spark code base.
I'm guessing without a token you can't access whatever code that public tool pulls down, meaning you need an active token to get future updates of the code base? Pretty cool system if that's the case (there's motivation to keep your purchase to receive updates).
I'm not asking to try and rip him off. I was just curious about the mechanism of protecting the download. Sounds like the only real difference here is the download is done over a command line tool instead of a web interface. Other than that, it's no different than serving a protected file?
I believe so. Updates are handled through composer package manager and the process is no different than updating a normal Laravel installation. I've never seen any info about how Spark is protected, so I'm just going off of my personal experience using it.
I cut my teeth as a developer on PHP, back in the 4.3 days before they'd really placed their bets on OOP, and we were dealing with mysql_real_escape_string, needles and haystacks, and haystacks and needles. No PDO, XSS and SQL injections up the wazoo.
I can't say I enjoyed working on any of those projects compared to the kind of stuff I do now (and how much I've learned since), but I've been remarkably surprised by some more recent codebases, despite the architecture sometimes feeling a little over-engineered (Symfony 2, for an outdated example).
It's not the style of code I enjoy writing at all but I've seen some incredibly clean stuff that would put a lot of Rails apps to shame. And I'd take that PHP over a badly maintained Rails app any day.
I wouldn't use PHP by choice still, but I no longer care to be snobbish about it. People are doing some good stuff in it, just the same as has happened with JS.
I can't say I enjoyed working on any of those projects compared to the kind of stuff I do now (and how much I've learned since), but I've been remarkably surprised by some more recent codebases, despite the architecture sometimes feeling a little over-engineered (Symfony 2, for an outdated example).
It's not the style of code I enjoy writing at all but I've seen some incredibly clean stuff that would put a lot of Rails apps to shame. And I'd take that PHP over a badly maintained Rails app any day.
I wouldn't use PHP by choice still, but I no longer care to be snobbish about it. People are doing some good stuff in it, just the same as has happened with JS.
Modern PHP is light years ahead of 4.3. Not just the ecosystem, but the language itself, the performance. It's really not bad.
> Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy.
It's also use abysmal amounts for RAM for some reason. I managed to use Chrome headless for my app with only 512MB, but not Composer.
It's also use abysmal amounts for RAM for some reason. I managed to use Chrome headless for my app with only 512MB, but not Composer.
How long ago was that? There were some issues if you had xdebug enabled, but AFAIK that has been fixed.
Just few months and I did not use xdebug on that server. To clarify it's was just CRUD app on Laravel with few small dependencies on top of it. Composer used like 700MB RAM to install it for whatever reason.
Just today, I had to resize the swap on a raspberry pi so composer could update the dependencies.
I've had fun issues recently where Composer crashed after hoovering up 1.5 GB of memory. (Composer sets that limit by itself on startup, I didn't arbitrarily choose that number.) XDebug was off. I fixed it by telling Composer to use unlimited memory.
I had to raise Composer’s RAM limit last week for a fairly simple Symfony project with less than 10 extra dependencies. I had to up it from 2 to 4 gigs. PHP 7.2.8. without xdebug.
To speed up Composer you can install Prestissimo [1] globally, it speeds things up considerably.
[1] https://github.com/hirak/prestissimo
[1] https://github.com/hirak/prestissimo
> Composer, the package distribution system
a package distribution system.
Composer suffers some of the same issues NPM does, IMO: it encourages stuff like 'install dependencies at deployment' and "why write it when you can blindly trust someone else's code".
Not everyone who uses PHP uses Composer.
a package distribution system.
Composer suffers some of the same issues NPM does, IMO: it encourages stuff like 'install dependencies at deployment' and "why write it when you can blindly trust someone else's code".
Not everyone who uses PHP uses Composer.
The vast majority of people using a package manager in the PHP ecosystem are using composer. It makes sense to call it "the" package manager.
I’d argue that the only “the” is one that’s distributed with it, which is PEAR. I’m not saying PEAR is used more or that it’s better, just that it’s the only one close to “default” with the language distributions.
PEAR hasn't been distributed with PHP in well over a decade, and the last commit to the PEAR "modernization" project was in 2011.
PEAR is an abandoned tool used by no one. Arguing for it to be considered "the" package manager is a really weird fight to pick.
PEAR is an abandoned tool used by no one. Arguing for it to be considered "the" package manager is a really weird fight to pick.
I don't like that PEAR by default needs administrator privileges and installs packages into system directories. That's inconvenient because you might have many PHP applications, and each needs different versions of dependencies. What did PEAR developers think? That I will be working on a single app for whole life?
Installing libraries globally is inconvenient for developers. Sadly, most Linux package managers have same problem and do not allow you to install several versions of PHP or Node.
Installing libraries globally is inconvenient for developers. Sadly, most Linux package managers have same problem and do not allow you to install several versions of PHP or Node.
PEAR installation will be disabled by default in PHP 7.4, see https://externals.io/message/103977. It was a good tool, once, but the community has moved on.
pear/pecl are more for installing extensions TO php in my experience, where composer is for installing packages built IN php, so composer is more the defacto community package manager, pear/pecl are useful though when you need to install gmp, gdi, intl, etc on your local dev environment. I don't know anyone who uses pear to install carbon or guzzle, or any other php package though.
I literally know no one who uses PEAR.
I do. I was using it back in 2003... pear/DB. I still have some code from that era that uses it.
Would you use a pear dependency in a new project if you weren't pulling bits in from an older one?
Personally, I wouldn't... I worked with pear and pecl and composer is just far more pleasant to interact with.
Personally, I wouldn't... I worked with pear and pecl and composer is just far more pleasant to interact with.
Which is literally irrelevant to my point.
Last time I used composer (about 3 years ago) it had a nasty memory leak that eventually meant I had to run the build on a higher specced instance than the actual application. This was mainly due to the ridiculous dependancies of the application, but it was almost a show stopper. Has this improved?
Composer is very useful in penetration testing. Lot's of good information in the composer.json files people keep forgetting to block..
A Laravel or Symfony app operates out of the public/ directory, so composer.json shouldn’t need any blocking typically - it’d be outside the web root.
Yeah I remember the problems with composer. It's good now.
It is not a leak, it just loads too much data into memory so you need about 1 Gb of RAM to run composer update.
Yeah, that's not a thing anymore.
I hear you on composer being slow. One thing I found that works extremely well to speed up composer installs:
https://packagist.org/packages/hirak/prestissimo
Give this package a try, it really worked for me to speed up package management with composer.
https://packagist.org/packages/hirak/prestissimo
Give this package a try, it really worked for me to speed up package management with composer.
In my opinion the framework matters more than programming language. One typically doesn't need the "odd" or "fancy" features of a programming language if the framework is well designed and/or a good fit for the shop's conventions or needs.
No doubt its great, but does anyone know how does it compare to django for saas apps?
Honestly I don't see what's all the fuss about Laravel, especially when you compare it to Django. I mean, you have an admin ready out-of-the-box, and database migrations are automatically generated. Correct me if I'm wrong but, Laravel you need to do those things manually...!
Laravel was fantastic. The first month I followed the tutorial, I was bitter about the complexity, but when it came time to building my back end, it took only a few weeks.
I would recommend.
I would recommend.
Laravel is interesting for greenfield stuff. I'm working on a legacy project and we've had a bunch of good times with zend as it allows you to transition to it more naturally piece-by-piece.
kudos to laravel team (and symfony, since IIRC, laravel is built on top of sf bundles)
On one hand, I do see that HN (and probably Reddit) live in a bubble. Where most of the darling languages and tools have very low use in the real-world. And where most of the languages and tooling that actually run the real-world go un-discussed, or simply dismissed, because they're boring and don't appeal to students and entry-level devs working on side projects. I realize that the perspective most rookies get from these forums is completely distorted.
On the other hand, I ALSO think that PHP is only still relevant because of WordPress. The business world runs on Java, and .NET to a lesser extent. I see job postings for Python all the time, as it and the JVM run the worlds of data science and big data. One can even still make a thriving living with Ruby. But I just don't see any recruiter activity around PHP at all. And whereas my Java shop will hire Python or Node junior devs, on the theory that they can learn, we would more likely to skip over a PHP-based resume (if we ever actually saw any).
On the other hand, I ALSO think that PHP is only still relevant because of WordPress. The business world runs on Java, and .NET to a lesser extent. I see job postings for Python all the time, as it and the JVM run the worlds of data science and big data. One can even still make a thriving living with Ruby. But I just don't see any recruiter activity around PHP at all. And whereas my Java shop will hire Python or Node junior devs, on the theory that they can learn, we would more likely to skip over a PHP-based resume (if we ever actually saw any).
Often when there is a post about PHP I read over these treads sort of subtly trying to figure out how a language with such a large user base has remained basically invisible to me. And I don't think I live in the HN bubble, though I do use a lot of Python, in my consulting work I've also done plenty of work with .NET, JVM to a lesser extent and other "boring" tech.
But PHP has literally never come up, even as a suggestion or as a tool that is a small part of the company stack or whatever. It feels like I'm looking into a strange parallel universe of software development reading through these threads. PHP devs, where are you?
But PHP has literally never come up, even as a suggestion or as a tool that is a small part of the company stack or whatever. It feels like I'm looking into a strange parallel universe of software development reading through these threads. PHP devs, where are you?
Right here! PHP and JS/TS is what I do every day.
PHP has its tentacles all over the web: WordPress and Drupal are immensely popular for simplistic sites and short-lived promotionals, Magento and WooCommerce attract many e-commerce users, and Symfony/Laravel handle the custom stuff. I've worked with all of these and have the scars to show for it.
All popular projects have swarms of consultants offering advice, prebuilt additions, and custom development. (E.g. WordPress plugins and themes are everywhere.) This is also a significant factor for the penny-pinching customer — from their point of view, they avoid vendor lock-in and expensive development this way. (Spoiler: it rarely works out, in the end. "Tower of Babylon" and "shallow learning curve" mix in very exciting ways.) So there are masses of people who know the basics of PHP and call themselves "PHP developers". In my opinion, just a fraction of them actually deserves that title.
PHP has its tentacles all over the web: WordPress and Drupal are immensely popular for simplistic sites and short-lived promotionals, Magento and WooCommerce attract many e-commerce users, and Symfony/Laravel handle the custom stuff. I've worked with all of these and have the scars to show for it.
All popular projects have swarms of consultants offering advice, prebuilt additions, and custom development. (E.g. WordPress plugins and themes are everywhere.) This is also a significant factor for the penny-pinching customer — from their point of view, they avoid vendor lock-in and expensive development this way. (Spoiler: it rarely works out, in the end. "Tower of Babylon" and "shallow learning curve" mix in very exciting ways.) So there are masses of people who know the basics of PHP and call themselves "PHP developers". In my opinion, just a fraction of them actually deserves that title.
So I get the sense that PHP is sort of the tool of choice for web development at small or medium businesses which are not primarily software businesses, but are looking to create a website and maybe do some ecommerce? Is that right? If so I guess it makes sense that I wouldn't have seen it, most of my consulting work has been at relatively large enterprises.
Pretty much any shared hosting service (which is the default for a small business not going for a more handheld hosted solution like Squarespace or Shopify) is cPanel enabled with PHP, MySQL (via phpMyAdmin), one-click Wordpress installation, and other similar features.
It definitely feels that way, yes. I've mostly dealt with small businesses looking for the lowest bidder and medium businesses unable to spend a fortune on software licenses and highly-experienced devs, and PHP fits that segment well.
> [WordPress and] Drupal are immensely popular for simplistic sites
That's not a sentence I expected to see. Ever. Drupal is popular for many things but for simplistic sites?
That's not a sentence I expected to see. Ever. Drupal is popular for many things but for simplistic sites?
This may be a regional thing. I've seen Drupal 6/7 on a lot of sites where the original dev threw together five content types in the admin GUI and told the admin how to post new content. It worked well and was certainly less worrisome than seeing (outdated) WordPress.
We run about 1,000 simple websites off the same Drupal codebase. Custom forms, page layouts, etc.
Right here! Started working for a PHP shop straight out of college, and have never been able to get hired for anything else since then.
Right here! Drupal has been moving into the enterprise sector with their latest release (v8, built on Symfony). I get a lot of interest from recruiters based on my Drupal background, especially lately.
Here’s one right here!
In the world I’m in and the journey I’ve taken in my career of being in digital/dev for 10+ years, PHP is what I have based my dev foundations on. (albeit web rather than software)
I am recruiting PHP developers for my team now, and they are out there, but maybe not here?!
We make websites, and not a tremendous amount beyond that bar a few Laravel apps.
I suspect we travel in totally different worlds?!
In the world I’m in and the journey I’ve taken in my career of being in digital/dev for 10+ years, PHP is what I have based my dev foundations on. (albeit web rather than software)
I am recruiting PHP developers for my team now, and they are out there, but maybe not here?!
We make websites, and not a tremendous amount beyond that bar a few Laravel apps.
I suspect we travel in totally different worlds?!
I think the bubble has to do with purists vs pragmatists.
I once joined a Java team as a front-end dev (I'm full-stack). They would do the back-end. They had done everything by the book perfectly. Following all the best practices. But the back-end wasn't doing what it needed to do by a long shot. They were stuck. Meaning I couldn't make progress. So I cooked up a simple (temporary) PHP back-end so I could easily build the needed queries. All nicely secured with LDAP. I was literally running circles around their solution. But it was blasphemy.
Eventually they ported my code into Java. Some portions literally one-to-one. Nobody will ever know the critical role PHP played in this Java success story.
I once joined a Java team as a front-end dev (I'm full-stack). They would do the back-end. They had done everything by the book perfectly. Following all the best practices. But the back-end wasn't doing what it needed to do by a long shot. They were stuck. Meaning I couldn't make progress. So I cooked up a simple (temporary) PHP back-end so I could easily build the needed queries. All nicely secured with LDAP. I was literally running circles around their solution. But it was blasphemy.
Eventually they ported my code into Java. Some portions literally one-to-one. Nobody will ever know the critical role PHP played in this Java success story.
Sounds like they needed a better back-end developer, not PHP.
Java guys didn't ship much at my first real gig. Lots of tooling time and watching movies or discussing Star Trek.
I shipped apps in 2 weeks myself that the company got paid ~70k for. And we kept my clients.
I shipped apps in 2 weeks myself that the company got paid ~70k for. And we kept my clients.
I don't think so. "The bubble" is more about using shiny new languages like go and rust.
I was just talking about with a student who got on to a PHP project with an older developer lead. We decided that PHP is a code smell for a poorly managed project. You know, the kind that were common in the early aughts that featured poor version control practices, no tests, no automation, live changes, live database schema, etc., etc. That's certainly not the way things have to be, but it's never surprising if it is. The root cause is the developer in charge and their reports, but PHP usage is an easy marker to check. We found most examples using other languages (you mention) to be generally better managed in our area/sampling.
> PHP is a code smell for a poorly managed project
Woo, that's a harsh but honest assessment.. Having lived through countless PHP projects, I'd have to say I agree.
> That's certainly not the way things have to be
As the article pointed out, there are new developments in the language, frameworks, tooling, etc., that support better practices and well-managed projects. It's just that the average codebase still tends to be haphazardly organized, idiosyncratic, bloated, complicated, tough to maintain and extend.
The popularity and evolution of PHP have been impressive, and having used it for years I do have some fondness for it. But at some point, I think it becomes necessary to move on to other languages and systems that encourage best practices from the beginning, with a higher baseline/average code quality.
Woo, that's a harsh but honest assessment.. Having lived through countless PHP projects, I'd have to say I agree.
> That's certainly not the way things have to be
As the article pointed out, there are new developments in the language, frameworks, tooling, etc., that support better practices and well-managed projects. It's just that the average codebase still tends to be haphazardly organized, idiosyncratic, bloated, complicated, tough to maintain and extend.
The popularity and evolution of PHP have been impressive, and having used it for years I do have some fondness for it. But at some point, I think it becomes necessary to move on to other languages and systems that encourage best practices from the beginning, with a higher baseline/average code quality.
Well I've been gainfully employed for pretty much my entire career using PHP and I've never had a problem with recruiters. It really depends on the city, the companies in that city, and the overall market in your region.
Big business runs on Java/.NET, but small-midsized businesses run on a variety of different platforms partially based on the history of their IT department and their development needs.
The bottom line is that you can write a good greenfield web application for a midsized business faster, with less overhead, and with fewer headaches using PHP and a good framework than you can with Java or any of those other tools you mentioned. The tradeoff is that they don't integrate as easily with the huge backend software packages and may not scale as well as Java and .NET. Which is why huge businesses don't run with them as much.
Big business runs on Java/.NET, but small-midsized businesses run on a variety of different platforms partially based on the history of their IT department and their development needs.
The bottom line is that you can write a good greenfield web application for a midsized business faster, with less overhead, and with fewer headaches using PHP and a good framework than you can with Java or any of those other tools you mentioned. The tradeoff is that they don't integrate as easily with the huge backend software packages and may not scale as well as Java and .NET. Which is why huge businesses don't run with them as much.
> PHP is only still relevant because of WordPress
There's also Drupal, which is very common in higher ed.
There's also Drupal, which is very common in higher ed.
Indeed, and also Joomla. But the thing with all of these CMS systems is that they're already written. So the related "PHP work" is writing or tweaking plugins for them.
It's kind of like acknowledging the footprint of Microsoft Excel and VBA. Yes, it's quietly a huge deal, and thousands of people hold a job largely because they maintain it for an organization. But it's also the sort of thing one "stumbles into". They don't get hired specifically for that, and it doesn't really transfer to more general developer jobs.
It's kind of like acknowledging the footprint of Microsoft Excel and VBA. Yes, it's quietly a huge deal, and thousands of people hold a job largely because they maintain it for an organization. But it's also the sort of thing one "stumbles into". They don't get hired specifically for that, and it doesn't really transfer to more general developer jobs.
There's still lots of small-fish web development agencies who specifically hire PHP developers.
That's about it though, I think the web development industry is specifically tied to PHP because of their excessive dependence on WordPress, Drupal etc, this also produces developers who are overly specialised in niches using these platforms at the expense of general capability. Think back to the mid-2000's where there was a big difference between a JavaScript developer and a jQuery developer - while they both wrote JS the latter was generally incapable of using vanilla JS proficiently because their use of jQuery's abstractions as a crutch impaired their learning of the underlying fundamentals. A lot of "WordPress developers" are so heavily specialised in using WordPress they probably can't even remember how to write a vanilla PHP site.
That's about it though, I think the web development industry is specifically tied to PHP because of their excessive dependence on WordPress, Drupal etc, this also produces developers who are overly specialised in niches using these platforms at the expense of general capability. Think back to the mid-2000's where there was a big difference between a JavaScript developer and a jQuery developer - while they both wrote JS the latter was generally incapable of using vanilla JS proficiently because their use of jQuery's abstractions as a crutch impaired their learning of the underlying fundamentals. A lot of "WordPress developers" are so heavily specialised in using WordPress they probably can't even remember how to write a vanilla PHP site.
Isn't Facebook running on HipHop PHP?
What about Zalando, one of the biggest platforms out there? They started using Magento and tuning it
What's wrong with Laravel or Symfony?
I don't know if there's anything inherently wrong with them.
I'm just saying that I don't see any job listings for them as an interviewee, or see any resumes with them as an interviewer. In contrast to other technologies that HN or Reddit declare to be "dead" or "dying", yet actually seem to run the world with no serious disruption on the horizon yet.
I'm just saying that I don't see any job listings for them as an interviewee, or see any resumes with them as an interviewer. In contrast to other technologies that HN or Reddit declare to be "dead" or "dying", yet actually seem to run the world with no serious disruption on the horizon yet.
Are you in the US? There are TONS of PHP jobs here in the UK (possibly second to JavaScript, although there are a lot of Java jobs too), and I hear that in general PHP is very popular in Europe, whereas Ruby is more popular in the US (some people use ruby here, but not many).
Laravel is not only fine, but one of the best frameworks I've ever used. It's like rails/django, but less opinionated in all the right ways (while still providing loads out of the box). I think PHP has a very bright future.
Laravel is not only fine, but one of the best frameworks I've ever used. It's like rails/django, but less opinionated in all the right ways (while still providing loads out of the box). I think PHP has a very bright future.
Where do you live? In the US there are a shitload of PHP and Laravel jobs.
Laravel and Symphony, in particular, have the terrible code smell of elongated toolchains, that are specific to the frameworks.
> php artisan serve # laravel
> symphony server:start # symphony
Same poor thinking that NodeJS introduced, albeit less offensively integrated.
If you need additional toolchains, you're not using PHP per se, but another meta-language. There's literally no good reason to do this other than to remove the concept of tradeoffs for a "we know better" or "don't worry about it". These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.
> php artisan serve # laravel
> symphony server:start # symphony
Same poor thinking that NodeJS introduced, albeit less offensively integrated.
If you need additional toolchains, you're not using PHP per se, but another meta-language. There's literally no good reason to do this other than to remove the concept of tradeoffs for a "we know better" or "don't worry about it". These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.
Never met a Laravel developer who actually uses php artisan serve. Sounds like you're fighting windmills.
> Sounds like you're fighting windmills.
Every Laravel developer uses artisan to do something. They were highlighting the names of the magic binaries.
Of course, every Laravel howto starts with a quick guide telling you to use artisan serve, illustrating the point.
Every Laravel developer uses artisan to do something. They were highlighting the names of the magic binaries.
Of course, every Laravel howto starts with a quick guide telling you to use artisan serve, illustrating the point.
I can't speak for symphony, but that's just not the way it works in laravel. The "artisan serve" action is used when you want to make a quick demo (maybe). The actual deployment is in an apache server like everything else.
The rest of the actions that use artisan, for the most part, are for creating boilerplate code like database models or empty controllers quickly. They aren't a requirement to use the framework, but are faster and less error-prone than copy/pasting an old empty class file.
The last class of actions that call artisan are for things like cron jobs which you setup once and forget about. Their use case is pretty obvious once you read the manual.
> These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.
That's nice to hear, but it's probably not true for the majority of people. The entire point for these projects is to allow programmers to create a rapid prototype for design purposes that can then be iteratively developed into a final product. If they don't make sense to you, maybe it's because you aren't working in that space, and not because the tools themselves are lacking.
The rest of the actions that use artisan, for the most part, are for creating boilerplate code like database models or empty controllers quickly. They aren't a requirement to use the framework, but are faster and less error-prone than copy/pasting an old empty class file.
The last class of actions that call artisan are for things like cron jobs which you setup once and forget about. Their use case is pretty obvious once you read the manual.
> These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.
That's nice to hear, but it's probably not true for the majority of people. The entire point for these projects is to allow programmers to create a rapid prototype for design purposes that can then be iteratively developed into a final product. If they don't make sense to you, maybe it's because you aren't working in that space, and not because the tools themselves are lacking.
You make a sweeping statement about a bubble and then demonstrate the edge of yours:
> The business world runs on Java, and .NET to a lesser extent.
Flip those.
> I just don't see any recruiter activity around PHP at all.
This is probably true. My own anecdote: I'm at a primarily-PHP SaaS provider in a major tech hub, and for the couple hires we've made in the last year all of our applicants with extensive PHP experience said we were the only PHP shop they'd talked to, many of them over a year into their job search.
> The business world runs on Java, and .NET to a lesser extent.
Flip those.
> I just don't see any recruiter activity around PHP at all.
This is probably true. My own anecdote: I'm at a primarily-PHP SaaS provider in a major tech hub, and for the couple hires we've made in the last year all of our applicants with extensive PHP experience said we were the only PHP shop they'd talked to, many of them over a year into their job search.
> Flip those.
Nope. That's just incorrect. From Experian to JPMorgan Chase to Cambia Health to Amazon, Java is the typical case for every project. Look at stream processing tools at netflix via any given youtube presentation about stream processing. There are entire tooling segments where .NET is absent, despite their quality tools that run on Windows. Nobody trusts Windows by default and this has mortally wounded .NET
Nope. That's just incorrect. From Experian to JPMorgan Chase to Cambia Health to Amazon, Java is the typical case for every project. Look at stream processing tools at netflix via any given youtube presentation about stream processing. There are entire tooling segments where .NET is absent, despite their quality tools that run on Windows. Nobody trusts Windows by default and this has mortally wounded .NET
Having done a lot of .NET programming at JP Morgan Chase, allow me this Marshall McLuhan in Annie Hall moment ...
I have no idea which language is more popular, but I can certainly list 1,000+ companies including the majority of the Fortune 500 who use .NET in the enterprise.
I have no idea which language is more popular, but I can certainly list 1,000+ companies including the majority of the Fortune 500 who use .NET in the enterprise.
I have worked for all the companies mentioned, of course. Having done a lot of Java programming at JP Morgan Chase, I can confidently say that Java far outstrips .NET usage. Orders of magnitude.
And I can say the opposite is true at Credit Suisse and the Royal Bank of Canada and WalMart and Toyota and Chevron and AT&T ...
What of it.
What of it.
Which one is more popular depends a lot on which country you're in, and sometimes even where in that country.
I think the easiest thing to forget is what made PHP popular was how easy it was to get started writing software that worked good enough. The barrier to entry was incredibly low. It caused a lot of bad code & gave PHP a bad reputation but a lot of good was also made from it.
PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses.
While PHP is nothing like its former self, most people who developed web apps in the first decade of the century will probably always remember PHP for what it was.
PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses.
While PHP is nothing like its former self, most people who developed web apps in the first decade of the century will probably always remember PHP for what it was.
The thing that I like about PHP is that I can mix HTML, code, and database queries into a single file.
This is incredibly useful when learning basic web development, even though it doesn't scale for more complicated applications.
It's also incredibly useful when trying to bang out a simple experiment.
This is incredibly useful when learning basic web development, even though it doesn't scale for more complicated applications.
It's also incredibly useful when trying to bang out a simple experiment.
In the world of machining people will often build a tool for a job. Its a one off, or something that will rarely if ever be used again.
These features of PHP are still eminently useful if you have to do the dirty one off. You can eliminate a massive amount of time pressure (an emergency or time invested vs time saved) if you dont have a ton of overhead that comes with modern frameworks.
These features of PHP are still eminently useful if you have to do the dirty one off. You can eliminate a massive amount of time pressure (an emergency or time invested vs time saved) if you dont have a ton of overhead that comes with modern frameworks.
It also allows you to utilize and extend the full http protocol, something which most "serious" frameworks hinder.
And many of us took the jump and refused to do things that way. You're wrong, PHP scales and you CAN do separation of concerns and have pretty, maintanable code, using a framework or not: just a matter of knowing what you are doing
It's pretty clear that he meant mixing HTML, code, and database queries into a single file was what didn't scale, not PHP itself.
I think you're missing the point of the comment - when it comes to prototyping PHP is incredibly easy to whip out a buggy test thingy in minutes that breaks all best practices but still lets you prove a concept or prep a demo.
> PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses.
Unfortunately it also provided a lot of careers to developers who never got to the "make it" stage.
Unfortunately it also provided a lot of careers to developers who never got to the "make it" stage.
I think it's a bit harsh and elitist to label this with "unfortunately"; for developers like the ones you mention, often their goal or aspiration is not to work in a FAANG or silicon valley startup; they want to make a decent living as a developer in their city and this provides that career for them. Many of those companies aren't trying to be the next unicorn, they're just small dev teams trying to maintain a web site for their business.
Why on earth is that unfortunate? Seems like a positive thing to me, even if some people don't make it to the pinnacle of their craft so what? If someone has gainful employment and meaning in their life I see that as a net positive.
> Why on earth is that unfortunate?
Because many times, they write bad, buggy software. Because other people end up having to maintain it, or fix it, or replace it. Or they release things like plugins that malfunction, but because they're the best out of a set of bad options, end up being the de-facto solution that everyone has to deal with.
I'm not talking about people who build software that works ok, but has bad patterns. I'm talking about people who write cash register software that uses floating-point math to do calculations, or Wordpress plugins that fill up error logs with garbage or nearly DDoS sites because they don't understand how to write efficient code.
Not that I've done any of the above as an early PHP developer, no sir...
Because many times, they write bad, buggy software. Because other people end up having to maintain it, or fix it, or replace it. Or they release things like plugins that malfunction, but because they're the best out of a set of bad options, end up being the de-facto solution that everyone has to deal with.
I'm not talking about people who build software that works ok, but has bad patterns. I'm talking about people who write cash register software that uses floating-point math to do calculations, or Wordpress plugins that fill up error logs with garbage or nearly DDoS sites because they don't understand how to write efficient code.
Not that I've done any of the above as an early PHP developer, no sir...
Writing with PHP is better than ever... and getting better and better.
And... you don't need too worry too much about the server, or the request lifecycle, or networking... you just write your app, in a language which is, in my opinion, going in the right direction with a stronger slant towards OOP and types.
Of course it's still entirely possible to write garbage PHP code... but it's possible to write garbage in anything.
I'm increasingly proud to say I'm a PHP developer; it still gets a lot of bad commentary but it all tends to be based on historical stigmas which are increasingly untrue. Yet all the original benefits are still here, and the language itself is going from strength to strength...
And... you don't need too worry too much about the server, or the request lifecycle, or networking... you just write your app, in a language which is, in my opinion, going in the right direction with a stronger slant towards OOP and types.
Of course it's still entirely possible to write garbage PHP code... but it's possible to write garbage in anything.
I'm increasingly proud to say I'm a PHP developer; it still gets a lot of bad commentary but it all tends to be based on historical stigmas which are increasingly untrue. Yet all the original benefits are still here, and the language itself is going from strength to strength...
My issue with modern PHP is that it's essentially becoming Java. And with the JVM and the Java ecosystem, what is the compelling reason to not just pick Java at this point? With Java you are basically writing exactly what you would be writing with PHP, except with more language features and the ability to opt into other languages on the JVM like Kotlin and Scala.
The modern additions are fantastic for projects and teams that have a specific need to stay on PHP. I still work on projects with PHP and am thankful it has so many improvements. But in its current form and direction, I'm not sure how it has not become simply a little bit worse version of Java.
The modern additions are fantastic for projects and teams that have a specific need to stay on PHP. I still work on projects with PHP and am thankful it has so many improvements. But in its current form and direction, I'm not sure how it has not become simply a little bit worse version of Java.
Interesting analogy, performance wise PHP has made impressive progress. On par with node and the JVM. But Java code specifically is just so bloated. And then there is the worker-per-request model in PHP - All resources isolated to a worker and cleanup on exit. This avoids global garbage collection freezes by design. Something you would get otherwise only from Elixir/Erlang natively. Compared to the JVM that allows PHP applications to scale vertically to any amount of RAM/CPU, and horizontally to any amount of machines. If you let me free choices I'll do Elixir all day long. But pressed on Java vs. PHP for a web app it's PHP for sure.
"On par with node" wow looks fairly close
"on par with JVM" thats a big stretch
Fun stuff here is that PHP hipsters currently gravitate towards node like runtime models. It isn't really eating the platform right now, but I see it as a risk.
I don't get it. Java is bloated but PHP isn't?? PHP has been doing its best since 5.0 to become a Java clone.
Have you ever tried building, deploying and maintaining Java? There is more to a language than the syntax
I have. And honestly, with modern, professional PHP development, most of us are not just FTP'ing PHP code to our shared host to deploy. So realistically, we are dealing with some of that deployment complexity regardless.
The modern Java ecosystem has tooling like Maven and Gradle. IDE support and static analysis in Java is more advanced as well.
As I said above, the additions are fantastic and I think they have absolutely improved the PHP experience for projects where PHP is required. But for new projects, I just do not see deploying PHP vs deploying Java with modern tooling as holding up like it may have 7-10 years ago.
The modern Java ecosystem has tooling like Maven and Gradle. IDE support and static analysis in Java is more advanced as well.
As I said above, the additions are fantastic and I think they have absolutely improved the PHP experience for projects where PHP is required. But for new projects, I just do not see deploying PHP vs deploying Java with modern tooling as holding up like it may have 7-10 years ago.
I agree that once you get a certain size of application, you effectively reduce the complexity of deployment to a small portion of the overall work. In those cases, something like Java is probably appropriate. In fact, most companies leave Ruby/PHP for Java service once they mature.
I was more referring to your statement of using Java over PHP. PHP's syntax may be approaching something like Java, but the differences between the languages are still so vast, that they are only similar in syntax.
I was more referring to your statement of using Java over PHP. PHP's syntax may be approaching something like Java, but the differences between the languages are still so vast, that they are only similar in syntax.
I'm not one to proselytize since I use a handful of languages every day, but when my Java hat is on, I double click a build target, my software is tested, built, deployed side-by-side with my current production build.
New users are automatically pushed to the new build, and users with existing sessions remain on the previous build. When I undeploy the previous build, the rest of the users start seeing the new build as well.
That's all out of the box with small config tweaks for our environment. It is truly torturous.
New users are automatically pushed to the new build, and users with existing sessions remain on the previous build. When I undeploy the previous build, the rest of the users start seeing the new build as well.
That's all out of the box with small config tweaks for our environment. It is truly torturous.
Java is killing itself at a rate of 6 months. They removed javapackager, which means the official tool to build releases is missing from the LTS version.
The EE ecosystem is collapsing thanks to Oracle opposing the Eclipse Foundation, making the quest to build enterprise applications challenging due to namespace collisions and overrides, because of modularisation.
PHP is on this aspect still strong and you can still choose your weapon of choice to build whatever you want and not being hostage of a company.
The only missing part is a good private composer repository for companies who don't release source code.
PHP is on this aspect still strong and you can still choose your weapon of choice to build whatever you want and not being hostage of a company.
The only missing part is a good private composer repository for companies who don't release source code.
You can push libraries privately to GitHub and use with with composer directly, no packagist or anything else required.[0]
[0]: https://getcomposer.org/doc/05-repositories.md
[0]: https://getcomposer.org/doc/05-repositories.md
It looks like Packagist has a private commercial offering: https://packagist.com/
And it even looks like the code for Packagist.org is open source, although not meant for self-hosting as there is no docs, support or BC compatibility guarantee: https://github.com/composer/packagist
And it even looks like the code for Packagist.org is open source, although not meant for self-hosting as there is no docs, support or BC compatibility guarantee: https://github.com/composer/packagist
Except PHP is not Java, and it never can be.
What is PHP's multithreading model again? Hotspot VM? NIO?
I'm sure someone will chime in and cite something similar in PHP, but the comparison will be laughable in reality.
What is PHP's multithreading model again? Hotspot VM? NIO?
I'm sure someone will chime in and cite something similar in PHP, but the comparison will be laughable in reality.
I'm not a concurrency expert (haven't had to do much high-performance stuff), but php does have coroutines like go's --if you use swoole, the performance is actually higher than node in some benchmarks and other multi-threaded / parallel programming paradigms, which comforts me to know that if I have the use case it's there, so I don't necessarily need to drop everything and pick up rust or java or go or another language w/ native concurrency models.
Not saying php is better, there's definitely reasons using rust, elixir, et al would be a better decision for scalability/etc... Just saying it isn't as far off from java, and it's getting JIT I believe in 8.0 (tentatively), whether that improves speed/proficiency is yet to be determined.
That said, I've been a laravel dev since 2013, getting a little bored, so have been branching out and toying w/ other things like clojure, elixir, rust, and node.js for backends to web/mobile apps. Though, laravel is easiest/fastest most of the time to get a project completed by myself.
Not saying php is better, there's definitely reasons using rust, elixir, et al would be a better decision for scalability/etc... Just saying it isn't as far off from java, and it's getting JIT I believe in 8.0 (tentatively), whether that improves speed/proficiency is yet to be determined.
That said, I've been a laravel dev since 2013, getting a little bored, so have been branching out and toying w/ other things like clojure, elixir, rust, and node.js for backends to web/mobile apps. Though, laravel is easiest/fastest most of the time to get a project completed by myself.
In my experience Clojure with Luminus is the quickest for getting something up and running. No brittle ORM to deal with - just HugSQL for turning raw SQL into functions.
Coroutines do not mean that you get parallel execution. Concurrency is not the same as parallelization.
If PHP does not have JIT, then it's nowhere near the speed of Java. Even if it did, Java would likely beat it significantly. I would encourage you to read about Java's Hotspot VM and its adaptive optimizations.
If PHP does not have JIT, then it's nowhere near the speed of Java. Even if it did, Java would likely beat it significantly. I would encourage you to read about Java's Hotspot VM and its adaptive optimizations.
Multithreading is not strictly parallelism, typical discussions of multithreading regard concurrency, and multithreading is what you initially asked about. PHP 7.4 will ship with a JIT as an experimental feature and PHP 8 will ship with it built in standard.
Multithreading in Java means parallelism, which is what I was originally asking about.
You're confused. Nowhere did I claim that multithreading always means parrelalism.
You're confused. Nowhere did I claim that multithreading always means parrelalism.
>What is PHP's multithreading model again
Since it's inception, the PHP implementation hasn't been threadsafe and since, the way of doing paralellism has been process forking. Later iterations where released with support for long-lived processes and threads but it's still not officially "stable" since again, historically the model of process forking made the ecosystem take for granted non-memory safety.
On the other hand, at least since the last time I was doing Java, paralellism is done via multithreading. Sure, there must be someone doing some else out there, but relevant frameworks like Spring work by making 1 thread by http request.
IMHO the right way of dealing with concurrency is the Node way. But comparing the PHP vs Java y think the PHP way is better. In small-medium scale the Java way is obviously more performant. The problem is when you scale to more instances. The PHP way of immutable processes really makes vertical scalling easier.
Since it's inception, the PHP implementation hasn't been threadsafe and since, the way of doing paralellism has been process forking. Later iterations where released with support for long-lived processes and threads but it's still not officially "stable" since again, historically the model of process forking made the ecosystem take for granted non-memory safety.
On the other hand, at least since the last time I was doing Java, paralellism is done via multithreading. Sure, there must be someone doing some else out there, but relevant frameworks like Spring work by making 1 thread by http request.
IMHO the right way of dealing with concurrency is the Node way. But comparing the PHP vs Java y think the PHP way is better. In small-medium scale the Java way is obviously more performant. The problem is when you scale to more instances. The PHP way of immutable processes really makes vertical scalling easier.
PHP scales better than Java? Java is only suited for small to medium scale? That's absurd and you are completely wrong.
Java web servers are multithreaded. Java has JIT. Java has a Hotspot VM with JIT optimizations at runtime.
This is why companies like Google and Amazon run their stacks on Java. It scales. Facebook had to write their own fork of PHP due to performance issues.
Java web servers are multithreaded. Java has JIT. Java has a Hotspot VM with JIT optimizations at runtime.
This is why companies like Google and Amazon run their stacks on Java. It scales. Facebook had to write their own fork of PHP due to performance issues.
>Java is only suited for small to medium scale?
Never said that. What I said was that in the small to medium scale Java was obviously more performant because of the persistent instance & multithreaded model. But beyond that it really is no longer true. The immutable "shared nothing" process forking model of PHP scales horizontally very easily.
>Java web servers are multithreaded
this really is a disadvantage when scalling. The default linux thread stack is 1024k for 64-bit VMs, can't find what's the minium if you tweak it enough. You can see how bad that scalles to thousands of concurrent requests.
And then there's containerization and microservices, where each instance needs a full JVM.
>This is why companies like Google and Amazon run their stacks on Java
You can make anything scale with Google or Amazon budgets.
Again, just listing some pros and cons of both approaches, both of which I think are not even the best.
Never said that. What I said was that in the small to medium scale Java was obviously more performant because of the persistent instance & multithreaded model. But beyond that it really is no longer true. The immutable "shared nothing" process forking model of PHP scales horizontally very easily.
>Java web servers are multithreaded
this really is a disadvantage when scalling. The default linux thread stack is 1024k for 64-bit VMs, can't find what's the minium if you tweak it enough. You can see how bad that scalles to thousands of concurrent requests.
And then there's containerization and microservices, where each instance needs a full JVM.
>This is why companies like Google and Amazon run their stacks on Java
You can make anything scale with Google or Amazon budgets.
Again, just listing some pros and cons of both approaches, both of which I think are not even the best.
You don't seem to understand the basics of how Java web containers work. The thread stack size is irrelevant in most cases. You're going to be using a thread pooled server anyway to handle requests. Conceptually this is no different than using a forked model. You just use a pool of threads instead of processes.
Are you telling me that you run a process pool of thousands of PHP instances on a single machine? I hope not.
Your notion that forked = better is outdated. Running processes has overhead, even with read only shared mem. Micro processes are the way to go, and are being embraced by newer languages. You get min mem and context switching overhead, along with the parallelization of running on multiple cores.
Even so, threads are still going to be lighter weight than forking new "heavy weight" (non micro) processes.
And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc
Are you telling me that you run a process pool of thousands of PHP instances on a single machine? I hope not.
Your notion that forked = better is outdated. Running processes has overhead, even with read only shared mem. Micro processes are the way to go, and are being embraced by newer languages. You get min mem and context switching overhead, along with the parallelization of running on multiple cores.
Even so, threads are still going to be lighter weight than forking new "heavy weight" (non micro) processes.
And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc
>Your notion that forked = better is outdated.
You're beating a strawman here. Nowhere did I make the claim that it was better. I even said multithreading is more performant. The only claim I make is that immutable and shared nothing model of PHP servers makes horizontal scalling more straightforward.
>You're going to be using a thread pooled server anyway to handle requests
That doesn't take away the fact that n parallel requests will require n threads.
>And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc
I don't make any claims here either. Of course Java is faster here. My point was specifically about which model of concurrency and paralellism is better for server IO.
You're beating a strawman here. Nowhere did I make the claim that it was better. I even said multithreading is more performant. The only claim I make is that immutable and shared nothing model of PHP servers makes horizontal scalling more straightforward.
>You're going to be using a thread pooled server anyway to handle requests
That doesn't take away the fact that n parallel requests will require n threads.
>And this doesn't even get into the more efficient compilation. PHP has no JIT yet. There's overhead for type inference. Etc etc
I don't make any claims here either. Of course Java is faster here. My point was specifically about which model of concurrency and paralellism is better for server IO.
>That doesn't take away the fact that n parallel requests will require n threads.
What's your point? In PHP's model, n requests will take n processes. There's no event loop in PHP.
The forked model has nothing to do with making scaling horizontally more straightforward. In either scenario, you'll end up running a different process on another machine once you exhaust your resources.
What's your point? In PHP's model, n requests will take n processes. There's no event loop in PHP.
The forked model has nothing to do with making scaling horizontally more straightforward. In either scenario, you'll end up running a different process on another machine once you exhaust your resources.
> what is the compelling reason to not just pick Java at this point?
Oracle.
Oracle.
The funny thing is, I don’t like java because of all of the historical problems and reputation it has. And I’m a PHP dev.
I really do need to get over all of that and give it another shot.
I really do need to get over all of that and give it another shot.
Even the nature of server-side PHP is bad. Running the script like an executable and using opcache on better case is no good. Also it is not uncommon to upload a php shell using some crappy upload.php forgotten script... Come on, it's Personal HomePage language - you shouldn't do anything bigger than your home page in it.
One of the main takeaways I got from the original Fractal of Bad Design post was the myriad of inconsistencies in both representation and execution of code. This was barely touched upon, mostly this post focused on how PHP has added features and ecosystem. But then so has Javascript.
Unfortunately this is true and it can't be changed, the functions are named and parameters are soemtimes inconsistent like strpos and str_replace, I would have to use the docs all the time if my IDE wouldn't show me the param names.
But after you get productive with PHP there is no feature that I think I am missing from other similar languages.
But after you get productive with PHP there is no feature that I think I am missing from other similar languages.
Features that I miss in PHP:
- expressive type system with generics, union types, literal types, basically TypeScript. I can say "this function returns a string" or "this function returns an array", but not "this function returns an array of strings".
- specialized collection/hashmap data structures with good support across third-party libraries. Having one array() structure acting as both a sequence and an associative array at the same time is awful.
- a templating solution similar to JSX. I am spoiled by TypeScript's ability to typecheck my HTML views along with other code.
- expressive type system with generics, union types, literal types, basically TypeScript. I can say "this function returns a string" or "this function returns an array", but not "this function returns an array of strings".
- specialized collection/hashmap data structures with good support across third-party libraries. Having one array() structure acting as both a sequence and an associative array at the same time is awful.
- a templating solution similar to JSX. I am spoiled by TypeScript's ability to typecheck my HTML views along with other code.
It looks like Facebook had your exact problem; you want Hack:
https://hacklang.org
It's based on PHP, but adds:
Expressive type system with generics:
https://docs.hhvm.com/hack/types/generic-types
Specialized collections: vec, dict, keyset
https://docs.hhvm.com/hack/types/arrays
Templating solution similar to JSX: XHP
https://docs.hhvm.com/hack/XHP/some-basics
https://hacklang.org
It's based on PHP, but adds:
Expressive type system with generics:
https://docs.hhvm.com/hack/types/generic-types
Specialized collections: vec, dict, keyset
https://docs.hhvm.com/hack/types/arrays
Templating solution similar to JSX: XHP
https://docs.hhvm.com/hack/XHP/some-basics
I'm aware of Hack and it's quite nice, but I can't use it because a) my coworkers are … less open to new ideas … and will rightfully resist a "whole new language", whereas mgmt will see it as an attempt at "job security", and b) the biggest use-case for generics is third-party libraries (e.g. [0], [1], [2], [3]) which will never add support if this is not a core language feature.
[0]: https://github.com/doctrine/collections
[1]: https://github.com/schmittjoh/php-option
[2]: https://github.com/schmittjoh/php-collection
[3]: https://github.com/widmogrod/php-functional
[0]: https://github.com/doctrine/collections
[1]: https://github.com/schmittjoh/php-option
[2]: https://github.com/schmittjoh/php-collection
[3]: https://github.com/widmogrod/php-functional
I am not trying to say PHP > TS, just wanted to let you know in case you still work with PHP codebase that you can get good enough type checks with PHPDoc, here is a good example for the case you mentioned , in Intellij the built in linter will mark as warnings when you use types wrong
https://i.imgur.com/NqlAsTd.png (zoom a bit out and sorry for the bad crop)
About the array issue don't we have same situation with JS and TS where you don't have dictionaries or hashmaps in the standard library and you have to use array or object ?
I like JSX too, maybe some PHP template would be made to copy JSX , but not all ages need to be that interactive and not all PHP code is rendering HTML, my current project uses angular1 for the frontend (it was something already created so there was no debate what tool to be used where I could have voiced an opinion).
As a personal opinion I prefer react to angular because I don't like the angular magic compile stuff, I like that react components are JS functions and I can breakpoint into a render functions. I also done some side toy projects with TS, I like it and I hope it gets more popular so new projects would use it but I am worried that we could get a wave of front end languages and we will not have a standard great language but many non standard languages.
About the array issue don't we have same situation with JS and TS where you don't have dictionaries or hashmaps in the standard library and you have to use array or object ?
I like JSX too, maybe some PHP template would be made to copy JSX , but not all ages need to be that interactive and not all PHP code is rendering HTML, my current project uses angular1 for the frontend (it was something already created so there was no debate what tool to be used where I could have voiced an opinion).
As a personal opinion I prefer react to angular because I don't like the angular magic compile stuff, I like that react components are JS functions and I can breakpoint into a render functions. I also done some side toy projects with TS, I like it and I hope it gets more popular so new projects would use it but I am worried that we could get a wave of front end languages and we will not have a standard great language but many non standard languages.
IntelliJ will detect cases like that, yes. But it is difficult and slow to get IntelliJ to inspect your whole project like `tsc` does. With PHPStan or such tools you can do that more easily, but they still have interop problems due to non-standard annotation syntax. Having native support for such type expressions would be much better.
ES6 has Map and Array, which are perfectly sufficient and distinguishable from each other. PHP core only has array() which tries to do everything. You can use array() to build a collection or an associative array and you cannot force it to only behave as one of those. Even Zend's PHP certification contains questions about what happens if you try to push a value into an array that uses associative keys. This is a joke.
I prefer React over Angular as well, but interactivity was not on my list of goals. I want a template syntax that combines valid markup, escaping by default, and TSX-style typechecking. Basically, I want XHP [0]. There is no other template engine for PHP that validates "values passed into this template" against "values used in this template" like TSX can, and no engine that ensures you're generating valid XML/HTML markup. I certainly agree that this is far less important than powerful types, but hey, one can dream :)
[0]: https://github.com/hhvm/xhp-lib
ES6 has Map and Array, which are perfectly sufficient and distinguishable from each other. PHP core only has array() which tries to do everything. You can use array() to build a collection or an associative array and you cannot force it to only behave as one of those. Even Zend's PHP certification contains questions about what happens if you try to push a value into an array that uses associative keys. This is a joke.
I prefer React over Angular as well, but interactivity was not on my list of goals. I want a template syntax that combines valid markup, escaping by default, and TSX-style typechecking. Basically, I want XHP [0]. There is no other template engine for PHP that validates "values passed into this template" against "values used in this template" like TSX can, and no engine that ensures you're generating valid XML/HTML markup. I certainly agree that this is far less important than powerful types, but hey, one can dream :)
[0]: https://github.com/hhvm/xhp-lib
>ES6 has Map and Array,
Bue ES6 is new, I never seen APIs that use Map , I often had to use an Object as dictionary and had to Google how to properly do it not to get extra keys and values from the Object.prototype.
I am not trying to say that PHP is better then TS, but as far as type safety my PHP code with PHPDoc is better type checked then JS code with JSDoc (we are using ES5).
I don't have experience with PHP rendering, but I assume you only have to escape unsafe input, don't have to escape markuup, have you tried twig, is it not safe https://twig.symfony.com/doc/2.x/filters/escape.html ?
I admit I like rendering with react, but I admit that reading a twig template is much simpler then reading JSX code (but I am condemned to use angular :-( ).
Bue ES6 is new, I never seen APIs that use Map , I often had to use an Object as dictionary and had to Google how to properly do it not to get extra keys and values from the Object.prototype.
I am not trying to say that PHP is better then TS, but as far as type safety my PHP code with PHPDoc is better type checked then JS code with JSDoc (we are using ES5).
I don't have experience with PHP rendering, but I assume you only have to escape unsafe input, don't have to escape markuup, have you tried twig, is it not safe https://twig.symfony.com/doc/2.x/filters/escape.html ?
I admit I like rendering with react, but I admit that reading a twig template is much simpler then reading JSX code (but I am condemned to use angular :-( ).
It can be changed.
You have some syntax to opt into a later release (e.g. doing `<?php(version=8)` at the start of a script.
In a major release, you then get rid of a load of cruft.
You have some syntax to opt into a later release (e.g. doing `<?php(version=8)` at the start of a script.
In a major release, you then get rid of a load of cruft.
> You have some syntax to opt into a later release (e.g. doing `<?php(version=8)` at the start of a script.
imagine the exponential complexity as old behaviours need to be kept around for various levels of opting in.
imagine the exponential complexity as old behaviours need to be kept around for various levels of opting in.
I would see it as javascript's strict mode, and I think most devs would ok with a binary switch.
The only fear I'd have is a lack of big entity committed to PHP. In the heydays there was Yahoo, facebook and other giant companies relying on PHP and guaranteeing that there would be enough man power to weather any type of changes. Now I wonder how many people are left to push through breaking changes and rewrite/modernize the libraries and the ecosystem.
The only fear I'd have is a lack of big entity committed to PHP. In the heydays there was Yahoo, facebook and other giant companies relying on PHP and guaranteeing that there would be enough man power to weather any type of changes. Now I wonder how many people are left to push through breaking changes and rewrite/modernize the libraries and the ecosystem.
PHP already has a strict mode as well. It's pretty hard to imagine every developer typing in a long block of compatibility switches at the top of every file and then the mental load of maintaining a code base with some of those on and off.
There's already been a degree of that with php.ini flags, and some of the behaviours available via those flags have been deprecated then removed over a period of years. It's not impossible. Yes, it's complex, but the process for dealing with that complexity has already existed and worked out ... relatively smoothly. The bigger issue is getting people to upgrade - I'm still dealing with a couple of projects - one started in 2017 - that are on PHP 5.6.
That's why you want to do it on a per file basis, not on a per interpreter basis, which allows a project to incrementally move.
You also want a single version, not a gigantic pile of things to opt in to.
You also want a single version, not a gigantic pile of things to opt in to.
The complexity still has to exist somewhere, right? By avoiding this, they're just keeping it in all the developers' heads, rather than a legacy mode in the compiler.
I'm not sure that's the wrong decision, but it's not a great one, either. Too much complexity in the implementation can kill the project. Too much complexity in the language can kill a person's hope of learning it.
I'm not sure that's the wrong decision, but it's not a great one, either. Too much complexity in the implementation can kill the project. Too much complexity in the language can kill a person's hope of learning it.
Many complaints are about the PHP standard libraries and not about the language itself, so you can learn the language just fine and just don't learn the old deprecated functions at all unless you hit such a function in a codebase and tehn you research it. . Is not equivalent to compare PHP+ standard library with JS core , PHP included function to read and write files, streams, databases,json,XML, run executables(if enabled), where in JS or other languages most of this functions are not standard.
The libraries can also be treated in a similar manner.
Named parameters would be nice.
And JavaScript is the best language in the world (with TypeScript).
It's sad how many people think I'm crazy when I say this. No other language feels as good as writing JS with ES6+ features.
Gradual typing (that you can opt-out from) makes for a smooth prototype-to-production experience. Wish more languages supported it.
The thing that matters is language consistency... A language with a pure clean vision of itself in which the programmer can guess at syntax because they understand the general syntax principles to which the language adheres. Nothing here says PHP has been fixed in this regard.
Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.
The only thing that would have really interested me in this post would have been to hear that PHP had been cleaned up into a consistent syntax, but that's not what this article says.
Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.
The only thing that would have really interested me in this post would have been to hear that PHP had been cleaned up into a consistent syntax, but that's not what this article says.
I've been coding in PHP for almost 20 years now. I think I can count on one hand the number of times where I have had an issue regarding inconsistent function signatures. It becomes second nature, and if I forget, the documentation is available online or in worst case built into my IDE.
I can understand why people make this into such a pain point, but quite frankly it isn't for anyone who works day in day out with PHP.
I can understand why people make this into such a pain point, but quite frankly it isn't for anyone who works day in day out with PHP.
23 years here (php/fi in jan '96) and I probably hit the 'parameter order' issue more than you. I still need to look param order stuff multiple times per year. Normally I can get it in the IDE, but doing remote vim stuff, for example, I need to look it up.
Yes, it's technically a non-zero problem. I get it. Having spent several years in the Java/Spring world, the classic ASP world, and the Perl world... they all have problems, both with the languages and the ecosystems. There will always be people who will throw out Rust or Go or Erlang as 'better' by some metric.
For the types of projects I work on, the modern PHP stacks of the last 5-6 years are all probably the best ROI. Colleagues/friends are running medium-sized SaaS on Rails, and it works, but we compare headaches sometimes, and it's not carefree in the Rails world. There's issues there. Regardless of whether your language is 'clean' or 'discoverable', the rest of the ecosystem can still present problems.
Yes, it's technically a non-zero problem. I get it. Having spent several years in the Java/Spring world, the classic ASP world, and the Perl world... they all have problems, both with the languages and the ecosystems. There will always be people who will throw out Rust or Go or Erlang as 'better' by some metric.
For the types of projects I work on, the modern PHP stacks of the last 5-6 years are all probably the best ROI. Colleagues/friends are running medium-sized SaaS on Rails, and it works, but we compare headaches sometimes, and it's not carefree in the Rails world. There's issues there. Regardless of whether your language is 'clean' or 'discoverable', the rest of the ecosystem can still present problems.
Since you mentioned Perl, I wonder if you've tried Mojolicious at all and what you think of it? I've found it pretty nice to work in, and easily scalable to small and large projects.
That said, I don't have is a lot of experience with other frameworks in other languages to compare it to, so I don't exactly know how it compares.
That said, I don't have is a lot of experience with other frameworks in other languages to compare it to, so I don't exactly know how it compares.
That's what really gets me.
Anyone that works with PHP on a daily basis very quickly gets used to some of the naming differences or inconsistent signatures. Anyone that works with PHP rarely is almost assuredly going to have to look it up regardless of how inconsistent it is. (do people really guess at function names, signatures, and return values in other languages!? I've guessed that they exist, but I don't ever think i've tried something without first checking the docs just to see about any surprises or differences)
Consistency is nice to have, but it's pretty far down the list of requirements in my opinion. If it's different for some, I can see how they wouldn't like PHP, but calling for it to "clean up" it's syntax in a giant "python-3-esque" move seem really misguided. People who program in PHP regularly don't really mind the warts, and the language has improved significantly in areas that it's users found most important. Types slowly working their way into the language, easy closures, traits, nice new operators, and the massive speed and memory usage improvements have all been very welcome improvements that have made me more productive in the language.
The time spent on "cleaning up" the standard library would be a welcome change by most, but it wouldn't really have any material impact for me or any of the other PHP devs I know.
Anyone that works with PHP on a daily basis very quickly gets used to some of the naming differences or inconsistent signatures. Anyone that works with PHP rarely is almost assuredly going to have to look it up regardless of how inconsistent it is. (do people really guess at function names, signatures, and return values in other languages!? I've guessed that they exist, but I don't ever think i've tried something without first checking the docs just to see about any surprises or differences)
Consistency is nice to have, but it's pretty far down the list of requirements in my opinion. If it's different for some, I can see how they wouldn't like PHP, but calling for it to "clean up" it's syntax in a giant "python-3-esque" move seem really misguided. People who program in PHP regularly don't really mind the warts, and the language has improved significantly in areas that it's users found most important. Types slowly working their way into the language, easy closures, traits, nice new operators, and the massive speed and memory usage improvements have all been very welcome improvements that have made me more productive in the language.
The time spent on "cleaning up" the standard library would be a welcome change by most, but it wouldn't really have any material impact for me or any of the other PHP devs I know.
For a while it was popular to just create your own functions with your own naming convention and parameter order, easy to do and you have whatever order is sane for you. Lots of frameworks around now so you don't even have to do that any more.
[deleted]
See, I code php very rarely, I review php code a bit more often, and I stumble upon these inconsistencies all the time. So because you got used to something bad doesn't mean it's not bad.
That would break too much things and the benefits will not be enough. They could add some new things, deprecated the old things and keep them all but then you get a manual twice as big. All the changes in PHP feel pragmatic, like better SQL support, better cryptography support, better defaults, better performance and less on cool looking syntax or latest cool features.
IMO pragmatic is good, especially when you have to use an existing code base and you have to upgrade it to the latest supported version you don't want a Python 3 migration story(I migrated a medium project to latest version and the only problem was a cryptographic function that was used to generate some random looking strings that was deprecated, I replaced with the new safer function and done , my project is now compatible with the older and the new version).
IMO pragmatic is good, especially when you have to use an existing code base and you have to upgrade it to the latest supported version you don't want a Python 3 migration story(I migrated a medium project to latest version and the only problem was a cryptographic function that was used to generate some random looking strings that was deprecated, I replaced with the new safer function and done , my project is now compatible with the older and the new version).
I don't disagree with your points -- but then it turns out that PHP is still the same old crappy language it was ten years ago.
Is that and more, I mean everyone uses classes and namespaces now and structures code better so there is this improvement. Projects use autoloaders now and things again are better.
Have a look for example http://image.intervention.io/getting_started/installation how you would resize an image if you used a framework, it is much different then you would see in a code that was written 20 years ago.
Have a look for example http://image.intervention.io/getting_started/installation how you would resize an image if you used a framework, it is much different then you would see in a code that was written 20 years ago.
My point was, people can still shoot themselves in the foot if they read an old tutorial. This should not be possible in newer versions. That would be a true improvement in my eyes.
But then that means breaking backwards compatibility, stranding huge parts of the internet on older versions, splitting the community into "pre-massive-change" and "post-massive-change", and a LOT of work by both PHP maintainers and "users" for what will end up being a marginal increase in dev happiness and practically zero material benefit for anyone.
And that still doesn't solve the problem of bad blog posts... You can't control what others write about the language, and if someone writes some posts or has a website with bad information, the maintainers of the language can't "fix" that. The best they can do is what they already do, make sure the PHP documentation is among the best and most approachable of the languages that I've used.
And that still doesn't solve the problem of bad blog posts... You can't control what others write about the language, and if someone writes some posts or has a website with bad information, the maintainers of the language can't "fix" that. The best they can do is what they already do, make sure the PHP documentation is among the best and most approachable of the languages that I've used.
It is a good point but it is a big disadvantage for the people that need the backward compatibility, is the same issue with C++ or other similar old languages that keep the backward compatibility so old code continues to work.
Though if you work on a new project or existing project that uses a framework you will not even need to do the bad search queries like "how to insert an user in a mysql table", the framework is forcing you to use the correct/safe patterns.
Most beginning level tutorials are super simplified and are not following the correct patterns, like they don't check for errors, don't clean user input etc.
Though if you work on a new project or existing project that uses a framework you will not even need to do the bad search queries like "how to insert an user in a mysql table", the framework is forcing you to use the correct/safe patterns.
Most beginning level tutorials are super simplified and are not following the correct patterns, like they don't check for errors, don't clean user input etc.
You mean to say that namespaces and classes are an improvement?
Yes, you mean you want everything in a global space, you have then issues where 2 dependencies define the same type named "Task" and on dev machine a different Task is initialized then on production (it happened to me when working on an old code base that was not using namespaces).
If you are an anti OOP person then I would prefer not to debate here religions.
If you are an anti OOP person then I would prefer not to debate here religions.
> Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.
People keep saying it was a huge failure, but honestly, I don't see how it was supposed to be done better otherwise. Either you make breaking changes that will impact your entire ecosystem or you don't and live with the same cruft from 20 years ago.
People keep saying it was a huge failure, but honestly, I don't see how it was supposed to be done better otherwise. Either you make breaking changes that will impact your entire ecosystem or you don't and live with the same cruft from 20 years ago.
Rust did it with its "edition" system, where you can freely mix and match modules from the 2015 edition with modules from the 2018 edition. Unfortunately, in the Python 2 to Python 3 transition a fundamental data type (strings) changed, which would make freely mixing Python 2 and Python 3 code much harder.
In retrospect, for me many of the problems would have been fixed it they'd wrapped everything in one release, like gcc with the -std flag.
Then once someone had (say) python 2. 6 I'd know they also have python 3.2, and I wouldn't have to figure out that name of the executable to call, it would just be python, with (perhaps) either a command line option or a comment at the top of the file.
Then once someone had (say) python 2. 6 I'd know they also have python 3.2, and I wouldn't have to figure out that name of the executable to call, it would just be python, with (perhaps) either a command line option or a comment at the top of the file.
> The thing that matters is language consistency.
To be fair, we are talking about standard library consistency and not language consistency. PHP is a consistent language but it's standard library is very low-level. In Python, you don't call the mysql C library functions directly, you use an object-oriented abstraction. In PHP, you can call those mysql C library functions directly or you can use an object-oriented abstraction.
To be fair, we are talking about standard library consistency and not language consistency. PHP is a consistent language but it's standard library is very low-level. In Python, you don't call the mysql C library functions directly, you use an object-oriented abstraction. In PHP, you can call those mysql C library functions directly or you can use an object-oriented abstraction.
That's irrelevant. When talking about language consistency, we should also be including the language's standard library.
The problem is that PHP wasn't designed as language-first but as a tool to make web development more accessible. Hence the acronym for "Personal HomePage". PHP was merely a native interface to modules written in C (e.g. MySQL), with the interface hosted in a simplified version of Perl.
The draw of PHP was that you didn't need the CGI bin, and it was easy to deploy with Apache.
Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.
If you are still writing PHP in 2019, you are either very unfortunate or just very lazy.
The problem is that PHP wasn't designed as language-first but as a tool to make web development more accessible. Hence the acronym for "Personal HomePage". PHP was merely a native interface to modules written in C (e.g. MySQL), with the interface hosted in a simplified version of Perl.
The draw of PHP was that you didn't need the CGI bin, and it was easy to deploy with Apache.
Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.
If you are still writing PHP in 2019, you are either very unfortunate or just very lazy.
> That's irrelevant. When talking about language consistency, we should also be including the language's standard library.
As you said, PHP was merely an interface to (many already existing) modules written in C. When people complain about mysql_real_escape_string() in PHP they don't realize that that is the actual name of the function in the MySQL C API. Same with the image functions (imagemagik). And so on. Some are named directly after the corresponding C standard library function.
This was actually part of the huge success of PHP -- it made available, for the web developer, a huge library of existing open source technology. This did not exist, in a scripting language, before PHP. The open source community wasn't as large.
But PHP does have high-level abstractions and, like with other languages, you would also use a framework that has high-level abstractions.
If you compare PHP to JavaScript, PHP's standard library is far superior. But it's a ridiculous comparison there as well.
> The problem is that PHP wasn't designed as language-first but a tool to make web development more accessible.
Yes, but all the ways that PHP as-a-language were less than ideal most of those have been solved now. So unless you're complaining about the standard library, there isn't much left.
> Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.
Nowadays there really just isn't that much difference in design or performance between PHP and the majority of languages you would suggest.
As you said, PHP was merely an interface to (many already existing) modules written in C. When people complain about mysql_real_escape_string() in PHP they don't realize that that is the actual name of the function in the MySQL C API. Same with the image functions (imagemagik). And so on. Some are named directly after the corresponding C standard library function.
This was actually part of the huge success of PHP -- it made available, for the web developer, a huge library of existing open source technology. This did not exist, in a scripting language, before PHP. The open source community wasn't as large.
But PHP does have high-level abstractions and, like with other languages, you would also use a framework that has high-level abstractions.
If you compare PHP to JavaScript, PHP's standard library is far superior. But it's a ridiculous comparison there as well.
> The problem is that PHP wasn't designed as language-first but a tool to make web development more accessible.
Yes, but all the ways that PHP as-a-language were less than ideal most of those have been solved now. So unless you're complaining about the standard library, there isn't much left.
> Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.
Nowadays there really just isn't that much difference in design or performance between PHP and the majority of languages you would suggest.
Genuine question, because I do not know the answer. Does it support:
Lexical scoping
Coroutines
Generators
Decorators
Generic type containers
A functional API (e.g. something like Java 8 streams)
An extensive selection of data structures (collections) included in the standard lib
?
Lexical scoping
Coroutines
Generators
Decorators
Generic type containers
A functional API (e.g. something like Java 8 streams)
An extensive selection of data structures (collections) included in the standard lib
?
> Lexical scoping
Yes.
> Coroutines
No.
> Generators
Yes.
> Decorators
No.
> Generic type containers
In progress. But also PHP has dynamic/weak typing and static/strong typing so this isn't strictly necessary.
> A functional API (e.g. something like Java 8 streams)
Available as a 3rd party library.
> An extensive selection of data structures (collections) included in the standard lib
https://www.php.net/manual/en/book.spl.php
Yes.
> Coroutines
No.
> Generators
Yes.
> Decorators
No.
> Generic type containers
In progress. But also PHP has dynamic/weak typing and static/strong typing so this isn't strictly necessary.
> A functional API (e.g. something like Java 8 streams)
Available as a 3rd party library.
> An extensive selection of data structures (collections) included in the standard lib
https://www.php.net/manual/en/book.spl.php
Thanks for the thoughtful response. But based on your answers, PHP does lag significantly behind other modern languages. FYI the SPL you linked is quite meager compared to languages like Python and Java.
My opinion remains unchanged. Using PHP in 2019 only puts you at a disadvantage when compared to the alternatives.
My opinion remains unchanged. Using PHP in 2019 only puts you at a disadvantage when compared to the alternatives.
Honestly nobody uses the SPL. PHP's array type is more than powerful enough for the vast majority of data structure tasks and the standard library has functions for treating it as a stack, a list, etc.
Coroutines are not necessary in PHP. In fact, the share nothing architecture of the LAMP stack is one of it's advantages if that suits your needs.
The setup of a Java web stack alone is painful enough to make PHP a viable option in comparison.
Coroutines are not necessary in PHP. In fact, the share nothing architecture of the LAMP stack is one of it's advantages if that suits your needs.
The setup of a Java web stack alone is painful enough to make PHP a viable option in comparison.
Thanks. Again, I am asking out of ignorance:
What is PHP's concurrency model? Is it still a forked process pool via something like PHP-FPM, or has it changed?
Does the VM enforce a GIL? I'm assuming there is some kind of threading API?
Can you run an event loop using epoll, and is the standard library well supported in that execution model?
FYI, I was a PHP developer from 2003-2011. I did enjoy it back then. I never bought into the Rails hype at the time, opting instead for copycats like Yii and CI.
But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.
It may be the nature of the work, but I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.
What is PHP's concurrency model? Is it still a forked process pool via something like PHP-FPM, or has it changed?
Does the VM enforce a GIL? I'm assuming there is some kind of threading API?
Can you run an event loop using epoll, and is the standard library well supported in that execution model?
FYI, I was a PHP developer from 2003-2011. I did enjoy it back then. I never bought into the Rails hype at the time, opting instead for copycats like Yii and CI.
But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.
It may be the nature of the work, but I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.
> What is PHP's concurrency model? Is it still a forked process pool via something like PHP-FPM, or has it changed?
> Does the VM enforce a GIL? I'm assuming there is some kind of threading API?
As far as I'm aware PHP is still mostly run PHP-FPM. It also does have a threading API: https://www.php.net/manual/en/class.thread.php
> But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.
I haven't done PHP seriously in a very long time. I currently work in C# and ASP.NET for web and I do C++, Python, and JavaScript. Personally, I'm doing work in Python right now and I don't enjoy it very much -- I'd much rather work in PHP for web development over Python. I prefer a good strongly typed language.
> I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.
I don't know. PHP has Lambdas. It has generators. It was strong typing. From a CS perspective, there isn't much PHP does not have for the purposes of web development. It's limitations, in my opinion, mostly come from being a dynamic scripting language but those same issues befall Python and Nodejs as well.
If I had to code in PHP again, my code wouldn't look much different from my code in any other language.
As far as I'm aware PHP is still mostly run PHP-FPM. It also does have a threading API: https://www.php.net/manual/en/class.thread.php
> But I was ignorant. Honestly, after switching to Python for web dev, I saw no reason to ever return. Since then, I've dropped web dev altogether, and I now work in C++, Java, and Python on a daily basis.
I haven't done PHP seriously in a very long time. I currently work in C# and ASP.NET for web and I do C++, Python, and JavaScript. Personally, I'm doing work in Python right now and I don't enjoy it very much -- I'd much rather work in PHP for web development over Python. I prefer a good strongly typed language.
> I still cringe at the thought of using PHP again after learning how capable other general purpose languages are. From a CS point of view, working in PHP just isn't very interesting... or pleasant.
I don't know. PHP has Lambdas. It has generators. It was strong typing. From a CS perspective, there isn't much PHP does not have for the purposes of web development. It's limitations, in my opinion, mostly come from being a dynamic scripting language but those same issues befall Python and Nodejs as well.
If I had to code in PHP again, my code wouldn't look much different from my code in any other language.
That's fair.
I think if you're building CRUD apps over and over again, then yeah, there isn't too much difference.
But if you're building a web service with more complicated business logic and you need more control over your concurrency model, then other languages look more appealing.
And it looks like PHP doesn't have JIT yet, which is another huge mark against it.
So PHP is probably fine for passing params and rendering back HTML. But anything sitting in between that's more interesting should be built in something else.
I think if you're building CRUD apps over and over again, then yeah, there isn't too much difference.
But if you're building a web service with more complicated business logic and you need more control over your concurrency model, then other languages look more appealing.
And it looks like PHP doesn't have JIT yet, which is another huge mark against it.
So PHP is probably fine for passing params and rendering back HTML. But anything sitting in between that's more interesting should be built in something else.
> The thing that matters is language consistency... [...] Python made the big leap and fixed some huge problems when it went to python 3
And yet, here we are over a decade along and the Python project is still maintaining Python 2 and I still need to maintain a copy of Python 2 on my computer because of the number of actively maintained projects still using it. How many developer-hours that could have gone into doing something else have instead gone into this "language consistency" project?
At any point in the past 25 years someone could have forked PHP to clean the syntax up and accomplished the exact same thing -- and yet apparently nobody has seen the inconsistency as a big enough issue or time sink to do so. I would take that as prima facie evidence that this isn't nearly as important as you seem to think it is.
Meanwhile, one of the strengths of PHP in my opinion has been how carefully they have maintained and managed backward compatibility. While "move fast and break things" might be the new norm, there is still a huge contingent of developers and businesses that see value in slower, more considered change.
And yet, here we are over a decade along and the Python project is still maintaining Python 2 and I still need to maintain a copy of Python 2 on my computer because of the number of actively maintained projects still using it. How many developer-hours that could have gone into doing something else have instead gone into this "language consistency" project?
At any point in the past 25 years someone could have forked PHP to clean the syntax up and accomplished the exact same thing -- and yet apparently nobody has seen the inconsistency as a big enough issue or time sink to do so. I would take that as prima facie evidence that this isn't nearly as important as you seem to think it is.
Meanwhile, one of the strengths of PHP in my opinion has been how carefully they have maintained and managed backward compatibility. While "move fast and break things" might be the new norm, there is still a huge contingent of developers and businesses that see value in slower, more considered change.
What are you talking about is just a syntax. Which is not an issue for a PHP dev nowadays. I am typing much more custom method names than vanilla PHP functions. And when I have, my IDE shows me the right syntax after a few keystrokes.
So, it's apparently a good reason to hate, but by no means a reason not to use PHP.
So, it's apparently a good reason to hate, but by no means a reason not to use PHP.
I often run into this argument - "inconsistent syntax", followed by zero proof. Then I wonder - is the person making the comment even using PHP or is the person behind the comment.. even capable programmer?
Yes, PHP has been "cleaned up" and you have always had the option to use clean, concise way of coding without language interfering or hindering you in any way.
There's no programming language out there that makes up for the sloppiness and inability of the person behind the screen.
Yes, PHP has been "cleaned up" and you have always had the option to use clean, concise way of coding without language interfering or hindering you in any way.
There's no programming language out there that makes up for the sloppiness and inability of the person behind the screen.
Back in the PHP 3/4 days, a lot of related functions would have different argument orders.
str_replace(old, new) vs. stri_replace(new, old) kind of thing.
str_replace(old, new) vs. stri_replace(new, old) kind of thing.
Here's the thing that always grates a little bit for me about these posts:
I don't have a choice.
I've worked at a couple of organisation where there are hundreds of thousands of lines of code written in PHP. It's been there for years. It does its job and - from a business perspective - it does its job pretty damn well. And I get paid to keep it ticking, and to improve it. Not to rewrite it to fit my personal tastes.
In my spare time I've played with Haskell, Rust, C, Lisp, assembly languages, and I enjoy them. I dearly miss some of the more functional aspects from these languages every time I write PHP.
I work with a large PHP codebase right now (amongst others) and while there are a great many technical benefits I could wring from it in another language, runtime, or environment, a lot of the changes needed to get there would be prolonged, painful, and would provide no noticeable business value.
I'm somewhat reminded of Python, where there is the concept of a "pythonic way" of doing things. There is very much a "PHP way" of doing things, a "${LANGUAGE} way" of doing things, and of course an "${ORG-SPECIFIC} way".
I'm also somewhat amused at Rails as a frequent comparison. I've also worked with Rails, and I hated it. It was quite some time ago, I'd probably enjoy it if I tried again. But I will try to remember in future that opinions formed from bad experiences need to be reviewed in light of the time elapsed since then, and my own personal/professional growth as well.
More generally, when I hear a developer (in my own office ;P) espousing the view that "${LANGUAGE} is garbage", I assign more meaning to the fact that they choose to make that statement than I do to any particular view of the language in question.
I don't have a choice.
I've worked at a couple of organisation where there are hundreds of thousands of lines of code written in PHP. It's been there for years. It does its job and - from a business perspective - it does its job pretty damn well. And I get paid to keep it ticking, and to improve it. Not to rewrite it to fit my personal tastes.
In my spare time I've played with Haskell, Rust, C, Lisp, assembly languages, and I enjoy them. I dearly miss some of the more functional aspects from these languages every time I write PHP.
I work with a large PHP codebase right now (amongst others) and while there are a great many technical benefits I could wring from it in another language, runtime, or environment, a lot of the changes needed to get there would be prolonged, painful, and would provide no noticeable business value.
I'm somewhat reminded of Python, where there is the concept of a "pythonic way" of doing things. There is very much a "PHP way" of doing things, a "${LANGUAGE} way" of doing things, and of course an "${ORG-SPECIFIC} way".
I'm also somewhat amused at Rails as a frequent comparison. I've also worked with Rails, and I hated it. It was quite some time ago, I'd probably enjoy it if I tried again. But I will try to remember in future that opinions formed from bad experiences need to be reviewed in light of the time elapsed since then, and my own personal/professional growth as well.
More generally, when I hear a developer (in my own office ;P) espousing the view that "${LANGUAGE} is garbage", I assign more meaning to the fact that they choose to make that statement than I do to any particular view of the language in question.
[deleted]
I've been using PHP semi-regularly since the late 90s. It's been empowering and infuriating.
The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards.
For whatever reason, I often feel clumsier after working on a PHP project. After working in other languages like JS or Python, I tend to feel like I've leveled-up my skills.
One thing I wish PHP would address is the inconsistency in its map-filter-reduce functions -- their argument-order doesn't match (array, callback) vs. (callback, array):
- https://packagist.org/
- https://github.com/prettier/plugin-php
The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards.
For whatever reason, I often feel clumsier after working on a PHP project. After working in other languages like JS or Python, I tend to feel like I've leveled-up my skills.
One thing I wish PHP would address is the inconsistency in its map-filter-reduce functions -- their argument-order doesn't match (array, callback) vs. (callback, array):
array_filter($arr, $fn)
array_map($fn, $arr)
array_reduce($arr, $fn)
- https://packagist.org/
- https://github.com/prettier/plugin-php
I hear this complaint a lot but I find those argument orders completely intuitive.
You filter (1) an array with (2) a function. You map (1) a function over (2) an array. You reduce (1) an array with (2) a function.
It follows exactly what I'm thinking when I type it. To reverse the orders would be, what? "Mapping an array with a function?" "Filter a function on an array?"
You filter (1) an array with (2) a function. You map (1) a function over (2) an array. You reduce (1) an array with (2) a function.
It follows exactly what I'm thinking when I type it. To reverse the orders would be, what? "Mapping an array with a function?" "Filter a function on an array?"
Laravel has Collection class that wraps arrays - as such you can do `(new Collection([your array]))->filter(function(){})` or `(new Collection([your array]))->map(function(){})`. It also adds other helper methods. I guess Symfony has something similar
Reference: https://laravel.com/docs/5.8/collections
Reference: https://laravel.com/docs/5.8/collections
Or collect([your array]). I love Laravel collections.
From a performance perspective, you likely want to do those with `foreach` anyway in PHP. Especially when the array function is fed a closure. I know it is not as interesting as using those functions, but because of PHP internals, `foreach` is almost always preferred.
https://stackoverflow.com/questions/18144782/performance-of-...
https://stackoverflow.com/questions/18144782/performance-of-...
Infuriating? I'm not here to defend php but even when I do agree that inconsistencies are not nice, nothing stop you of creating your own wrapper for these functions.
Infuriating? really?
Infuriating? really?
Yes, it is really infuriating that PHP literally cannot commit to any coding standards whatsoever for its standard library. Even if you choose to write your own wrappers, it doesn't change other people's code which you have to read. It's idiotic that the developers of PHP didn't take 5 seconds to consult their other functions before adding new ones with the arguments reversed, and it is totally appropriate to feel angry at them for their unconscionable shortsightedness.
Back when I wrote PHP, the solution was to use an editor which shows you functions arguments after you type the open bracket.
As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like.
Is performance that much of a big deal for most people? In a world where Ruby on Rail exists I find that hard to believe. Server are cheaper and vastly more powerful now than in PHP's infancy, I'm sure that for the vast majority of use cases PHP's performance (whatever it is) is good enough.
The infamous "Fractal of Bad Design" wasn't about that, it was about the ridiculously inconsistent and error-prone API, the insane defaults, the counter-intuitive behaviour of '==', the headless chicken development roadmap where maintainers would add features because they were popular in other programing languages without trying to figure out if they had their place in PHP,...
Surely a lot of this has turned into technical debt? Even assuming that "modern" PHP managed to come up with better ways to deal with all of this, I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them?
Again, I personally don't really care, but if you want to win new converts who haven't been as scarred by PHP as I have been I think that's where you should focus your efforts. Maybe somebody should write a point-by-point rebuttal to the "fractal of bad design" article?
Is performance that much of a big deal for most people? In a world where Ruby on Rail exists I find that hard to believe. Server are cheaper and vastly more powerful now than in PHP's infancy, I'm sure that for the vast majority of use cases PHP's performance (whatever it is) is good enough.
The infamous "Fractal of Bad Design" wasn't about that, it was about the ridiculously inconsistent and error-prone API, the insane defaults, the counter-intuitive behaviour of '==', the headless chicken development roadmap where maintainers would add features because they were popular in other programing languages without trying to figure out if they had their place in PHP,...
Surely a lot of this has turned into technical debt? Even assuming that "modern" PHP managed to come up with better ways to deal with all of this, I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them?
Again, I personally don't really care, but if you want to win new converts who haven't been as scarred by PHP as I have been I think that's where you should focus your efforts. Maybe somebody should write a point-by-point rebuttal to the "fractal of bad design" article?
I was pretty anti-PHP before I worked for a multi-billion dollar company that was built on top of it. It's not a beautiful language, but it offers a lot of side benefits in terms of dev-ops, and tooling, and frameworks. As a company, the language was not something that held us back. The company moved really fast, and PHP was a large part a big part of why. In my career over the past 14 years I've done web work using ruby, python, C#, javascript, and Java. but that ugly PHP site was the one that impressed me the most. People moved fast in it, our tooling never held us back, everything just worked. It was the most utilitarian environment i've worked in. The first time I touched PHP, it was a spaghetti disaster... but today, next to python It's my go to language. It gets the job done faster, and it's maintainability is just fine. It really doesn't matter if sometimes things just look odd.
I have to echo this.
I worked on a data pipeline that was a mountain of PHP scripts bolted together with Bash and it was such a breeze to maintain. Using Symfony ensures that every command is well documented and consistent in design and use.
Something I never appreciated about PHP until recently is that character encoding is so much more robust in PHP than other languages. We were forced to replace our pipeline with Python because of a combination of "Eww, PHP" from new management and "data scientists use Python." Character encoding was a huge, unexpected annoyance.
I worked on a data pipeline that was a mountain of PHP scripts bolted together with Bash and it was such a breeze to maintain. Using Symfony ensures that every command is well documented and consistent in design and use.
Something I never appreciated about PHP until recently is that character encoding is so much more robust in PHP than other languages. We were forced to replace our pipeline with Python because of a combination of "Eww, PHP" from new management and "data scientists use Python." Character encoding was a huge, unexpected annoyance.
Which version of Python? I ask because making fundamental changes to character encoding was the single most disruptive feature of the Python 2/Python 3 split.
> character encoding is so much more robust in PHP than other languages.
This is not what I expected -- my limited past experiences with anything outside of Latin-1 using PHP have been perplexing and not smooth (and I generally like PHP well enough). Can you elaborate on what features or approach can make things robust?
This is not what I expected -- my limited past experiences with anything outside of Latin-1 using PHP have been perplexing and not smooth (and I generally like PHP well enough). Can you elaborate on what features or approach can make things robust?
PHP doesn't care about your encoding. Therefore it's simpler to work with any encoding in it, because you're managing it manually.
Most of this would apply to Perl, as well. Which I can't fathom why Perl didn't easily beat out Python in the data science world. It's incredibly stable (version 5, that is), fast, and can just about rip apart and parse any raw data you have with ease. Python may "feel" newer, but there are only a few years age difference. Even Ruby isn't that much newer.
Tragically, Perl developed its "unreadable" reputation because it was the language du jour of the system admin/hacking world. The first time most people experienced Perl was by finding some crufty old script that glued a bunch of shell tools together haphazardly. Few developers today have actually seen what good, production Perl can look like.
No disrespect to the wonderful system admins of years past, but those guys were a different breed. They weren't programmers. But Perl still let them get their job done. Their unmaintainable messes caused a great deal of harm to Perl.
Tragically, Perl developed its "unreadable" reputation because it was the language du jour of the system admin/hacking world. The first time most people experienced Perl was by finding some crufty old script that glued a bunch of shell tools together haphazardly. Few developers today have actually seen what good, production Perl can look like.
No disrespect to the wonderful system admins of years past, but those guys were a different breed. They weren't programmers. But Perl still let them get their job done. Their unmaintainable messes caused a great deal of harm to Perl.
I maintain others Perl code and am no expert. Its our most use web tool and has been running for 10 years. I think Perl is different enough to confuse people who look at it (@,%,$) and it can make it hard to follow. I still have a little problems switching to it from other languages sometimes (do x unless y seems backward to me). I've also been told I write perl like a c programmer. Perl does have some beautiful parts though..
CPAN is great, but its hard sometimes when I just want to install something easy. It was the first great shared library and it shows its age a bit. Last time I ran it, it was compiling C code for some strange reason. We have trouble setting up shared perl environments, something we don'e have with python.
Biology has a lot of Perl code still, but it seems to moving to python.
Terrible code exists in many languages.
CPAN is great, but its hard sometimes when I just want to install something easy. It was the first great shared library and it shows its age a bit. Last time I ran it, it was compiling C code for some strange reason. We have trouble setting up shared perl environments, something we don'e have with python.
Biology has a lot of Perl code still, but it seems to moving to python.
Terrible code exists in many languages.
I appreciate you sharing this. The goal of my post was not to convince people to "switch to PHP right now", but rather to tell them you can do pretty cool things with it, and that it's actually fun to work in.
> ven assuming that "modern" PHP managed to come up with better ways to deal with all of this, I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them?
I think the "path of least resistance" is important: developers are time-constrained, understanding-constrained, lazy (if they're virtuous), etc. There's a big incentive to do whatever is easiest/quickest.
When I last used PHP, about 5 years ago, there were OOP APIs cropping up to replace many of the standard global functions; namespaces had just been introduced; closures had become useful; frameworks like Symfony (and Drupal 8) were becoming established, rather than the old "plugin" approach of throwing around arbitrary code and hoping for the best; dependencies were being managed by composer; files could be autoloaded from sensible locations; testing frameworks like PHPUnit and PHPSpec had become best practice; etc.
Yet all of those things were opt-in and verbose. The path of least resistance was still:
Compare this to something like Java: it favours class-based OOP so much that even "hello world" needs a class. The path of least resistance is to do things "right" (from Java's perspective). Haskell's path of least resistance is simultaneously easier ("hello world" is just `main = putStrLn "hello world"`) and harder (`main` uses the `IO` type, whose API enforces certain conventions).
Deprecation warnings, linters, etc. can help with this; but PHP's only real strength is its installed base of code and developers; changing the language too much would throw away this advantage (akin to being a new language, see Python 3 and Perl 6); not changing it enough prevents the more serious and/or systemic issues from being dealt with.
I wish the language designers and users luck, but I'm really hoping to never use it again ;)
I think the "path of least resistance" is important: developers are time-constrained, understanding-constrained, lazy (if they're virtuous), etc. There's a big incentive to do whatever is easiest/quickest.
When I last used PHP, about 5 years ago, there were OOP APIs cropping up to replace many of the standard global functions; namespaces had just been introduced; closures had become useful; frameworks like Symfony (and Drupal 8) were becoming established, rather than the old "plugin" approach of throwing around arbitrary code and hoping for the best; dependencies were being managed by composer; files could be autoloaded from sensible locations; testing frameworks like PHPUnit and PHPSpec had become best practice; etc.
Yet all of those things were opt-in and verbose. The path of least resistance was still:
<html>
<body>
Hello <?php echo $_GET['name']; ?>
</body>
</html>
Compare this to something like Java: it favours class-based OOP so much that even "hello world" needs a class. The path of least resistance is to do things "right" (from Java's perspective). Haskell's path of least resistance is simultaneously easier ("hello world" is just `main = putStrLn "hello world"`) and harder (`main` uses the `IO` type, whose API enforces certain conventions).
Deprecation warnings, linters, etc. can help with this; but PHP's only real strength is its installed base of code and developers; changing the language too much would throw away this advantage (akin to being a new language, see Python 3 and Perl 6); not changing it enough prevents the more serious and/or systemic issues from being dealt with.
I wish the language designers and users luck, but I'm really hoping to never use it again ;)
The $_GET/$_POST pattern is rare in modern applications (anything built in the last 5 years) and is rightly recognized as an antipattern. Similarly many of the older obsolete functions have been either removed or fallen out of fashion.
You are absolutely right that the path to this has been fixing the path of least resistance. Laravel and other frameworks have made it easy to get variables using their preferred methods (and automatically sanitizing input). Learning resources (tutorials, docs) utilize the OO functions and many of the older functions were deprecated and have been removed for years. If you look at one of the more infamous functions, mysql_real_escape_string (https://www.php.net/manual/en/function.mysql-real-escape-str...) that was removed entirely in PHP 7. If you look at the more modern mysqli, they've chosen to have both escape_string and real_escape string, but one is an alias to the other. Similarly, sane defaults have become the norm, especially since most developers are using containers or VMs/vagrant to program. The one major outstanding issue is the api naming is still inconsistent.
On a sidenote, the PHP docs are great with pages showing examples and notes talking about potential issues. When I switched to python I couldn't believe how bad the docs were in comparison.
You are absolutely right that the path to this has been fixing the path of least resistance. Laravel and other frameworks have made it easy to get variables using their preferred methods (and automatically sanitizing input). Learning resources (tutorials, docs) utilize the OO functions and many of the older functions were deprecated and have been removed for years. If you look at one of the more infamous functions, mysql_real_escape_string (https://www.php.net/manual/en/function.mysql-real-escape-str...) that was removed entirely in PHP 7. If you look at the more modern mysqli, they've chosen to have both escape_string and real_escape string, but one is an alias to the other. Similarly, sane defaults have become the norm, especially since most developers are using containers or VMs/vagrant to program. The one major outstanding issue is the api naming is still inconsistent.
On a sidenote, the PHP docs are great with pages showing examples and notes talking about potential issues. When I switched to python I couldn't believe how bad the docs were in comparison.
To understand that, you have to take a closer look at its origins. For me, this talk by Rasmus Lerdorf (creator of PHP) was a real eye-opener: https://www.youtube.com/watch?v=SvEGwtgLtjA He mentions that what we now refer to as the "PHP language" was originally intended to be only the templating system, and you were supposed to write your business logic in a "real language" such as C. However, as PHP got more popular, bits and pieces were added until the "templating system" became a full-fledged language. Sounds like this happened more by chance than by design. And because you can't throw all of that out, it shows until today. You can introduce new features, but doing that in a way that stays (more or less) backwards compatible is difficult and forces compromises - see type declarations, which are actually just type hinting and of very limited use. So sure, PHP is wildly popular because of its "first mover" status, so it will probably stay with us for the foreseeable future, and working in it may have become more pleasant over the years thanks to better tooling, but it will unfortunately never be as pleasant as in other, more well-designed languages.
That's kinda the problem with any domain-specific language: it either requires a full language for support, or it becomes one (and generally not a very good one). Every language is an opinion about what things should be easy and what things are allowed to be hard.
I've got nothing against DSLs and template languages and such, but most of the ones I encounter make me sigh and say, "I know you thought it would be easier but it's just one more thing I have to figure out how to debug, without any of my usual debugging tools."
I've got nothing against DSLs and template languages and such, but most of the ones I encounter make me sigh and say, "I know you thought it would be easier but it's just one more thing I have to figure out how to debug, without any of my usual debugging tools."
> what we now refer to as the "PHP language" was originally intended to be only the templating system, and you were supposed to write your business logic in a "real language" such as C
I did get a little perverse amusement at writing HTML files containing nothing other than single `<?php` element; where that PHP's job was to generate HTML; and it did so via a templating language (e.g. Twig or Smarty)...
I did get a little perverse amusement at writing HTML files containing nothing other than single `<?php` element; where that PHP's job was to generate HTML; and it did so via a templating language (e.g. Twig or Smarty)...
You can't remove those old APIs without changing culture, and culture is really hard to change.
One thing that shocked me during my brief foray into PHP was how heavily popular PHP apps like WordPress rely on the filesystem. Want to move a site? Copy the database, and copy a bunch of files. It seems like there's a cultural expectation that applications run on a single server in your closet. Of course you don't have to write code this way... but people still do.
One thing that shocked me during my brief foray into PHP was how heavily popular PHP apps like WordPress rely on the filesystem. Want to move a site? Copy the database, and copy a bunch of files. It seems like there's a cultural expectation that applications run on a single server in your closet. Of course you don't have to write code this way... but people still do.
WordPress is NOT an example of modern PHP practices though. The amount of legacy insanity in WordPress is enough to make any sane dev cry...
Why was it shocking? PHP (originally) stood for "Personal Home Page" after all...
comparing a web page with a potential XSS vs a java 'hello world' (assuming console output) is a bit disingenuous, no?
<?php echo "hello world";
There - no XSS, no HTML, no class requirements.
<?php echo "hello world";
There - no XSS, no HTML, no class requirements.
I think you're confused. The PHP snippet was to demonstrate my point that:
- The path of least resistance in PHP is often directly at odds with the "proper" way of doing things (including many things listed in this article).
- This is important because PHP's intended domain is Web development, so this can easily cause security flaws.
- Any attempt to "fix" this example will inevitably make it longer, more complicated, harder to remember, etc.
Your PHP "hello world" does not demonstrate those problems, since it has no XSS or HTML, so it is a poor example.
After this demonstration, I abstracted to the more general concepts of "path of least resistance" and "'proper' ways to do things", irrespective of language or domain.
To clarify my meaning for these phrases, and to demonstrate how language designers can use the former to push the latter, I gave two examples: Java pushing its preferred approach of class-based OOP, by disallowing raw, top-level statements; and Haskell pushing its preferred approach of monadic I/O, by enforcing the type of `main` and restricting the available APIs. Notice that neither of those examples make the "proper" way easier (that can be very difficult, in general); instead they eliminate anything that's easier (like top-level statements), such that the "proper" way is the easiest thing that's left. In other words, Java's requirement that even "hello world" be wrapped in a class is a good thing for Java programmers, since allowing top-level statements like `System.out.println("hello world");` would undermine the principles of the language. This general argument is not specific to PHP, and certainly not a direct comparison to the XSS snippet.
After defining and demonstrating these general concepts, I then returned to the specific case of PHP, to point out how backwards-compatibility with its legacy of easy, insecure approaches undermines the attempts to improve the situation. In other words, the "proper" way to write PHP (at least, back when I used it) is to use OOP, namespaces, type hints, escaping of user input, etc. Yet the design of the PHP language discourages all of those, by providing easier alternatives which are "improper" (like in my XSS example); and removing those alternatives (in the same way that Java forbids top-level statements) would break almost all existing PHP projects and require the majority of PHP developers to change their habits; and doing so would eliminate PHP's main selling point (installed base and developer mindshare).
I hope that clarifies why the comparison is not disingenuous (i.e. because I'm not making the comparison that you claim).
If I were to make a comparison of that vulnerable PHP code against something else, it would need to be against a language which is primarily designed for Web development (to avoid being disingenuous), and it should be designed to make the "proper" approach the easiest. The Ur/Web language fits these criteria nicely, and (from a quick skim of the tutorial at http://www.expdev.net/urtutorial/step1.html ) the equivalent to that PHP would be:
- The path of least resistance in PHP is often directly at odds with the "proper" way of doing things (including many things listed in this article).
- This is important because PHP's intended domain is Web development, so this can easily cause security flaws.
- Any attempt to "fix" this example will inevitably make it longer, more complicated, harder to remember, etc.
Your PHP "hello world" does not demonstrate those problems, since it has no XSS or HTML, so it is a poor example.
After this demonstration, I abstracted to the more general concepts of "path of least resistance" and "'proper' ways to do things", irrespective of language or domain.
To clarify my meaning for these phrases, and to demonstrate how language designers can use the former to push the latter, I gave two examples: Java pushing its preferred approach of class-based OOP, by disallowing raw, top-level statements; and Haskell pushing its preferred approach of monadic I/O, by enforcing the type of `main` and restricting the available APIs. Notice that neither of those examples make the "proper" way easier (that can be very difficult, in general); instead they eliminate anything that's easier (like top-level statements), such that the "proper" way is the easiest thing that's left. In other words, Java's requirement that even "hello world" be wrapped in a class is a good thing for Java programmers, since allowing top-level statements like `System.out.println("hello world");` would undermine the principles of the language. This general argument is not specific to PHP, and certainly not a direct comparison to the XSS snippet.
After defining and demonstrating these general concepts, I then returned to the specific case of PHP, to point out how backwards-compatibility with its legacy of easy, insecure approaches undermines the attempts to improve the situation. In other words, the "proper" way to write PHP (at least, back when I used it) is to use OOP, namespaces, type hints, escaping of user input, etc. Yet the design of the PHP language discourages all of those, by providing easier alternatives which are "improper" (like in my XSS example); and removing those alternatives (in the same way that Java forbids top-level statements) would break almost all existing PHP projects and require the majority of PHP developers to change their habits; and doing so would eliminate PHP's main selling point (installed base and developer mindshare).
I hope that clarifies why the comparison is not disingenuous (i.e. because I'm not making the comparison that you claim).
If I were to make a comparison of that vulnerable PHP code against something else, it would need to be against a language which is primarily designed for Web development (to avoid being disingenuous), and it should be designed to make the "proper" approach the easiest. The Ur/Web language fits these criteria nicely, and (from a quick skim of the tutorial at http://www.expdev.net/urtutorial/step1.html ) the equivalent to that PHP would be:
fun greet data = return <xml>
<body>
Hello {[data.name]}
</body>
</xml>
funny, because it's what React.js allows to do nowadays
The difference is React actually handles escaping properly. It won't just dump out raw HTML by default, so you won't have an XSS issue.
PHP, on the other hand, requires manual escaping with htmlentities() ... It is very, very error prone.
PHP, on the other hand, requires manual escaping with htmlentities() ... It is very, very error prone.
You are comparing a framework to a language though. Escaping in PHP is usually handled by the templating component, you don't go around writing htmlentities() everywhere.
If you're dealing with decade old code that uses no framework, you certainly do. PHP is, by default, a primitive templating language...
PHP comes with a Web framework built in (that's what things like `$_GET`, `$_POST`, `htmlentities`, etc. are). It is also a templating language, that's why we need to write `<?` at the start (to open a PHP tag).
Agreed, articles like these do absolutely nothing to address PHP's insane warts, some of which you mentioned.
That's not helpful. Laravel can objectively be the best web app framework in the world and I still won't touch it, because of PHP.
Predictability, minimum WTFs per minute, consistency, sane defaults -- these win over short-term convenience, every time.
That's not helpful. Laravel can objectively be the best web app framework in the world and I still won't touch it, because of PHP.
Predictability, minimum WTFs per minute, consistency, sane defaults -- these win over short-term convenience, every time.
For what it's worth, here's the source code of one of my personal side projects, written in PHP and Laravel: https://github.com/brendt/aggregate.stitcher.io
One of my old friends has been working with php since forever, we’ve teased him over the years.
Since then we’ve moved to a world where every program is web-based. I mean, even huge enterprise systems in healthcare run on some JavaScript MVVM framework and a web-backend in the cloud.
The truth is that php is more adapt at handling this than a lot of the stacks you see in enterprise. It’s really kind of silly, but I don’t think we’ll ever adopt php either exactly for its bad rep. But sometimes I wonder if we shouldn’t.
Since then we’ve moved to a world where every program is web-based. I mean, even huge enterprise systems in healthcare run on some JavaScript MVVM framework and a web-backend in the cloud.
The truth is that php is more adapt at handling this than a lot of the stacks you see in enterprise. It’s really kind of silly, but I don’t think we’ll ever adopt php either exactly for its bad rep. But sometimes I wonder if we shouldn’t.
> [...] its defenders should focus on actually showing what modern PHP code looks like.
Laravel does this very well, not just by being a great framework but also in its ecosystem (Envoyer, Forge, Spark, Nova, Horizon, Socialite) and its documentation (https://laravel.com/docs/master).
Laravel does this very well, not just by being a great framework but also in its ecosystem (Envoyer, Forge, Spark, Nova, Horizon, Socialite) and its documentation (https://laravel.com/docs/master).
Laravel has a Java-like problem of too many indirections, and has a really complex application model that breaks a lot of things. For that you gain an end of 00's quality templating system and ORM.
I understand that PHP developers love it. It's orders of magnitude better than doing everything by hand. But no, thanks.
I understand that PHP developers love it. It's orders of magnitude better than doing everything by hand. But no, thanks.
Just out of curiosity. What type of comparable work are you doing and what languages/frameworks are you using? How do they compare?
I've created reasonably complex projects on Django (with late 00's capabilities), I've done things in Flask, Asp.Net, Java (with very out of date components), very simple things on Rails, and also used some non-OOP frameworks like snap, I've also used some newer templating systems. I have never created anything in Laravel, but I have done some maintenance.
Compared to Django and Rails, Laravel has those two problems I said. I don't think I ever saw a benefit of Laravel compared to them, except for the easy to deployment of PHP (that is a mixed bag anyway).
The ASP.Net and Java frameworks are so different that any comparison could join Django, Rails, and Laravel as a single point. Everything on those languages is more bureaucratic and stable, easier to compose more complex projects, but harder to create simpler ones.
Compared to snap (I've used very little of Yesod, but looks like it's alike here), the trio Laravel, Django, and Rails compose pages much better (it's a shame really since "compose" and FP go hand to hand, and I expect that to change in the future), but the FP frameworks are much better for creating data services.
Compared to Django and Rails, Laravel has those two problems I said. I don't think I ever saw a benefit of Laravel compared to them, except for the easy to deployment of PHP (that is a mixed bag anyway).
The ASP.Net and Java frameworks are so different that any comparison could join Django, Rails, and Laravel as a single point. Everything on those languages is more bureaucratic and stable, easier to compose more complex projects, but harder to create simpler ones.
Compared to snap (I've used very little of Yesod, but looks like it's alike here), the trio Laravel, Django, and Rails compose pages much better (it's a shame really since "compose" and FP go hand to hand, and I expect that to change in the future), but the FP frameworks are much better for creating data services.
If laravel is the best we have were fucked.
Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.
Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.
Symfony is better at handling backward compatibility and managing deprecation.
Still over-engineered I guess but sometimes it means you won't have to go against the framework for some complicated tasks.
Still over-engineered I guess but sometimes it means you won't have to go against the framework for some complicated tasks.
Can you share some of the BC breaking changes you've seen? I personally haven't seen any in quite a while, but I'm not using all parts of the framework.
Read the migration notes for the last few releases. Anything that requires you to change your code is a breaking change and the reason you can't skip versions.
Can you explain the IOC hell? isn't most IOC / Dependency Injection patterns suppose to help the software maintainability ?
I tend to think of these more as enabling modularity and convention-over-configuration (being Rails-y if you will) rather than maintainability.
Prior to Laravel, the PHP way was minimal indirection and simple execution flow. I think it was hard to do something something different with Laravel, and definitely hard to do it in a way that offers performance and security and any other good thing you might want in addition to pretty code.
One disadvantage IOC/DI carry in every language and particularly in PHP is difficulty with debugging. If you have a file of functions and a template that generates HTML you could just read through the code yourself or use prints, now it can be hard to know where to put the print when each page load may involve a couple dozen files.
That, I believe, is IOC hell. My belief is you get through it by learning the framework internals, which is a lot of work (especially if you also have to fit something like Wordpress, Angular, your family, or Photoshop in your mind as well).
Prior to Laravel, the PHP way was minimal indirection and simple execution flow. I think it was hard to do something something different with Laravel, and definitely hard to do it in a way that offers performance and security and any other good thing you might want in addition to pretty code.
One disadvantage IOC/DI carry in every language and particularly in PHP is difficulty with debugging. If you have a file of functions and a template that generates HTML you could just read through the code yourself or use prints, now it can be hard to know where to put the print when each page load may involve a couple dozen files.
That, I believe, is IOC hell. My belief is you get through it by learning the framework internals, which is a lot of work (especially if you also have to fit something like Wordpress, Angular, your family, or Photoshop in your mind as well).
Yes, they are supposed to.
The problem is that it gets taken to extremes when it's done at the framework level.
The pattern tends to encourage overly decoupled abstractions that are nigh impossible to wrap your head around.
Dependency injection is useful when you need to decouple for testing. Other than that it's rarely useful.
If your trying to decouple everything because "coupling is bad mmkay" your just cargo culting.
IOC is just anti OO. And I'm anti OO. But when you use IOC for every class yove got a huge fucking problem.
The only time I've seen IOC work well is across module boundaries in a system where modules were boundaries that could not be crossed without the IOC.
Within modules usual namespacing and new constructors were used liberally.
The problem is that it gets taken to extremes when it's done at the framework level.
The pattern tends to encourage overly decoupled abstractions that are nigh impossible to wrap your head around.
Dependency injection is useful when you need to decouple for testing. Other than that it's rarely useful.
If your trying to decouple everything because "coupling is bad mmkay" your just cargo culting.
IOC is just anti OO. And I'm anti OO. But when you use IOC for every class yove got a huge fucking problem.
The only time I've seen IOC work well is across module boundaries in a system where modules were boundaries that could not be crossed without the IOC.
Within modules usual namespacing and new constructors were used liberally.
> its defenders should focus on actually showing what modern PHP code looks like
This is one of my personal side projects, written in PHP and Laravel: https://github.com/brendt/aggregate.stitcher.io
Here's a list of all OSS package we maintain at work: https://github.com/spatie
This is one of my personal side projects, written in PHP and Laravel: https://github.com/brendt/aggregate.stitcher.io
Here's a list of all OSS package we maintain at work: https://github.com/spatie
some very interesting stuff in there! Thanks for sharing!
>I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them?
This. If there isn't a linter that bombs out on those things that used to be standard PHP, modern PHP is a non-starter. There are too many bad examples out there that will make their way into modern code if you let them.
This. If there isn't a linter that bombs out on those things that used to be standard PHP, modern PHP is a non-starter. There are too many bad examples out there that will make their way into modern code if you let them.
https://www.exakat.io/
https://github.com/phpstan/phpstan
https://github.com/phan/phan
Lots of great static analyzers to run in CI and during development to catch all kinds of issues.
Also, https://github.com/FriendsOfPhp/PHP-CS-Fixer to clean up code syntax (configurable rules, has good presets).
https://github.com/phpstan/phpstan
https://github.com/phan/phan
Lots of great static analyzers to run in CI and during development to catch all kinds of issues.
Also, https://github.com/FriendsOfPhp/PHP-CS-Fixer to clean up code syntax (configurable rules, has good presets).
Yeah, I've been burned too badly by PHP. There are languages I haven't done in years that I would go back to if there was a compelling need to.
PHP is not that language. Far to many sleepless late nights trying to clean up some security hole. PHP is like that abusive Ex that everyone says has changed. It may be true, in which case, good for PHP
But I won't be putting myself in that position again.
PHP is not that language. Far to many sleepless late nights trying to clean up some security hole. PHP is like that abusive Ex that everyone says has changed. It may be true, in which case, good for PHP
But I won't be putting myself in that position again.
I've been burned by some language that create a poor developer experience with long compilation time and garbage collection.
Maybe V language (vlang.io) could pique your curiosity.
Maybe V language (vlang.io) could pique your curiosity.
You can be burned by every program language if you dont know the in and outs. It all boils down to, pick the right language for the job and more important, know the language you choose.
Seems like to know PHP, though, you need to know all the history that the author has picked up by following the PHP space since forever. Which mysql functions are appropriate, etc. If knowing the language means "being a working programmer in 2010 so that you could gain a working knowledge of the old APIs and some context for the new ones" I'm out. Keep PHP, I'll move to a different language where knowing historical baggage isn't a prerequisite.
Languages have foot guns. Most however don't default to being loaded and already pointed at your foot.
I did know PHP. I was actually pretty good at and wrote non-trival software in it. Even then the relationship was pretty abusive. Even when I was writing bug free code the author of a library I was using wasn't or a co-worker wasn't.
It may in fact be that PHP has improved to the point that the relationship isn't abusive anymore. But I'll never go back to find out. PHP and me were done years ago.
It may in fact be that PHP has improved to the point that the relationship isn't abusive anymore. But I'll never go back to find out. PHP and me were done years ago.
> Server are cheaper and vastly more powerful now than in PHP's infancy
Slightly off-topic, but I think that nowdays it's actually less of an argument than when PHP started becoming popular. The thing is, back in the days, statically typed languages were just bad and unproductive. Today, they are way better, and the fact that I can run my service on $3/month server with 900M of RAM and not think about the price tag at all is actually quite a decent argument to stay away from dynamic languages (but not the main one, tbh).
Slightly off-topic, but I think that nowdays it's actually less of an argument than when PHP started becoming popular. The thing is, back in the days, statically typed languages were just bad and unproductive. Today, they are way better, and the fact that I can run my service on $3/month server with 900M of RAM and not think about the price tag at all is actually quite a decent argument to stay away from dynamic languages (but not the main one, tbh).
With more companies moving to virtualized hosts, I bet performance becomes a real consideration. With most services I've seen, you buy server capacity in doubling increments. So either your application fits into 2 vcores @ 2.2GB with 8GB or RAM, or you step up to 4 vcores and 16GB, with costs also doubling.
Good point! Let's not forget that, unlike the old days, it's kind of a standard to require redundancy and load-balancing from day 1, so not fitting machine's RAM hurts even more.
It's gotta be the easiest stateless system to get started with, right? It's decidedly not a BAD language anymore. It probably has some of the best tooling for said system as well. And it has a GIGANTIC community.
That's worth a lot to most people, I think?
That's worth a lot to most people, I think?
Your comment reads as "I like ruby therefor php is dumb"
> Is performance that much of a big deal for most people? Yes obviously. Performance is important no matter the language.
> the counter-intuitive behaviour of '==' You should learn the languages type system instead of assuming it works how you think. Again this is true of every language.
> I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them? The built in linter gives you a warning that its obsolete.
The inconsistent naming and arguments. Dumb defaults and thousands of functions in a global namespace is the real problem and there is no solution to it. Oh and calling functions is unacceptably slow, that they can and need to fix the rest of this is just I like my language better.
> Is performance that much of a big deal for most people? Yes obviously. Performance is important no matter the language.
> the counter-intuitive behaviour of '==' You should learn the languages type system instead of assuming it works how you think. Again this is true of every language.
> I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them? The built in linter gives you a warning that its obsolete.
The inconsistent naming and arguments. Dumb defaults and thousands of functions in a global namespace is the real problem and there is no solution to it. Oh and calling functions is unacceptably slow, that they can and need to fix the rest of this is just I like my language better.
I haven't used Ruby in about a decade and I was never a fan. I used it as an example of a technology that managed to become popular despite abysmal performance. I think that's proof that in many situations, especially for web development, performance is a very secondary concern.
> You should learn the languages type system instead of assuming it works how you think. Again this is true of every language.
A good language should have good ergonomics. Criticism that `123 == "123foo"` is not reasonable cannot be brushed away by claiming that users should RTFM (although arguably in this case it's less an issue with == than "123foo" being implicitly cast into an integer).
Maybe this has been fixed and is no longer relevant though (I'm citing the Fractal of Bad Design page).
> You should learn the languages type system instead of assuming it works how you think. Again this is true of every language.
A good language should have good ergonomics. Criticism that `123 == "123foo"` is not reasonable cannot be brushed away by claiming that users should RTFM (although arguably in this case it's less an issue with == than "123foo" being implicitly cast into an integer).
Maybe this has been fixed and is no longer relevant though (I'm citing the Fractal of Bad Design page).
What ended PHP were not the worst parts of its design, but upstream's unwillingness to simply change the language for better.
See, as a commercial enterprise (begware as a business) all kinds of "foundations" and sponsorship pools surrounding the language already accumulated a big enough pool of clients who were happy enough with PHP as it was in 4.0 era. They had no intensive to progress. Especially if their business depended on "fixing brokenness"
Open source and sponsorship does not always mix well. Just as with front-end frameworks/libraries that live off sponsorships, eventually it leads to people prioritising pleasing sponsors, and working on pushing their software over improving the software itself.
The current allergy in JS world about genuinely required breaking changes is all about that as well. Any times a talk of genuine "JS 2.0" starts to entertain minds of powerful players in the JS world, there will be tons of people with commercial interest coming and extinguishing the conversation with "no, we absolutely can not ever break anything, ever, even if it is already broken"
Breaking changes in JS world do occur, but most of them being near accidental, security related, or being done as part of actual sabotage like intentional breaking of synchronous AJAX requests after they were shipped.
My logic is, if breaking changes are still unavoidable in JS, why not to do them in a controlled manner, rather than through sneaky sabotage ops like one above?
See, as a commercial enterprise (begware as a business) all kinds of "foundations" and sponsorship pools surrounding the language already accumulated a big enough pool of clients who were happy enough with PHP as it was in 4.0 era. They had no intensive to progress. Especially if their business depended on "fixing brokenness"
Open source and sponsorship does not always mix well. Just as with front-end frameworks/libraries that live off sponsorships, eventually it leads to people prioritising pleasing sponsors, and working on pushing their software over improving the software itself.
The current allergy in JS world about genuinely required breaking changes is all about that as well. Any times a talk of genuine "JS 2.0" starts to entertain minds of powerful players in the JS world, there will be tons of people with commercial interest coming and extinguishing the conversation with "no, we absolutely can not ever break anything, ever, even if it is already broken"
Breaking changes in JS world do occur, but most of them being near accidental, security related, or being done as part of actual sabotage like intentional breaking of synchronous AJAX requests after they were shipped.
My logic is, if breaking changes are still unavoidable in JS, why not to do them in a controlled manner, rather than through sneaky sabotage ops like one above?
I think ended is pretty strong word for a language that powers a huge portion of the web. Yes the lang. has issues and yet WordPress, Magento etc. are used an order of magnitude more than alternatives written in other languages.
Behind the language, the early day of shared web hosting make it affordable.
> but upstream's unwillingness to simply change the language for better.
Wow that could not be more wrong. PHP definitely changes things to make the language better, especially breaking changes. PHP5 changed objects from value types to reference types -- you don't get a bigger change than that.
But they don't just change things willy-nilly -- they do try to maintain backwards compatibility as much as is reasonable otherwise it wouldn't still be PHP.
Wow that could not be more wrong. PHP definitely changes things to make the language better, especially breaking changes. PHP5 changed objects from value types to reference types -- you don't get a bigger change than that.
But they don't just change things willy-nilly -- they do try to maintain backwards compatibility as much as is reasonable otherwise it wouldn't still be PHP.
> Is performance that much of a big deal for most people?
For most people outside VC-funded startups, yes it is. It is also an environmental concern, imagine if 80% of the web was running on ruby.
For most people outside VC-funded startups, yes it is. It is also an environmental concern, imagine if 80% of the web was running on ruby.
Well if 80% of the web was running on ruby there wouldn't be any difference.
Most people don't understand that 99% of performance issues are not caused by language performance but by bad architecture and bad developers.
Always choose the best tool for the job, you rarely get to that scale and quality of software design that only the raw language performance is left to be optimized :)
Most people don't understand that 99% of performance issues are not caused by language performance but by bad architecture and bad developers.
Always choose the best tool for the job, you rarely get to that scale and quality of software design that only the raw language performance is left to be optimized :)
There absolutely would be a difference. IME, people take this "performance is not a major concern when choosing a stack" thing a little too far and apply it too broadly, often without ever having benchmarked anything. When I can handle 300+ requests per second in one implementation and only 50 in another on the same hardware, that's going to be a big difference in costs that matters for everyone except fledgling businesses. I've seen 5-10x differences in performance between languages with none of it being attributable to anything the programmer did being suboptimal --just the language/standard libraries/runtime.
I agree with your costs argument, but my point is you can rarely blame the language. If we bring the frameworks in the discussion it gets even more complicated.
If you build a Rails or Laravel app in the same way you would build a Java app, the Rails/Laravel app will be dead slow. And I've seen that happen. But if you know what you're doing you with Rails/Laravel it will be a long time before you say: we should rewrite this in Go/Rust/Erlang.
The main criteria for me when choosing a tool for the job is: how well does the team know the tool? can they use it at full potential?
I've been involved in java project with 20k monthly cloud costs. Most of the workload is handled in the background by consumers that pull messages from RabbitMQ. I'm pretty sure I could rebuild that with any language while actually reducing the costs because the bottleneck is not the code but the architecture. Would it matter if I would rewrite it in Java instead pf Python or Ruby, in terms of performance, yes, if we need to consider other things, like speed of development, etc it gets complicated again. :)
If you build a Rails or Laravel app in the same way you would build a Java app, the Rails/Laravel app will be dead slow. And I've seen that happen. But if you know what you're doing you with Rails/Laravel it will be a long time before you say: we should rewrite this in Go/Rust/Erlang.
The main criteria for me when choosing a tool for the job is: how well does the team know the tool? can they use it at full potential?
I've been involved in java project with 20k monthly cloud costs. Most of the workload is handled in the background by consumers that pull messages from RabbitMQ. I'm pretty sure I could rebuild that with any language while actually reducing the costs because the bottleneck is not the code but the architecture. Would it matter if I would rewrite it in Java instead pf Python or Ruby, in terms of performance, yes, if we need to consider other things, like speed of development, etc it gets complicated again. :)
5x-10x differences only exist between statically compiled and dynamically compiled languages. The differences in performance between dynamic languages is marginal. As for Ruby it's now slightly faster than Python for most things except C-based numerics.
When you start mixing in things like random number generators, different methods of string manipulation, different data structures and so on, there can be pretty dramatic differences in performance within each category. (static or dynamic)
Every language has building blocks that come with it that are far from equal.
[deleted]
Tbh most of it is wordpress, and that is not terribly inefficient.
I haven't touched wordpress in 8 years, but with old codebases you always inherit a lot of bad design decisions that always have an impact on general performance.
Maybe the wordpress guys have done a great job in rewriting the internals and cleaning things up in the last years, I wouldn't know, I don't follow their progress.
Maybe the wordpress guys have done a great job in rewriting the internals and cleaning things up in the last years, I wouldn't know, I don't follow their progress.
Your parent comment has a point about performance; I don't see why he is downvoted. Crystal is cool, but it is still immature in terms of ecosystem, the language could change, limited library support, and most importantly, not many great engineers. Particularly not outside of the valley.
Performance is a concern for many people, and this is somewhat overlooked because of the number of people here who work for companies where scaling is the primary concern. I think this is what he meant by people outside of VC-backed startups. I know of multiple companies that have had outrageous cloud-hosting bills and have had to hire fancy consultants to fix it.
Performance is a concern for many people, and this is somewhat overlooked because of the number of people here who work for companies where scaling is the primary concern. I think this is what he meant by people outside of VC-backed startups. I know of multiple companies that have had outrageous cloud-hosting bills and have had to hire fancy consultants to fix it.
I simply meant that Crystal lang features ultra high performance, and yet shares much of Rubys syntactical elegance.
Much is built into the standard library and I have to ask what your experience with Crystal has been like so far?
I find pretty much everything I need, and the easy FFI with C takes care of most of the rest (see the Mongo.cr wrapper for the C mongo driver, for example...)
I agree with that assessment. My experience has been reading a good bit into it. I considered learning it a few months ago, but wanted to focus on things that people were currently hiring for. Maybe at some point I will learn more, but I am a bit too broke right now to spend that much time on something that doesn't pay. I don't say that to be disparaging, it goes back to my point about it being immature and not having many engineers or companies using it.
despite it's pre 1.0 status it's arguably more production ready than php ever was/will-be etc.
I bet you rely on things written in PHP way more than you realize.
Exactly. See: Wikipedia, Facebook, WordPress, etc. People talk crap about PHP but it is a workhorse of the web.
indeed. this is largely legacy, but good luck changing that. I can't say that i miss it much, but then I don't work for either of these 2 entities. I'm familiar with what you are speaking about, so I don't think the lack of respect stems from a general ignorance of what you are referring to. It's rather people who have interacted with PHP in the past and didn't enjoy the experience.
That's a fair point.
I'm familiar with the usage stats on wordpress, lol.
I can't say that this is a good thing, but if it suits your needs, have at it.
I see no reason to start any greenfield project in 2019 in PHP unless you literally only know or ever want to learn PHP. I could be wrong in terms of the entire language and it's ecosystem could have changed in the 18-20 years since I deliberated interacted with it last... We have a lot of things since mod php, so there's many other options, most of which don't involve PHP, so I suppose true fans will build their web apps in forth, I dunno...
I see no reason to start any greenfield project in 2019 in PHP unless you literally only know or ever want to learn PHP. I could be wrong in terms of the entire language and it's ecosystem could have changed in the 18-20 years since I deliberated interacted with it last... We have a lot of things since mod php, so there's many other options, most of which don't involve PHP, so I suppose true fans will build their web apps in forth, I dunno...
My main beef with PHP is performance at scale. Doing 100.000+ req/s, the memory footprint for PHP is ... annoying.
Maybe it isn't, but other languages/frameworks have improved the past ten years as well. I don't see the selling point in building something in PHP in 2019 when you have similar if not better/more mature languages/frameworks at your disposal.
Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more stable surface to build upon it? I really fail to see where PHP has its place in 2019. For your "build a minimally viable product fast", the above win. For enterprise stuff, the good old Java/C# win.
Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more stable surface to build upon it? I really fail to see where PHP has its place in 2019. For your "build a minimally viable product fast", the above win. For enterprise stuff, the good old Java/C# win.
Stable? Big e-shop I wrote in 2005 in PHP works without any compatibility issues until today. No need to re-compile anything, to fix bugs in the runtime, etc.
Ruby was some obscure language just gaining acceptance back then, node didn't exist, golang didn't exist, C# has just invented iterators.
PHP showed over the years that it was a stable and painless surface to build on. And I don't see it changing.
Ruby was some obscure language just gaining acceptance back then, node didn't exist, golang didn't exist, C# has just invented iterators.
PHP showed over the years that it was a stable and painless surface to build on. And I don't see it changing.
Referencing "go" and somehow smuggling in 'mature' in there without mentioning the dependency management situation is ... disheartening. There may be many reasons to like the go language, but the dep management issue doesn't seem solved at all (last viewed in Nov 2018 - maybe it's all magically better and there's 80% community consensus and everything is smooth now?)
> Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more stable surface to build upon it?
One of the most understated pros of PHP (IMHO) is that it's so easy to get setup with. You can start hacking on something so quickly. In my experience, Go has not been like that. Node.js also was never as quick.
One of the most understated pros of PHP (IMHO) is that it's so easy to get setup with. You can start hacking on something so quickly. In my experience, Go has not been like that. Node.js also was never as quick.
But other languages like Python and Ruby are even easier to get started with than PHP.
I worked with rails in the 1.x and 2.x days. Deployment was a joke and you had to restart the whole Ruby server to update scripts.
PHP you simply refresh your browser page to see the changes. This has all changed in recent years and rails deployment/debugging is much smoother.
PHP you simply refresh your browser page to see the changes. This has all changed in recent years and rails deployment/debugging is much smoother.
Not really the case with Docker. I can spin up a container targeting any language in less than 10 seconds, mount a volume and start hacking away. Best of all, it doesn't pollute my system in any way. We shouldn't pick a language just by how easy it is to get started, a decision which often leads to a lot of regrets. Pick whatever is good for the project not your disposition.
But I am productive with PHP, I don't know docker or related tool chains, I am more productive in PHP then Python(because of my own experience and dilikes for Python like syntax), the ecosystems are equivalent for my task so I would use PHP.
Buf if PHP was not good enough then sure I would always use the best task for the job(I used Java for a different project or even use a bash script and pipe UNIX tools)
That's how I feel. I'm glad to hear it's improved, but "not as bad as it used to be" isn't a compelling argument that would make me consider PHP over Elixir/Go.
It only means you don't know PHP enough. No offense, I moved from PHP to Rust after 11 years of using it, but it was definitely not because of tools or speed of development. I just prefer strict typing and Rust's errors handling.
If somebody prefers dynamic languages and want to create some prototype - it can be done even without any frameworks, quickly enough, with millions of libraries for any need.
If somebody prefers dynamic languages and want to create some prototype - it can be done even without any frameworks, quickly enough, with millions of libraries for any need.
Very good documentation, stable and widely used is the strong points for php.
And yet ~everything in https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ is still true.
All that's happened is that the language is even more complex, has even more baggage.
All that's happened is that the language is even more complex, has even more baggage.
Everything in fractal of bad design wasn't even true when it was written! 1/3 of that article was factually incorrect when written and still is. 1/3 is just opinion.
My rebuttal from 2012: https://news.ycombinator.com/item?id=3821029
My rebuttal from 2012: https://news.ycombinator.com/item?id=3821029
It sounds a bit like you are just trolling this thread?
The PHP community has made a ton of improvements over the last few years, surely you can't criticise a project for improving?
The PHP community has made a ton of improvements over the last few years, surely you can't criticise a project for improving?
You could make a similar article about Ruby, Python, or Node.js. None of these are bad languages, but you can't write a perfect language, because languages are designed to be used day in and day out by people. I like Python and I've found that some of the things I really like about Python are the same things other people dislike about it.
PHP has a lot to like about it - otherwise it wouldn't be as popular as it is.
PHP has a lot to like about it - otherwise it wouldn't be as popular as it is.
I'm not really sure why this comment is getting downvoted, but literally every single thing in that post still holds true.
No, it's not. PHP has disabled or removed the major anti-features like magic quotes, globals, URL includes and the bad mysql extension. It has a proper AST-compatible parser which removed tons of quirks, and added syntax sugar to look more normal to outsiders.
The remaining things are:
• the endless whine about inconsistent underscores in function names and haystack/needle. These are a bad look, but aren't really an obstacle to using the language (PHP devs memorize the common functions, rely on IDE or docs for the rest, and move on).
• being offended about use of backslash as the namespace separator. It really doesn't matter at all.
• old constructs and edge cases that exist, but are not used in new code.
• general upset about dynamically-typed languages, and all the consequences and compromises that dynamic typing brings.
That post is just a rant. It presents insignificant/arbitrary choices as flaws (e.g. "clone is an operator?!" — so what?). Some complaints are totally ridiculous, e.g. exceptions thrown in destructors were fatal errors, and that was bad. When the restriction has been removed, the post has been updated to complain that this is bad too, because now you can throw literally everywhere! Apparently, no matter what PHP does, it's bad.
The remaining things are:
• the endless whine about inconsistent underscores in function names and haystack/needle. These are a bad look, but aren't really an obstacle to using the language (PHP devs memorize the common functions, rely on IDE or docs for the rest, and move on).
• being offended about use of backslash as the namespace separator. It really doesn't matter at all.
• old constructs and edge cases that exist, but are not used in new code.
• general upset about dynamically-typed languages, and all the consequences and compromises that dynamic typing brings.
That post is just a rant. It presents insignificant/arbitrary choices as flaws (e.g. "clone is an operator?!" — so what?). Some complaints are totally ridiculous, e.g. exceptions thrown in destructors were fatal errors, and that was bad. When the restriction has been removed, the post has been updated to complain that this is bad too, because now you can throw literally everywhere! Apparently, no matter what PHP does, it's bad.
> (PHP devs memorize the common functions..
Nope (c) Me, after 5 years on trying to but still falling back to googling every 20 minutes despite years and years of using the language.
... And just writing code without looking into docs much after a week with ruby
Nope (c) Me, after 5 years on trying to but still falling back to googling every 20 minutes despite years and years of using the language.
... And just writing code without looking into docs much after a week with ruby
I'm quite shocked that a common complaint of any language is function syntax. Maybe it's been awhile since I've used PHP, but is it really worse than any other language? The problem with PHP is that, at least years ago, it had no equivalent of C's man pages. In C, you're constantly doing "man memchr" or what have you. Perl has "perldoc -f sort".
Don't get me started on Ruby, though. Wading through a tower of classes to figure out where and how some method is defined, only to much later find out it was actually created by define_method or method_missing is absolute torture. And yeah, I know the REPL can provide this info to you. The point is: source code should be obvious in how it functions. Not obscure things through cleverness.
Don't get me started on Ruby, though. Wading through a tower of classes to figure out where and how some method is defined, only to much later find out it was actually created by define_method or method_missing is absolute torture. And yeah, I know the REPL can provide this info to you. The point is: source code should be obvious in how it functions. Not obscure things through cleverness.
What are you talking about? I have been using php.net/{funcname} since forever.
I didn't use PHP for 2 years and upon coming back still know most of the common functions and the ones I don't the IDE helps with, so I am not sure why you're having such issue. What functions are you using that you don't remember the names for?
Ruby does not have the best standard library, just good enough. replying to the question - basically all of them, from strrpos, str_ireplace to array_search. Also, Null, false, 0, "" etc are adding degree of chaos
And on its quest towards JIT the language becomes less and less dynamically typed. strict_types=1 is already a standard in most major applications and all the cleanup that has been done already, such as count() raises an error if you try to count a non-countable variable, and many more.
If you read the article, it's full of notes about "this was fixed in 5.4" or whatever. A decent chunk of the remainder has been fixed in the 7.x series, and some of the remainder is slated to be solved in the (as of yet, unreleased) 8.0 version.
Just scrolling through at random:
> A function’s return value can’t be hinted.
But of course, this has been incorrect for years. The next was fixed in 5.3, the next two be fixed in 7.4, the next was fixed in 5.4, etc., etc. Which is fine; it's an old article, and one which was deeply influential on PHPs development, but it's completely false to suggest that "literally every single thing in that post still holds true". Many are outdated.
Just scrolling through at random:
> A function’s return value can’t be hinted.
But of course, this has been incorrect for years. The next was fixed in 5.3, the next two be fixed in 7.4, the next was fixed in 5.4, etc., etc. Which is fine; it's an old article, and one which was deeply influential on PHPs development, but it's completely false to suggest that "literally every single thing in that post still holds true". Many are outdated.
I agree some of it has been fixed - but definitely not all of it, or even anywhere close. Some highlights of why I wouldn't rely on PHP in my stack:
- A fair chunk of phpsadness is still unfixed - e.g. https://bugs.php.net/bug.php?id=49664 where recursing too much producing a segfault is Not A Bug.
- PHP's release machines were compromised. Let's not worry who downloaded it. http://news.php.net/php.internals/77695
- PHP 6. There's no hope of making PHP work in Unicode, ever. It's like Python 3, except half way through, they went 'let's not even bother'.
- The rebuttal elsewhere on this thread points to the very problem in the PHP community:
>> PHP’s one unique operator is @ (actually borrowed from DOS), which silences errors.
> Yup. I find it very useful on the unlink() function which will raise an error if the file you're trying to delete doesn't exist.
That just demonstrates that unlink is broken! PHP's error handling is some horrible collection of C, C++ and just spamming stderr.
- A fair chunk of phpsadness is still unfixed - e.g. https://bugs.php.net/bug.php?id=49664 where recursing too much producing a segfault is Not A Bug.
- PHP's release machines were compromised. Let's not worry who downloaded it. http://news.php.net/php.internals/77695
- PHP 6. There's no hope of making PHP work in Unicode, ever. It's like Python 3, except half way through, they went 'let's not even bother'.
- The rebuttal elsewhere on this thread points to the very problem in the PHP community:
>> PHP’s one unique operator is @ (actually borrowed from DOS), which silences errors.
> Yup. I find it very useful on the unlink() function which will raise an error if the file you're trying to delete doesn't exist.
That just demonstrates that unlink is broken! PHP's error handling is some horrible collection of C, C++ and just spamming stderr.
Rather than chasing MVw or OO trends of the JavaScript ecosystem and become more like JavaScript or Java, so to say, why don't the PHP developers identify and build on the unique strengths of PHP? Which are IMO: the large installed base in classic web hosting, and the original purpose of PHP as a high-level scripting language embedded in otherwise static HTML as in "<?php ...>". There is a huge room for improvement there since PHP's quick-and-dirty hackjob of a page-embedded language isn't HTML-aware and thus prone to injection attacks, which has caused uncountable attacks, botnets, and other problems for PHP and non-PHP sites alike, in particular when coupled with PHP's target demographic. This is especially painful because PHP embeds via SGML mechanisms (processing instructions), when SGML has all the features needed for context-aware, injection-free templating. If PHP can improve that story, and stop becoming the language of unintended consequences and usage-outside-its-comfort-zone, then it might earn a lot more respect and consideration.
> why don't the PHP developers identify and build on the unique strengths of PHP? Which are IMO: [...] the original purpose of PHP as a high-level scripting language embedded in otherwise static HTML as in "<?php ...>".
I really don't think that's a strength of PHP. It's very bad at that, and that's not been a focus of the language for decades. PHP, even with the work you suggest, is always going to be inferior compared to something like Liquid, Jinja, or Twig.
It's arguably true that PHP should focus on improving the things that make people use it, but nobody is using it because of that. Even the ability to run PHP on shared hosting is increasingly irrelevant as we move past that being a useful feature.
I really don't think that's a strength of PHP. It's very bad at that, and that's not been a focus of the language for decades. PHP, even with the work you suggest, is always going to be inferior compared to something like Liquid, Jinja, or Twig.
It's arguably true that PHP should focus on improving the things that make people use it, but nobody is using it because of that. Even the ability to run PHP on shared hosting is increasingly irrelevant as we move past that being a useful feature.
Your claims are vague, do you have a specific example of a new feature and a new mainstream framework that has the security issues you mention?
I think the point is that if you use a "new mainstream framework", you lose the traditional unique strengths of PHP by using it essentially the same way as you would any other language, so you might as well use a different language.
So instead of trying to be like other languages but with worse syntax and weird quirks, PHP could try to improve on the things that make it different and lead to its initial popularity.
So instead of trying to be like other languages but with worse syntax and weird quirks, PHP could try to improve on the things that make it different and lead to its initial popularity.
The old security issues with PHP were if you used SQL strings queries without sanitizing user input, or using eval or a bad configured server where someone could upload a file and had it be executed.
So you can use PHP without a framework, you need a good configured server, use the correct SQL related functions and practices.
Example for a project you have a third party payment system that can send you a POST request when an event happens, you want to log this event in the database and maybe trigger a simple thing. I can(and done this) with just 1 PHP file, no third party dependencies and I did not had to install anything on the server(because PHP is already there) so no installing node,npm,npm packages maybe git .
You will need a framework if you have a big project, you would be wasting a lot of time to do the logins, user management, view rendering from scratch and probably have a lot of bugs. There are minimalistic frameworks and libraries and you can use something that matches your need.
So you can use PHP without a framework, you need a good configured server, use the correct SQL related functions and practices.
Example for a project you have a third party payment system that can send you a POST request when an event happens, you want to log this event in the database and maybe trigger a simple thing. I can(and done this) with just 1 PHP file, no third party dependencies and I did not had to install anything on the server(because PHP is already there) so no installing node,npm,npm packages maybe git .
You will need a framework if you have a big project, you would be wasting a lot of time to do the logins, user management, view rendering from scratch and probably have a lot of bugs. There are minimalistic frameworks and libraries and you can use something that matches your need.
Exactly my point. Thanks for explaining it much better than I could.
Your point as related to security, so mention what security problems are in modern PHP and frameworks.
I actually see no reason to use PHP over other languages except if the project already has a large codebase in PHP.
In all other cases I keep thinking: "Have you seen Django yet?" And probably you can substitute ROR, Node, ASP.NET Core etc
In all other cases I keep thinking: "Have you seen Django yet?" And probably you can substitute ROR, Node, ASP.NET Core etc
If you want integrated scripting with web pages PHP cannot compete with the language already being embedded in pages to run on the client. The rise of Node et al was in large part the fall of PHP.
I worked at a small PHP shop for about two years. There was a ton of legacy code that was utterly terrifying: a 13-deep nested `if` and the like, global variables, etc.
I convinced my boss to let me start using Laravel. It made development worlds more sane. It made development orders of magnitude easier. Laravel does a lot for you, and they’ve thought about how to solve some tricky problems in clever ways.
That being said, I would never recommend PHP as the language to solve any given problem. It is now less of a terrible language and more of simply a mediocre language. I can’t think of anything it does particularly better than another language. For any given problem, there is most certainly a better language to solve it, be it Ruby, Elixir, Clojure, Rust, etc.
I’ve been working with Elixir and Phoenix for web development for a few months now, and it is sooooo much better. It’s hard for me to enumerate all the things, small and large, that reduce developer friction in contrast to even PHP’s best framework.
I convinced my boss to let me start using Laravel. It made development worlds more sane. It made development orders of magnitude easier. Laravel does a lot for you, and they’ve thought about how to solve some tricky problems in clever ways.
That being said, I would never recommend PHP as the language to solve any given problem. It is now less of a terrible language and more of simply a mediocre language. I can’t think of anything it does particularly better than another language. For any given problem, there is most certainly a better language to solve it, be it Ruby, Elixir, Clojure, Rust, etc.
I’ve been working with Elixir and Phoenix for web development for a few months now, and it is sooooo much better. It’s hard for me to enumerate all the things, small and large, that reduce developer friction in contrast to even PHP’s best framework.
You forgot one thing: PHP has a far larger community and packages compared to exotic languages like Elixir.
Everything is documented and there are tons of resources out there to solve a problem.
It's like C++ for the web. Why does C++ still live? Community, extensively tested and adopted by large organizations. Well PHP is the same. Until big companies are out there using PHP (consider Vimeo or Flixbus or Groupon as example), because it is perfomant, it will fail to die.
I agree with you: strong community support is essential in the survival of any language/technology. PHP has a large community and a dizzying number of packages. That helps a lot. But I can think of a number of languages (Python, Perl, Ruby) that also have large communities and vast numbers of libraries at their disposal. Therefore, I don't think you could pick PHP over any of those just because "it has more libraries".
Furthermore, Elixir, while it has fewer libraries and a smaller community, is growing fast. The core language is also exceptionally well documented and discoverable. It has libraries that cover essentially all your common use cases.
I guess what I want to say is, I'm happy PHP is getting better for all the programmers stuck using it. There's no reason to use it for anything new, because there's always a better tool out their for your job.
Furthermore, Elixir, while it has fewer libraries and a smaller community, is growing fast. The core language is also exceptionally well documented and discoverable. It has libraries that cover essentially all your common use cases.
I guess what I want to say is, I'm happy PHP is getting better for all the programmers stuck using it. There's no reason to use it for anything new, because there's always a better tool out their for your job.
I'm working in a vanilla PHP codebase right now, and I see all sides - the fractal design fails and the surprising improvements to the language. I've just read up on the architecture of Laravel, and given the public opinion of it, must be a very nice framework.
What strikes me most about PHP is the fundamental request/response execution model. Your execution context begins when a request is received and ends when we send the last byte or terminate the request. There's no startup healthchecks, no cache warming or any other bootstrapping of your service unless you jump through convoluted hoops on your own. Your service is either accepting requests or it isn't. You either lazy load your data into APCu or you don't. I've leveraged AWS healthchecks to achieve these in the past, but that path is not very maintainable.
Inevitably in the course of maintaining a service, I find use cases for a phase of execution that should occur before the server is live or shared static memory that should be available at all times, but (unless I don't know something) those are things that PHP doesn't do.
This is the reason that I find PHP to be a bizarro language - for its fundamental design assumption!
What strikes me most about PHP is the fundamental request/response execution model. Your execution context begins when a request is received and ends when we send the last byte or terminate the request. There's no startup healthchecks, no cache warming or any other bootstrapping of your service unless you jump through convoluted hoops on your own. Your service is either accepting requests or it isn't. You either lazy load your data into APCu or you don't. I've leveraged AWS healthchecks to achieve these in the past, but that path is not very maintainable.
Inevitably in the course of maintaining a service, I find use cases for a phase of execution that should occur before the server is live or shared static memory that should be available at all times, but (unless I don't know something) those are things that PHP doesn't do.
This is the reason that I find PHP to be a bizarro language - for its fundamental design assumption!
This execution model is just good old CGI scripts [0].
[0]: https://en.wikipedia.org/wiki/Common_Gateway_Interface
[0]: https://en.wikipedia.org/wiki/Common_Gateway_Interface
Actually you can compile PHP code and optimize it.
Thanks for sharing. The thing that I am most concerned about with PHP is not, strictly speaking, the language itself. The syntax is slightly odd but otherwise fine. And the semantics are much the same as any similar language.
The real problem that I find with PHP is that the designers seem (from an outside perspective) to take a similar approach towards language backward-compatibility that, for example, C/C++ have. There is some rejection of the idea of getting rid of the old, bad stuff. Plenty of new, cool features is all well and good - but there are still holes in the floor that new learners will fall through.
[To clarify, I understand the case made by the C/C++ committees on supporting old code. But nobody's programming pacemakers in PHP, one would hope.]
The real problem that I find with PHP is that the designers seem (from an outside perspective) to take a similar approach towards language backward-compatibility that, for example, C/C++ have. There is some rejection of the idea of getting rid of the old, bad stuff. Plenty of new, cool features is all well and good - but there are still holes in the floor that new learners will fall through.
[To clarify, I understand the case made by the C/C++ committees on supporting old code. But nobody's programming pacemakers in PHP, one would hope.]
The amount of legacy applications being run on the internet is huge. Breaking stuff would put a great financial burden on the companies running those.
It is a sensible approach IMHO.
What kind of bad stuff are you talking about? If you talk about function names and parameter ordering not being consistent that is not an issue for developers using the language daily, most of them are using an IDE so it doesn't matter as much as people who don't use it say.
It is a sensible approach IMHO.
What kind of bad stuff are you talking about? If you talk about function names and parameter ordering not being consistent that is not an issue for developers using the language daily, most of them are using an IDE so it doesn't matter as much as people who don't use it say.
Those legacy applications won't ever be upgraded to that theoretical and slimmed down PHP anyway, so I don't see a problem.
Old PHP projects can be upgraded in the present because backwards compatibility exists, as i metnioend in other comment I done such a small upgrade and I hat to change only 1 deprecated function with a different one.
If this would not have been possible the project would have still be running on an old version without security fixes and slower(eating more electricity so bad for environment)
If this would not have been possible the project would have still be running on an old version without security fixes and slower(eating more electricity so bad for environment)
If you say so. ~5 years ago I had to work a full week, 8h a day, to fully upgrade a medium-sized website from PHP 5.2 to 5.4, and eventually gave up. Most of the time was spent trying to cope with different datetime parsing idiosyncrasies.
I am sorry you had such a bad experience, can I ask you to give me some link or details about your issues with datetime , I want to learn about the problems I do not doubt you.
I had some problems with mysql updates though, new versions had different)better default behavior). we were using an ORM for the project but the initial setup and migrations were made in plain SQL and those needed to be updated. As an example in older mysql you could have a timestamp column NULL with no default value set and now we needed to fix to set a curenttime as default.
I had some problems with mysql updates though, new versions had different)better default behavior). we were using an ORM for the project but the initial setup and migrations were made in plain SQL and those needed to be updated. As an example in older mysql you could have a timestamp column NULL with no default value set and now we needed to fix to set a curenttime as default.
> If you talk about function names and parameter ordering not being consistent that is not an issue for developers using the language daily
It does feel like this is analogous to saying "the holes in the floor of our building aren't an issue - all the senior devs know where they are by now"
It does feel like this is analogous to saying "the holes in the floor of our building aren't an issue - all the senior devs know where they are by now"
I think that is largely changing. Quite a lot of breaking changes to clean up ancient cruft are slated for 8.0. For example, PHP has infamously had broken ternaries (they're left associative, which is never what you want, not how any other language works, and a rich source of bugs). Nested ternaries are being deprecated and will be removed completely in 8.0; in a future version correct (right associative) behaviour will be able to be added.
Obviously there's a long road to go, but being willing to change how an operator works on that level demonstrates a willingness to break compatibility when necessary.
Obviously there's a long road to go, but being willing to change how an operator works on that level demonstrates a willingness to break compatibility when necessary.
I heavily agree with this. The standard library, whilst great, has so many inconsistencies which I wish they'd fix and standardise.
Yes, that is the reason why i chose to write stuff in it (also because i knew it relatively well). PHP has not been fancy for 15 years now , which is a good thing if you have more interesting things to do rather than refactoring your old websites because some college kids wanted to "move fast and break things that work". If PHP decides to go with major breaking changes, i will probably quit it.
As a primary PHP developer, PHP has improved by leaps and bounds in the ten years I've been working with it, however there's still a major fundamental issue that has seen improvement but remains unresolved: function overhead.
Contrived example: - https://3v4l.org/eEtFl - https://3v4l.org/8QMFh
Two identical ways to do the same thing, one with nicer FP-like syntax, but because of function overhead even on 7.3.x it's significantly slower.
If you're building large-scale PHP applications you have to stay away from a bunch of shiny new features in anything remotely performance-sensitive, and it causes you to write worse code in general (e.g. this monolith would be a lot cleaner as multiple sub-functions, but it's going to be called in a loop 5 million times so I have to keep it ugly).
With compiled languages you can write clean code and then have the compiler optimize it. With PHP, you have to make development-time sacrifices in legibility and maintainability in order to not make runtime sacrifices in performance, which is both worse as an any-stage dev and a huge footgun as a junior dev.
Contrived example: - https://3v4l.org/eEtFl - https://3v4l.org/8QMFh
Two identical ways to do the same thing, one with nicer FP-like syntax, but because of function overhead even on 7.3.x it's significantly slower.
If you're building large-scale PHP applications you have to stay away from a bunch of shiny new features in anything remotely performance-sensitive, and it causes you to write worse code in general (e.g. this monolith would be a lot cleaner as multiple sub-functions, but it's going to be called in a loop 5 million times so I have to keep it ugly).
With compiled languages you can write clean code and then have the compiler optimize it. With PHP, you have to make development-time sacrifices in legibility and maintainability in order to not make runtime sacrifices in performance, which is both worse as an any-stage dev and a huge footgun as a junior dev.
Do you really find function overhead to be that great of an impact on performance? I work on a php app that sees around 15k/rps and I use a lot of functional patterns (feels best to me, my brain was formed in a lispy way).
By far database time remains our biggest bottleneck, especially since we finally made it onto PHP7
By far database time remains our biggest bottleneck, especially since we finally made it onto PHP7
> Do you remember the popular "PHP: a fractal of bad design" blog post? The first time I read it, I was working in a crappy place with lots of legacy PHP projects. This article got me wondering whether I should just quit and go do something entirely different than programming.
Seems like a pretty extreme reaction - how about trying a job with something other than PHP?
Seems like a pretty extreme reaction - how about trying a job with something other than PHP?
You're absolutely right. I think it's fair to say that I was closing in on a burnout, which made me think irrational.
Like I said: I was lucky being able to switch jobs, and re-discover my passion for programming
Like I said: I was lucky being able to switch jobs, and re-discover my passion for programming
php > echo count(get_defined_functions(TRUE)['internal']);
1196
While parent's comment seems to attract some downvotes, there is a good point hidden beneath: PHP (mostly) keeps backward compatibility.
This means that old and unsafe functions that should not be used anymore are not removed from the language and are still available to use.
Coupled with a lot of outdated documentation and tutorials that advocate using these functions, it becomes a big issue. For example, many tutorials use "==" when "===" should be the default. Deprecated functions are used in many tutorials as well.
Coupled with a lot of outdated documentation and tutorials that advocate using these functions, it becomes a big issue. For example, many tutorials use "==" when "===" should be the default. Deprecated functions are used in many tutorials as well.
Yeah and they should add basic features like lambdas and rewrite the entire standard library to support that while they are at it and when they are done with all of that could they potentially provide a separate syntax similar to facebook's reason? It's no longer the same language anymore if you change everything and therefore there is no reason to waste time improving PHP.
It's funny how shitty decisions in tech always seems to win the masses, only because it's easier to get started with. And only 10 or 20 years later, a great amount of effort is put into patching all of this.
"Good tech" is created by people with a lot of knowledge of a specific domain. For them, it all makes sense, but the mental modal does not map to newcomers.
"Bad tech" is usually forgiving (messy syntax, accepting bad data etc), so people don't get stuck.
The solution is to have good tech with proper tooling and hints / error/configuration reporting.
apache, php, mongo, mysql, javascript.. They all have the exact same strengths, weaknesses, quirks, bad decisions, and mass adoption.
"Good tech" is created by people with a lot of knowledge of a specific domain. For them, it all makes sense, but the mental modal does not map to newcomers.
"Bad tech" is usually forgiving (messy syntax, accepting bad data etc), so people don't get stuck.
The solution is to have good tech with proper tooling and hints / error/configuration reporting.
apache, php, mongo, mysql, javascript.. They all have the exact same strengths, weaknesses, quirks, bad decisions, and mass adoption.
I think the way to analyze a language and framework should be: "what does this framework permit the worst developer on the team to do?"
I think the story for Php in this regard has not been a good one historically.
You can put processes like PR review, and add coding standards, but getting things done will always trump those things, especially when you are bootstrapping.
If you can tell me modern PHP is better than the alternatives at preventing bad behavior (or encouraging good behavior) then I'm interested. But, this post didn't move me to change my mind there.
I think the story for Php in this regard has not been a good one historically.
You can put processes like PR review, and add coding standards, but getting things done will always trump those things, especially when you are bootstrapping.
If you can tell me modern PHP is better than the alternatives at preventing bad behavior (or encouraging good behavior) then I'm interested. But, this post didn't move me to change my mind there.
For example, coding standards:
`There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.`
https://github.com/php-fig/fig-standards/blob/master/accepte...
A language that has to permit this kind of thing (or thinks it has to) is just going to lead to developer infighting. This is an important issue because GitHub PRs are going to be unreadable if one developer can insist that "this line needs to be 145 characters..." and then no-one can diff changes to that code. You can break the PR process with this kind of thing.
`There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.`
https://github.com/php-fig/fig-standards/blob/master/accepte...
A language that has to permit this kind of thing (or thinks it has to) is just going to lead to developer infighting. This is an important issue because GitHub PRs are going to be unreadable if one developer can insist that "this line needs to be 145 characters..." and then no-one can diff changes to that code. You can break the PR process with this kind of thing.
I'm not sure what this has to do with PHP as a language... barring the few languages with a very strong default formatting convention like Go, code style differences are both a fact of life and not terribly problematic (set rules for the project and enforce them automatically).
I'm hiring PHP developers in Boston!
Doctrine, symfony, AWS, all backend API work.
Doctrine, symfony, AWS, all backend API work.
If you are doing API with Symfony you may want to check API Platform: https://api-platform.com/
Developing a database driven web site with a modern PHP framework, like Laravel, is very productive and quite pleasant. PHP is fast enough. It's simple to deploy. It's easy for "non-engineers" to get involved with: designers can edit templates, see the result instantly, no build issues, etc.
For my day job, I do Python and Java... For side projects that are database-driven web apps, PHP is perfect.
For my day job, I do Python and Java... For side projects that are database-driven web apps, PHP is perfect.
The sad thing is that nothing else has come along to fill the niche that PHP fills. Here are the key advantages of a PHP like language:
1. Low barrier to entry. An HTML document is pretty much a valid PHP program. You can add as much or as little code execution as you want to it. While at a certain point you should probably use templating (to handle things like escaping automatically, etc) but a low barrier to entry really helps get people on.
2. PHP has a stateless functional core. All the system functions are part of the web server binary. There's no loading some giant object tree just to print something to the screen. This is huge because of...
3. Resource management for serving HTTP requests is, to me, basically ideal in that you create a bunch of stuff, spit out a result and then tear everything down. It's hard to leak resources this way. No garbage collection oddities to deal with. The Java equivalent to this was the servlets API (years ago) but it doesn't share the same issues;
4. No multithreading on a per-request basis so you don't have to deal with race conditions at all in user code;
5. An opcode cache sufficiently closes the gap on code performance in the vast majority of cases at little to no cost to the end developer; and
6. Typically you can just hit reload on your browser and immediately find out if something works. That's really nice.
Big things missing from PHP:
1. A good type system. I use Hack at work (Facebook) and this solves a lot of problems; and
2. Cooperative multitasking via async/await semantics (again, Hack has this).
I'm a big fan of PHP not making breaking changes (badly) like Python did. You can't fix the inconsistent argument ordering in standard functions ("is it needle, haystack or haystack, needle?") but it basically doesn't matter at this point. I use an IDE that tells me the correct order anyway so who really cares? The way to handle that is to create new versions that are consistent.
Hack has these collections: vec, keyset and dict. These essentially replace array (side note: PHP maintaining insertion order on array is such a hugely useful feature). They have a consistent set of library functions (in C\, Vec\, Keyset\ and Dict\).
One other thing that I found hugely useful when I first did PHP was preg_replace_callback. I found this so useful that when I did Java after that I basically write a version of this function.
So anyway, there are a ton of legacy problems with PHP but nothing else has that same set of desirable characteristics IMHO and I really wonder why not.
1. Low barrier to entry. An HTML document is pretty much a valid PHP program. You can add as much or as little code execution as you want to it. While at a certain point you should probably use templating (to handle things like escaping automatically, etc) but a low barrier to entry really helps get people on.
2. PHP has a stateless functional core. All the system functions are part of the web server binary. There's no loading some giant object tree just to print something to the screen. This is huge because of...
3. Resource management for serving HTTP requests is, to me, basically ideal in that you create a bunch of stuff, spit out a result and then tear everything down. It's hard to leak resources this way. No garbage collection oddities to deal with. The Java equivalent to this was the servlets API (years ago) but it doesn't share the same issues;
4. No multithreading on a per-request basis so you don't have to deal with race conditions at all in user code;
5. An opcode cache sufficiently closes the gap on code performance in the vast majority of cases at little to no cost to the end developer; and
6. Typically you can just hit reload on your browser and immediately find out if something works. That's really nice.
Big things missing from PHP:
1. A good type system. I use Hack at work (Facebook) and this solves a lot of problems; and
2. Cooperative multitasking via async/await semantics (again, Hack has this).
I'm a big fan of PHP not making breaking changes (badly) like Python did. You can't fix the inconsistent argument ordering in standard functions ("is it needle, haystack or haystack, needle?") but it basically doesn't matter at this point. I use an IDE that tells me the correct order anyway so who really cares? The way to handle that is to create new versions that are consistent.
Hack has these collections: vec, keyset and dict. These essentially replace array (side note: PHP maintaining insertion order on array is such a hugely useful feature). They have a consistent set of library functions (in C\, Vec\, Keyset\ and Dict\).
One other thing that I found hugely useful when I first did PHP was preg_replace_callback. I found this so useful that when I did Java after that I basically write a version of this function.
So anyway, there are a ton of legacy problems with PHP but nothing else has that same set of desirable characteristics IMHO and I really wonder why not.
Not only did PHP clean itself up a lot in the last few years, it also managed to do so while maintaining a great deal of backward compatibility.
It's not uncommon to pick up a really old library that used to work in PHP 4.4, stick it in a PHP 7.3 project -- maybe you need it to import legacy data -- and experience no issues whatsoever. You can probably also use the library in question in parallel with a modern dependency management system like composer, or any framework built on top of it, without any conflicts. This is Windows-level backward compatibility, and I mean it in a good way.
Why would anyone want that in this day and age? Because there are tons of legacy PHP code that still power a very large fraction of the web. Not everyone is writing new projects from scratch. Not everyone can afford a total rewrite. PHP's backward compability allows people to transition gradually at their own pace. It might not be sexy, but it gets the work done, and it just keeps working. That's all that matters for many, many businesses out there.
It's not uncommon to pick up a really old library that used to work in PHP 4.4, stick it in a PHP 7.3 project -- maybe you need it to import legacy data -- and experience no issues whatsoever. You can probably also use the library in question in parallel with a modern dependency management system like composer, or any framework built on top of it, without any conflicts. This is Windows-level backward compatibility, and I mean it in a good way.
Why would anyone want that in this day and age? Because there are tons of legacy PHP code that still power a very large fraction of the web. Not everyone is writing new projects from scratch. Not everyone can afford a total rewrite. PHP's backward compability allows people to transition gradually at their own pace. It might not be sexy, but it gets the work done, and it just keeps working. That's all that matters for many, many businesses out there.
I have kept up with PHP since I replace my own 'PHP' which was a Perl cgi script. It is not as crappy as it was and Laravel is quite nice, but there is still so much crap in there, compared to modern languages, libraries and frameworks, that I only do maintenance on projects (upgrade Laravel, port to Laravel etc) but would never start a new project on it.
eh my problem with php never really was performance (up to a point) or the language itself, it was the default library making figuring out every operation an exercise in googling
like, why the weird _ difference between strtok and str_split, why str_replace has the search first and string as third parameter but in strpos the source string is the first parameter and then the search term the second
it's all confusing and weird and while someone that's a specialist is maybe at ease with this, for a generalist going in and out the language as needed it's frustrating.
like, why the weird _ difference between strtok and str_split, why str_replace has the search first and string as third parameter but in strpos the source string is the first parameter and then the search term the second
it's all confusing and weird and while someone that's a specialist is maybe at ease with this, for a generalist going in and out the language as needed it's frustrating.
When I did more PHP I quickly ended up writing my own sort of standard library with consistent functions and unit testing. It doesn’t really take much time and makes things much more predictable.
I think we all do this to a degree.
If you look most major projects have equivalents e.g. Laravel has Str.
Same with collection types, SPL is an abortion so everyone maps over array which isn't really an array to pretend we have proper collections/lists etc.
It's mostly fine but there are times when it's annoying.
If you look most major projects have equivalents e.g. Laravel has Str.
Same with collection types, SPL is an abortion so everyone maps over array which isn't really an array to pretend we have proper collections/lists etc.
It's mostly fine but there are times when it's annoying.
With JS it’s pretty much the same. It’s standard library is so weak that you pretty much have to write your own.
So much of the web is powered by PHP. Wikipedia (MediaWiki software) and Facebook are two of the largest footprints of usage. And of course, WordPress. PHP has a lot of firepower behind it.
The Facebook www code is written in Hack, which started off as a PHP-compatible language / stdlib, and then dropped PHP compatibility when it was holding them back.
Having worked with both, any one of the major additions (XHP, good type annotations, sane collection types, etc) makes my development experience 10x better; going back to vanilla PHP now just makes me sad...
Having worked with both, any one of the major additions (XHP, good type annotations, sane collection types, etc) makes my development experience 10x better; going back to vanilla PHP now just makes me sad...
Collection types is a big one for me, I miss those like crazy when working in PHP.
PHP isn't going anywhere. PHP is fine. Perl, Ruby, Python, all fine. That being said, for general programming TypeScript/JavaScript is the way forward. Other than PHP, I have loved all these interpreters. It's over. Accept the middle and move on. Everything else is nitch.
Benchmarking should be made with a more real world point of view: https://www.techempower.com/benchmarks/#section=data-r17&hw=... tries to do it ...
For me https://github.com/the-benchmarker/web-frameworks is just testing the routing system (e.g. in the rails case def user render plain: params['id'] end ) ;)
For me https://github.com/the-benchmarker/web-frameworks is just testing the routing system (e.g. in the rails case def user render plain: params['id'] end ) ;)
The question for me is what can PHP do better than any other language out there?
I've worked with Laravel for a few years and while it has sooo many great features out of the box, it doesn't quite detract from how unpleasant working with PHP is, when comparing with any other common/modern language. Of course this is only my opinion and experience with it.
I don't think I would ever recommend PHP to anyone unless they live in an area where you can only find PHP job opportunities. Otherwise, any other language can do what PHP can do and will provide a better programming experience IMO.
I've worked with Laravel for a few years and while it has sooo many great features out of the box, it doesn't quite detract from how unpleasant working with PHP is, when comparing with any other common/modern language. Of course this is only my opinion and experience with it.
I don't think I would ever recommend PHP to anyone unless they live in an area where you can only find PHP job opportunities. Otherwise, any other language can do what PHP can do and will provide a better programming experience IMO.
[deleted]
[deleted]
Do we have still to use mb_* functions to deal with utf-8 ? That was a major PITA when I used to write PHP.
No
How ?
~ php --version
PHP 7.2.17-0ubuntu0.19.04.1 (cli) (built: Apr 18 2019 18:01:25) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies
with Zend OPcache v7.2.17-0ubuntu0.19.04.1, Copyright (c) 1999-2018, by Zend Technologies
~ cat test.php
<?php
echo strlen("ùé");
echo "\n";
echo mb_strlen("ùé");
echo "\n";
~ php test.php
4
2The answer is: Composer + Packagist. There's almost certainly a library that handles it in a sane and transparent manner for you so you don't have to deal with the pain.
I develop on PHP from 2 decades. I loved PHP. I took 2 Zend cerfications as PHP engineer. After working in Javascript projects for some time on client and node.js, and after learning basics of functional programming I think PHP is really horrible as language. The only thing that I think make it still unique, is the REST nature of the web server integration. Every request is world apart. The script starts and end with the HTTP request(exceptions here). This make it really easy to understand and scale.
[deleted]
I always wondered, in a world where
1. people seem to hate writing (old?) PHP, and
2. there are a good dozen languages that were created solely because people hate this other language Javascript, which both compile to Javascript and have the semantics of Javascript, just not the syntax or stdlib of Javascript;
...why we didn’t end up with languages compiling to PHP, targeting the Zend VM, or whatever you’d have to do to get the PHP module in Apache to interpret non-PHP code.
1. people seem to hate writing (old?) PHP, and
2. there are a good dozen languages that were created solely because people hate this other language Javascript, which both compile to Javascript and have the semantics of Javascript, just not the syntax or stdlib of Javascript;
...why we didn’t end up with languages compiling to PHP, targeting the Zend VM, or whatever you’d have to do to get the PHP module in Apache to interpret non-PHP code.
Because Javascript is the only thing that runs on the client side.
And for many “LAMP” hosting environments—such as the tiny ones many ISPs and/or universities hand out like conference swag—(secured, sandboxed) PHP is the only thing that runs on the server side. Same with many “WordPress hosts”—they don’t let you run code per se, but they let you install arbitrary WordPress plugins, so you could deploy your own code into the site... if you’re willing to write PHP.
(Secured) PHP is used by these environments in about the same way that Server Side Includes and .htaccess files were used by Apache in the late 90s: as a way to give users the ability to add some dynamism to a website, without actually giving them a Turing-complete environment that they could use to run bots on.
And yes, I’m not being facetious, it’s really not Turing-complete: most of these environments have fixed request timeouts, fixed memory quotas, and no ability for the runtime to write to disk or make network requests. So there’s no infinite tape! This is “PHP as pushdown automata.” ;)
As such, the language I’m talking about would actually have to be built to understand that it it’s operating in this super-limited environment (more limited than PHP normally is.) I would expect that this would be presented less as a “programming language” per se, and more as something you can use in a Static Site Generator to inject a bit of server-side dynamism to your generated “static” site.
(Secured) PHP is used by these environments in about the same way that Server Side Includes and .htaccess files were used by Apache in the late 90s: as a way to give users the ability to add some dynamism to a website, without actually giving them a Turing-complete environment that they could use to run bots on.
And yes, I’m not being facetious, it’s really not Turing-complete: most of these environments have fixed request timeouts, fixed memory quotas, and no ability for the runtime to write to disk or make network requests. So there’s no infinite tape! This is “PHP as pushdown automata.” ;)
As such, the language I’m talking about would actually have to be built to understand that it it’s operating in this super-limited environment (more limited than PHP normally is.) I would expect that this would be presented less as a “programming language” per se, and more as something you can use in a Static Site Generator to inject a bit of server-side dynamism to your generated “static” site.
It might not be, but how does it fare against similar languages?
I have no idea why you'd choose it over Go/Node.js/Ruby or similar for your standard webdev stuff.
I have no idea why you'd choose it over Go/Node.js/Ruby or similar for your standard webdev stuff.
All apps I saw, written in Ruby, were awfully slow. I don't know Ruby, maybe it's just me, but would be interesting to know examples of not slow Ruby apps.
Well, github, just to name one:). Also shopify, digital ocean, stripe. I also worked on a large ruby app that was faster than another large Java app.
Keep is mind that all these platforms handle a great deal of requests at any given time, so we're not talking simple web apps.
In my experience bad software design, bad DB design and bad developers are the major cause for performance issues, you rarely get to that level of polish with your app that the difference between different languages really matters.
At micro-bench level PHP always beats ruby pr python, but most apps have performance issues without ever getting to that level.
My funnies experience was with a java team that where baffled why their app is slow. I told them it looks like they have a huge bottleneck on the DB, their answer: "Yeah but it's java, it should be fast"
In my experience bad software design, bad DB design and bad developers are the major cause for performance issues, you rarely get to that level of polish with your app that the difference between different languages really matters.
At micro-bench level PHP always beats ruby pr python, but most apps have performance issues without ever getting to that level.
My funnies experience was with a java team that where baffled why their app is slow. I told them it looks like they have a huge bottleneck on the DB, their answer: "Yeah but it's java, it should be fast"
github is terribly slow... or maybe it's just me?
It's usually fast for me with the occasional slow down.
From experience (did some code contributions to gitlab) when you work a lot with the filesystem, as is the case for platforms hosting git repos, you will have performance issues related to that, regardless of the programming language.
we host gitlab at my company for internal use, just switching from SSDs to HDDs made a big difference in terms of response time for big actions like opening a merge request, etc
I'm sure there are apps in the wild that get to that level of optimization where you need to decide on a different language. But what I've usually seen is you just slice that part out into a service and only rewrite that part.
I think stripe and others are basically doing this if they do hit the limits of ruby in very performance intensive workloads.
From experience (did some code contributions to gitlab) when you work a lot with the filesystem, as is the case for platforms hosting git repos, you will have performance issues related to that, regardless of the programming language.
we host gitlab at my company for internal use, just switching from SSDs to HDDs made a big difference in terms of response time for big actions like opening a merge request, etc
I'm sure there are apps in the wild that get to that level of optimization where you need to decide on a different language. But what I've usually seen is you just slice that part out into a service and only rewrite that part.
I think stripe and others are basically doing this if they do hit the limits of ruby in very performance intensive workloads.
Stripe is a good example, thanks.
I absolutely agree that in a good web app DB is a bottleneck and can be 10 times slower than any part of the web app itself, regardless of the language.
Maybe Ruby ORMs are not so optimized, who knows.
I absolutely agree that in a good web app DB is a bottleneck and can be 10 times slower than any part of the web app itself, regardless of the language.
Maybe Ruby ORMs are not so optimized, who knows.
It's rarely application code itself that leads to something being slow(though bad code can, of course, be slow).
It's usually database calls, external API's etc..
For example, JIRA is as slow as a dehydrated donkey because its database schemas are exceptionally awful.
It's usually database calls, external API's etc..
For example, JIRA is as slow as a dehydrated donkey because its database schemas are exceptionally awful.
If the author happens to read this thread: Please please please use a different font. Serif fonts with very dynamic stroke strengths look awesome in print, but they break down on screens where the narrow strokes round down to 0px and vanish. Although I'm reading this on a HiDPI notebook display (1440p over 13"), I have to crank up the text zoom to at least 150% to be able to read the article comfortably.
> Back in the 5.* days, PHP's performance was… average at best.
Even with 5.* it very much depended how you used it. The real world scenario's. PHP functions are written in C. You could make great gains by leveraging on them. Using PHP as just the "glue" for a blazingly fast library (and templating engine) written in C.
Even with 5.* it very much depended how you used it. The real world scenario's. PHP functions are written in C. You could make great gains by leveraging on them. Using PHP as just the "glue" for a blazingly fast library (and templating engine) written in C.
Working with Laravel for more than a year now and it enables writing quality code. Testing is nice, as is building models, routing, validation, and authorization.
PHP itself is not that important. The language is solid and does its stuff. I'm moving mainly in the framework to create functionality.
PHP itself is not that important. The language is solid and does its stuff. I'm moving mainly in the framework to create functionality.
I just took a random sample from Spatie's PHP libraries - https://github.com/spatie/crawler/blob/master/src/Crawler.ph.... Most of the code consists of:
public function getSomething(int $someParameter): SomeType {
return $this->someParameter;
}
It's been close to a decade since I did anything in PHP (PHP5), but since I know PHP5 had public (and private,and protected) accessors back then, but didn't have any real typing of parameters if I remember, I assume this is a design pattern to enforce typing on the object parameters. Also, a good amount of them have some other guard that throws an exception on specific problems. I think it's a valid design choice to decide that since some object variables may need special handling that is accomplished through accessor methods, just create them specifically for each item that needs public access, and while you're at it throw in a few sanity checks. That provides a consistent interface, where accessors are both named and act in the same manner (i.e. you don't have mixed method call and direct assignment).
I would say, that PHP faired through time much better than Perl.
May be is Facebook's investment in the platform, may be it is wordpress , the PHP's 'killer app'.
I invested into building a system in PHP in 2010 (and using ignite as framework), when opportunity came to redo it, recently , I picked Java (besides type safety, I also had to build a client as an Android app, so sharing classes across both was another reason for Java).
I would also say that 'health' of a particular language+ecosystem should be measured by 6 variables.
1) new project uptake (OSS) -- eg how many new projects are created using particular language.
2) existing project updates frequency (OSS)
3) leavers (how many projects leave this ecosystem)
and same for non-OSS projects (where this can be measured)
May be is Facebook's investment in the platform, may be it is wordpress , the PHP's 'killer app'.
I invested into building a system in PHP in 2010 (and using ignite as framework), when opportunity came to redo it, recently , I picked Java (besides type safety, I also had to build a client as an Android app, so sharing classes across both was another reason for Java).
I would also say that 'health' of a particular language+ecosystem should be measured by 6 variables.
1) new project uptake (OSS) -- eg how many new projects are created using particular language.
2) existing project updates frequency (OSS)
3) leavers (how many projects leave this ecosystem)
and same for non-OSS projects (where this can be measured)
Most of the people defending PHP are talking about PHP7+, and most of the people hating PHP are talking about PHP5-.
Both groups didn't experience what the other group did and they are not talking about the same thing. So it is kind of pointless discussion.
The language itself has improved a lot. It is easy to find decent PHP7+ code now. It is also easy to find bad code.
And that is the same for all major programming languages in terms of usage. As Java got more popular, it was easier to find crappy code everywhere from people that only learned inheritance from OOP. More projects mean more technical debt for the future. So you always find more critics against most popular ones.
Both groups didn't experience what the other group did and they are not talking about the same thing. So it is kind of pointless discussion.
The language itself has improved a lot. It is easy to find decent PHP7+ code now. It is also easy to find bad code.
And that is the same for all major programming languages in terms of usage. As Java got more popular, it was easier to find crappy code everywhere from people that only learned inheritance from OOP. More projects mean more technical debt for the future. So you always find more critics against most popular ones.
From https://thinkmobiles.com/blog/php-vs-nodejs/:
> Node.js is faster than PHP only in adding numbers.
> Node.js is faster than PHP only in adding numbers.
I’m going to chime in here and say that I stayed with PHP through the roughest years.
I’ve only seen positive changes in the time since then.
I’ve made a good living from writing code and I don’t see any reason that has to change.
I’ve only seen positive changes in the time since then.
I’ve made a good living from writing code and I don’t see any reason that has to change.
[deleted]
I'm impressed with the evolution of the language and the tooling around it, driven by the necessity to scale and maintain apps for big businesses.
Nevertheless, I would think that PHP is a hard sell for new projects and new enterprises. Unless you're a dyed-in-the-wool PHP junkie and you're bringing a team that is the same, there are a multitude of reasons why you'd want to choose a different language for web dev work.
Nevertheless, I would think that PHP is a hard sell for new projects and new enterprises. Unless you're a dyed-in-the-wool PHP junkie and you're bringing a team that is the same, there are a multitude of reasons why you'd want to choose a different language for web dev work.
I'm more and more surprised that Laravel is so often mentioned over Symfony in this types of debate.
I've worked with both and done professional projects in both. While both are great, I would have to sing some praise for Symfony's developer experience and tooling. But realistically the're neck and neck.
PS: It's really funny seeing people seriously discuss PHP when they themselves have not tried it since the 5.* days.
I've worked with both and done professional projects in both. While both are great, I would have to sing some praise for Symfony's developer experience and tooling. But realistically the're neck and neck.
PS: It's really funny seeing people seriously discuss PHP when they themselves have not tried it since the 5.* days.
Yeam im really digging php these days. Composer and Laravel have made it fuggin awesome! I think more so the frameworks built when php was first picking up steam are a little convoluted and oldschool (im looking at you drupal!... 6 & 7, mostly). The language has come along way since then though, so thanks to the team for all their hard work.
In all honesty, Laravel has been a blast to create projects with. Prior to that framework, I had very little experience with PHP or any back-end development. It's simple to setup, has sane/safe defaults, and it scales well with the complexity of projects. Can't recommend it enough!
Personally I'm a fan of the Phalcon framework. It's also structured similarly to Laravel/Cake/Rails but is compiled into a PHP module and thus runs super fast by comparison. PHP has certainly improved with the 7.x line so I'm happy to continue using it.
I respect the leaps PHP has come as a language and runtime in recent years, however I still can't understand why anyone would elect to use it for greenfields projects.
The developer experience might be better than it's ever been, but even as pointed out in this article, it still has all the old issues like inconsistent core API, vague global context, and way too much implicit magic and guesswork. Not to mention it still relies on running a separate, third party HTTP server, in contrast to Node.js, Java, Python etc stacks where the HTTP server itself is a native construct of the language/runtime.
I can't see any single use case where there isn't a more appropriate alternative to using PHP. The only feasible reason I can see someone would use PHP for a greenfields project in this day and age is that they simply don't know any better.
"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."
The developer experience might be better than it's ever been, but even as pointed out in this article, it still has all the old issues like inconsistent core API, vague global context, and way too much implicit magic and guesswork. Not to mention it still relies on running a separate, third party HTTP server, in contrast to Node.js, Java, Python etc stacks where the HTTP server itself is a native construct of the language/runtime.
I can't see any single use case where there isn't a more appropriate alternative to using PHP. The only feasible reason I can see someone would use PHP for a greenfields project in this day and age is that they simply don't know any better.
"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."
> it still has all the old issues like inconsistent core API
Seriously, people keep bringing this up. Why? Are you a machine? Did you memorize the API to every single language you write in? I type `strst` and my IDE autohints `strstr()` and the argument order.
> vague global context
What's vague about it? What does global context even mean in this sentence? Do you mean like super variables? Static properties? Can you provide some detail?
> Not to mention it still relies on running a separate, third party HTTP server, in contrast to Node.js, Java, Python
You _can_ run your website using only the built-in webserver for those languages, but are you really going to do that? Or are you going to put Nginx or Apache in front to do what they're made to do: be webservers? Hell, there's Unicorn, Passenger, Puma, all aimed at doing exactly this.
And surprise, surprise, PHP also has a built-in webserver you _can_ use, but shouldn't.
There's even ReactPHP, Swoole, Amp, all with webserver capabilities.
Sounds more like a person who knows PHP in passing, or may have used it lightly, or long ago.
Seriously, people keep bringing this up. Why? Are you a machine? Did you memorize the API to every single language you write in? I type `strst` and my IDE autohints `strstr()` and the argument order.
> vague global context
What's vague about it? What does global context even mean in this sentence? Do you mean like super variables? Static properties? Can you provide some detail?
> Not to mention it still relies on running a separate, third party HTTP server, in contrast to Node.js, Java, Python
You _can_ run your website using only the built-in webserver for those languages, but are you really going to do that? Or are you going to put Nginx or Apache in front to do what they're made to do: be webservers? Hell, there's Unicorn, Passenger, Puma, all aimed at doing exactly this.
And surprise, surprise, PHP also has a built-in webserver you _can_ use, but shouldn't.
There's even ReactPHP, Swoole, Amp, all with webserver capabilities.
Sounds more like a person who knows PHP in passing, or may have used it lightly, or long ago.
> Did you memorize the API to every single language you write in?
No, that is my point. Languages with consistent core APIs are more easily discoverable, less error-prone and result in developers being less reliant on editor hinting. Writing PHP requires to you memoize random shit like the fact that json_encode() accepts options via bitmasks, inconsistent with the rest of the language for no apparent reason.
> What's vague about it?
- Imports/namespaces are not explicit (no intuitive way to know what methods are being provided by a given import without diving into it's file)
- All HTTP input (remember, PHP basically exists to script HTTP responses) is magically provided through vague superglobals that are set to wildly different values depending on what HTTP server you use and how it is configured
- Variables are all declared in global scope by default
> You _can_ run your website using only the built-in webserver for those languages, but are you really going to do that?
Yes. Unlike with PHP, running a single-process HTTP server does not result in thread locking for most other languages as their HTTP implementations are asynchronous by nature. There are currently some PHP community projects to implement async i/o, but there isn't even really any point trying to use them given PHP is meant to be having native libuv support eventually which will more or less make them redundant. And even then, why would you go to all this extra effort reinventing the wheel if not just to be stubborn and avoid having to learn a new language which is better suited to the task at hand?
> Or are you going to put Nginx or Apache in front
I hope you realise that other than for traditionally CGI-executed runtimes like PHP, Ruby and Perl, external HTTP servers like Nginx and Apache are almost exclusively used as a reverse proxy for things like load-balancing and SSL termination and have little to no involvement in processing and responding to the actual HTTP requests, which is typically left up to a HTTP server implemented in the application code.
Sounds more like you have little to no experience with web services outside the PHP world.
No, that is my point. Languages with consistent core APIs are more easily discoverable, less error-prone and result in developers being less reliant on editor hinting. Writing PHP requires to you memoize random shit like the fact that json_encode() accepts options via bitmasks, inconsistent with the rest of the language for no apparent reason.
> What's vague about it?
- Imports/namespaces are not explicit (no intuitive way to know what methods are being provided by a given import without diving into it's file)
- All HTTP input (remember, PHP basically exists to script HTTP responses) is magically provided through vague superglobals that are set to wildly different values depending on what HTTP server you use and how it is configured
- Variables are all declared in global scope by default
> You _can_ run your website using only the built-in webserver for those languages, but are you really going to do that?
Yes. Unlike with PHP, running a single-process HTTP server does not result in thread locking for most other languages as their HTTP implementations are asynchronous by nature. There are currently some PHP community projects to implement async i/o, but there isn't even really any point trying to use them given PHP is meant to be having native libuv support eventually which will more or less make them redundant. And even then, why would you go to all this extra effort reinventing the wheel if not just to be stubborn and avoid having to learn a new language which is better suited to the task at hand?
> Or are you going to put Nginx or Apache in front
I hope you realise that other than for traditionally CGI-executed runtimes like PHP, Ruby and Perl, external HTTP servers like Nginx and Apache are almost exclusively used as a reverse proxy for things like load-balancing and SSL termination and have little to no involvement in processing and responding to the actual HTTP requests, which is typically left up to a HTTP server implemented in the application code.
Sounds more like you have little to no experience with web services outside the PHP world.
> Writing PHP requires to you memoize random shit like the fact that json_encode() accepts options via bitmasks
Several other functions use bitmaps. It's a convenient way to string multiple options together without needing to pass key:value arrays. It's in the manual. My IDE typehints this for me. It's well documented. If you're surprised by this it's because you're using a text editor. Do folks write c# outside of Visual Studio? I can imagine some people might enjoy writing Java in notepad.exe but that's simply not for me. Why would I subject myself to this? Why make programming harder than it need be?
> - Imports/namespaces are not explicit (no intuitive way to know what methods are being provided by a given import without diving into it's file)
So you need to know ... what you're importing. This is difficult for you? If you don't want your IDE to typehint on the namespace, you need to open the stuff you imported. Honestly, you're reaching.
> - Variables are all declared in global scope by default
I don't understand why you would think this is unique? Any variable declared in the global scope is ... global scoped?
https://playcode.io/317387?tabs=console&script.js&output
If you look at RoR, running `rails server` spins up a webserver using Puma. Why wouldn't RoR use whatever built-in webserver Ruby ships with? I admit I am not as knowledgeable in Ruby or Python as I am in PHP, but what I do know is that a 5 minute Google search shows me that very few places on the internet recommend exposing Ruby or Python directly to the internet, and instead Unicorn, Passenger, etc are recommended.
Why is this even a point of contention for you? Why would you think doing this, or being able to do this, would be a positive?
Several other functions use bitmaps. It's a convenient way to string multiple options together without needing to pass key:value arrays. It's in the manual. My IDE typehints this for me. It's well documented. If you're surprised by this it's because you're using a text editor. Do folks write c# outside of Visual Studio? I can imagine some people might enjoy writing Java in notepad.exe but that's simply not for me. Why would I subject myself to this? Why make programming harder than it need be?
> - Imports/namespaces are not explicit (no intuitive way to know what methods are being provided by a given import without diving into it's file)
So you need to know ... what you're importing. This is difficult for you? If you don't want your IDE to typehint on the namespace, you need to open the stuff you imported. Honestly, you're reaching.
> - Variables are all declared in global scope by default
I don't understand why you would think this is unique? Any variable declared in the global scope is ... global scoped?
https://playcode.io/317387?tabs=console&script.js&output
If you look at RoR, running `rails server` spins up a webserver using Puma. Why wouldn't RoR use whatever built-in webserver Ruby ships with? I admit I am not as knowledgeable in Ruby or Python as I am in PHP, but what I do know is that a 5 minute Google search shows me that very few places on the internet recommend exposing Ruby or Python directly to the internet, and instead Unicorn, Passenger, etc are recommended.
Why is this even a point of contention for you? Why would you think doing this, or being able to do this, would be a positive?
The thing I like about php the most is how all the different frameworks have come together to create standard interfaces for building frameworks. I was able to easily create my own microframework using packages from zend, symfony and the php league.
I'm a front-end guy (with bit of Node.js experience) and I would like to learn PHP and Laravel properly - do you have any suggestions where to start (I would like to learn strong PHP fundamentals as well, not start from Laravel immediately)
The thing that burns me so much about PHP is all the crap in php.ini that should be configured by applications at runtime. The container vs programming language mindset is basically my biggest architectural/cultural peeve.
[deleted]
It's true.
I'd like to say it's a new crappy language, because that'd be funny, but it wouldn't be true either!
I'd like to say it's a new crappy language, because that'd be funny, but it wouldn't be true either!
definitively much better than other programming languages out there, especially when it comes to MVP.
Fast, easy and flexible.
CakePHP is a wonderful framework and the community support is simply huge (orders of magnitude bigger than Java and C# for instance).
Don't forget that PHP runs 70% of internet (where also Wordpress and Magento are big helps)
Fast, easy and flexible.
CakePHP is a wonderful framework and the community support is simply huge (orders of magnitude bigger than Java and C# for instance).
Don't forget that PHP runs 70% of internet (where also Wordpress and Magento are big helps)
Php here to stay, I personally hate it, but respect for such a long successful journey since 90th last century.
Disclousure: Amezmo creator
The PHP community and eco system is only getting better every year, and the language continues to advance. PHP is one of the easiest platforms to get started with. I built Amezmo to automate the modern PHP server infrastructure and deployment. Check it out at https://www.amezmo.com - Use coupon code FRIEND
The PHP community and eco system is only getting better every year, and the language continues to advance. PHP is one of the easiest platforms to get started with. I built Amezmo to automate the modern PHP server infrastructure and deployment. Check it out at https://www.amezmo.com - Use coupon code FRIEND
What's the concurrency story in PHP - does it use 1 thread per incoming HTTP request?
Does one still debug using var_dump()?
Disclaimer: I have not used PHP since 2010.
Does it have an actual debugger already? Or are we still stuck with xdebug?
What's wrong with xdebug?
Sure, xdebug requires a graphical frontend to be practical (I use phpstorm), but so does GDB.
Debugging with xdebug has been a really good experience for me. Much better than python or even GDB for C code.
Sure, xdebug requires a graphical frontend to be practical (I use phpstorm), but so does GDB.
Debugging with xdebug has been a really good experience for me. Much better than python or even GDB for C code.
I've spent basically two years working to convert a legacy project built on PHP 5.x into Laravel on PHP 7.x and I can agree that it's come a long way as a language, and that frameworks like this help.
The biggest issues, however, are not technical but are based on changes in the development philosophy overall. The legacy project was written by people who envied Java and its object system and wanted to make everything an object. Laravel (and similar projects) have moved towards something that is a mix of object-based approaches and Functional/Lispy approaches. This puts it more in line with the direction alot of languages (JS, Rust, etc) have been taking.
TL;DR: PHP is in a better place than it's been in awhile, largely because it's willing to borrow good ideas and execute them while still being able to make use of its legacy libraries when needed.
The biggest issues, however, are not technical but are based on changes in the development philosophy overall. The legacy project was written by people who envied Java and its object system and wanted to make everything an object. Laravel (and similar projects) have moved towards something that is a mix of object-based approaches and Functional/Lispy approaches. This puts it more in line with the direction alot of languages (JS, Rust, etc) have been taking.
TL;DR: PHP is in a better place than it's been in awhile, largely because it's willing to borrow good ideas and execute them while still being able to make use of its legacy libraries when needed.
I can't imagining switching back to PHP, even if it is much better than it was before. It has to _surpass_ other languages.
As someone who deeply misses Python (warts and all) and due to a job change forced to take on PHP (thankfully, we are on an aggressive language versioning schedule, so we're already on latest 7.3) as the full time language of of choice, I miss a few things that just make me want to pull my hair out:
For what its worth: I used (and personally still use) Python 3.6+ so the comparison is with that.
1. Async programming. While in Python its not perfect, having it baked into the core of the language makes so many things trivial like processing jobs between requests and sending the results back later, or having a simple queue for persisting data to a database after validation has been done on the data (Marshmallow is my hero for this).
2. Not having to worry about all the strange things you have to worry about when everything has to be re-built per request. While I understand WSGI requests are definitely this (kind of, usually you have a daemonized runner that keeps your app alive even then), your entire app did not spin down between requests like it does with php. Simply having to rebuild everything every single time a request comes in (even when using php-fpm, more or less) drives me insane, because I can't just send some data off to another channel in memory easily, or sleep a generator in a position and resume it when I need to. Everything has to be handled in said request. This kind of goes along the same lines as number 1, but its sort of a different problem (in particular, I think generators in Python are very elegant in comparison to lots of other languages, not just PHP (looking at you javascript), but PHP generators feel worthless unless I'm reading something line by line from a file or some other external resource, or I'm iterating against say, a doctrine array result)
3. Your app is full stop dead without a cache if you are planning on doing anything interesting. I don't just mean like opcache, but even small applications have to leverage this (APCU at a minimum), because of the aforementioned problem of nothing being alive after a request has been spun down. Yes, I have leveraged caching before, and yes I leveraged it all the time with python, but for just getting a quick prototype feature out the door, and adding those kind of layers later, I really miss that. Try iterating through database results non-sequentially, where you have tons of variable conditions on how that data needs to be shown, its a pain in the ass without caching aggressively (this is unfortunately a very real scenario I have to deal with all the time. We have non linear questionnaires in my current job I have to deal with, and the questions have to pass a certain validation and then we either have to get the next immediate result, or skip `x` ahead, without really knowing whats what or having any real idea of what anything may be keyed to. I'm open to suggestions if anyone has a good link or something to read on this kind of problem. I have not found it easy to work through personally with php)
With all that, Its been an OK experience though. Not my favorite language (may never be). However, if I was to postulate further, if PHP doesn't start gaining traction on these issues (and no, the weird async extensions are not a replacement for any of this. It needs to be core to PHP and maintained as such, for it to work in the language, in my not so humble opinion), it will eventually be supplanted in full even where it may have some strengths.
Unfortunately, nobody working on the core of the language seems to care about this at all.
For what its worth: I used (and personally still use) Python 3.6+ so the comparison is with that.
1. Async programming. While in Python its not perfect, having it baked into the core of the language makes so many things trivial like processing jobs between requests and sending the results back later, or having a simple queue for persisting data to a database after validation has been done on the data (Marshmallow is my hero for this).
2. Not having to worry about all the strange things you have to worry about when everything has to be re-built per request. While I understand WSGI requests are definitely this (kind of, usually you have a daemonized runner that keeps your app alive even then), your entire app did not spin down between requests like it does with php. Simply having to rebuild everything every single time a request comes in (even when using php-fpm, more or less) drives me insane, because I can't just send some data off to another channel in memory easily, or sleep a generator in a position and resume it when I need to. Everything has to be handled in said request. This kind of goes along the same lines as number 1, but its sort of a different problem (in particular, I think generators in Python are very elegant in comparison to lots of other languages, not just PHP (looking at you javascript), but PHP generators feel worthless unless I'm reading something line by line from a file or some other external resource, or I'm iterating against say, a doctrine array result)
3. Your app is full stop dead without a cache if you are planning on doing anything interesting. I don't just mean like opcache, but even small applications have to leverage this (APCU at a minimum), because of the aforementioned problem of nothing being alive after a request has been spun down. Yes, I have leveraged caching before, and yes I leveraged it all the time with python, but for just getting a quick prototype feature out the door, and adding those kind of layers later, I really miss that. Try iterating through database results non-sequentially, where you have tons of variable conditions on how that data needs to be shown, its a pain in the ass without caching aggressively (this is unfortunately a very real scenario I have to deal with all the time. We have non linear questionnaires in my current job I have to deal with, and the questions have to pass a certain validation and then we either have to get the next immediate result, or skip `x` ahead, without really knowing whats what or having any real idea of what anything may be keyed to. I'm open to suggestions if anyone has a good link or something to read on this kind of problem. I have not found it easy to work through personally with php)
With all that, Its been an OK experience though. Not my favorite language (may never be). However, if I was to postulate further, if PHP doesn't start gaining traction on these issues (and no, the weird async extensions are not a replacement for any of this. It needs to be core to PHP and maintained as such, for it to work in the language, in my not so humble opinion), it will eventually be supplanted in full even where it may have some strengths.
Unfortunately, nobody working on the core of the language seems to care about this at all.
I wonder, wouldn't it be possible to generalize the work that was done for JS with V8 to a variety of languages, to target something like LLVM? Can't most interpreted language be targeted to a common ground?
Anyhow, I've generally avoided a lot of languages. For now my choices have boiled down to C++ and python, and I've even used brython instead of client side JS. I either don't touch other languages, or just thread very carefully.
My cynicism is usually yelling out to nuke all existing things, including HTML and JS, to favor something new, clean, less bloated, so that it can possibly run well on smartphones. I just wish public research and engineering entities like DARPA could come up with something better. I think C and by extent C++ are already that, but crowds of nerds will keep moaning about out of bound arrays.
HTML freed the web from the grasp of greedy capitalists, but now it has done its job and a lot of things should be put away. Aren't there tools to optimize HTML rendering for speed?
Anyhow, I've generally avoided a lot of languages. For now my choices have boiled down to C++ and python, and I've even used brython instead of client side JS. I either don't touch other languages, or just thread very carefully.
My cynicism is usually yelling out to nuke all existing things, including HTML and JS, to favor something new, clean, less bloated, so that it can possibly run well on smartphones. I just wish public research and engineering entities like DARPA could come up with something better. I think C and by extent C++ are already that, but crowds of nerds will keep moaning about out of bound arrays.
HTML freed the web from the grasp of greedy capitalists, but now it has done its job and a lot of things should be put away. Aren't there tools to optimize HTML rendering for speed?
a vicious circle
Falling for the php meme lmao
hadriendavid(1)
My major side project does most of the heavy lifting in an API written in Go, but the front end is a Laravel app.
It works nicely, is easy to make changes to, and gets out of my way.
/shrug
It works nicely, is easy to make changes to, and gets out of my way.
/shrug
I would argue that Kotlin is the better modern PHP. Beside of a lot of magic Laravel makes PHP okayish, but it is still the worse mainstream programming language.
> but it is still the worse mainstream programming language.
Please back this up.
Please back this up.
This is my opinion.
Some hints why I think PHP is not great:
* property type declaration in doc-strings * bad documentation * verry verbose for a dynamic language * a lot of inconsistencies * automatically loading of classes is a hack (psr4) which doesn't support importing functions without specifying it in a global project file
Some hints why I think PHP is not great:
* property type declaration in doc-strings * bad documentation * verry verbose for a dynamic language * a lot of inconsistencies * automatically loading of classes is a hack (psr4) which doesn't support importing functions without specifying it in a global project file
As a note, typed properties are coming with 7.4.
And I welcome it. Also the shorter anonymous function syntax will improve the current situation by a good deal.
https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/
Well, this is still true.
Well, this is still true.
I mean, apart from the huge number of items that have been fixed over the years, yeah.
> PHP isn't the same old crappy language it was ten years ago
But it is too late. JS on the backend has nearly completely ate its mindshare in its target demographic.
I think, JS itself risks ending up like this if core developers in Node and TC39 will not begin to think of the need for JS 2.0 and fixing fundamental design issues, and bug-o-features.
But it is too late. JS on the backend has nearly completely ate its mindshare in its target demographic.
I think, JS itself risks ending up like this if core developers in Node and TC39 will not begin to think of the need for JS 2.0 and fixing fundamental design issues, and bug-o-features.
I usually code a backend in Go or Python, but recently been thinking if I should just abandon my "prejudice" (JS sucks, Node sucks, Node is single threaded, there are no SQL libraries, etc) and move to JS on the backend as well, since that's what I already use on the frontend - be it web or React Native.
(I actually find JS very expressive and oriented towards a style of "table-oriented programming" which is useful for software that changes a lot like UI, IMO).
(I actually find JS very expressive and oriented towards a style of "table-oriented programming" which is useful for software that changes a lot like UI, IMO).
> (JS sucks, Node sucks, Node is single threaded, there are no SQL libraries, etc) and move to JS on the backend as well, since that's what I already use on the frontend - be it web or React Native.
My prejudice is the same. A lot of JS and its ecosystem feels to me to be broken by designs, but you have an option to use a boutique option of Scala/Dart/Go that nobody uses (relatively speaking,) or JS which is broken as a language, but is OK as a work tool.
JS will fall just like PHP, when it will be bested by the next better tool for "quick and dirty" programming, because Node and TC39 delayed the "2.0" change for too long.
What I feel already is increasing awareness of real world JS performance limitations, and people beginning to speak about JS sponoffs with native types, and further direction of work on things that sprung up from ASMjs
My prejudice is the same. A lot of JS and its ecosystem feels to me to be broken by designs, but you have an option to use a boutique option of Scala/Dart/Go that nobody uses (relatively speaking,) or JS which is broken as a language, but is OK as a work tool.
JS will fall just like PHP, when it will be bested by the next better tool for "quick and dirty" programming, because Node and TC39 delayed the "2.0" change for too long.
What I feel already is increasing awareness of real world JS performance limitations, and people beginning to speak about JS sponoffs with native types, and further direction of work on things that sprung up from ASMjs
Putting Go in the same box as Dart seems a tad insulting - it's not that much of a niche language anymore.
"While async and await are not available yet, lots of improvements to the language itself have been made over the past years"
It's 2019 guys. Please.
It's 2019 guys. Please.
If you are looking for speed tacking an event loop on an interpreted scripting language is trying to dig a hole with a rake.
Its why the demand for such functionality was almost wholly absent from Python, PHP, etc for so long. Asyncio is a throughput boon even in a single core environment, which dates its practicality back to the 90s - and it was found there, in pretty much every graphics stack and COM. C apis have used what is fundamentally a promise since the 80s,
But if you are in a situation where you want those kinds of performance characteristics where you have work to do during blocking operations you probably don't want to be writing that code in an interpreted language to begin with.
Last week I was optimizing some performance critical Python but when considering my options I just ported the whole thing to Boost / C++ and got an ~80x speedup over the whole loop.
Theres only a narrow range of problems actually best solved with interpreted asyncio, pretty much only in the space where introducing a build system and doing language binding isn't worth it but the gains from being non-blocking are. They exist, and its definitely not a bad thing to have async support in your interpreted language, but it definitely isn't mission critical in the slightest.
Its why the demand for such functionality was almost wholly absent from Python, PHP, etc for so long. Asyncio is a throughput boon even in a single core environment, which dates its practicality back to the 90s - and it was found there, in pretty much every graphics stack and COM. C apis have used what is fundamentally a promise since the 80s,
But if you are in a situation where you want those kinds of performance characteristics where you have work to do during blocking operations you probably don't want to be writing that code in an interpreted language to begin with.
Last week I was optimizing some performance critical Python but when considering my options I just ported the whole thing to Boost / C++ and got an ~80x speedup over the whole loop.
Theres only a narrow range of problems actually best solved with interpreted asyncio, pretty much only in the space where introducing a build system and doing language binding isn't worth it but the gains from being non-blocking are. They exist, and its definitely not a bad thing to have async support in your interpreted language, but it definitely isn't mission critical in the slightest.
It's good if they take some time to think about the implementation instead of doing a crappy job like Python did.
Cani you please elaborate a bit how python Async await is crappy ? Not defending anything but I'm curious. Is it in the language or its implementation ? I've found the loop choices and relationship with dbus loop or other internal libraries cumbersome on Linux but that is implementation.
Wait what? Python's async is actually well implemented and very consistent.
Thanks, modern JavaScript is much more better & profitable than not_a_crappy_language_anymore today.
If you're 60, you can still use PHP for legacy projects, but no sense to learn it now and kill your career. Market matters.
If you're 60, you can still use PHP for legacy projects, but no sense to learn it now and kill your career. Market matters.
As a seasoned PHP dev, I can actually see where nodejs sucks. Things that are native functions or part of default extensions in PHP, I have to hunt for on npm or be responsible for re-implmeneting from scratch. And PHP has a lot integrated.
It sucks if you know you can whip out a single call in PHP, but have to search for an hour in npm and not really find anything satisfying - all the while knowing that in PHP you'd already have been doing something more useful.
It sucks if you know you can whip out a single call in PHP, but have to search for an hour in npm and not really find anything satisfying - all the while knowing that in PHP you'd already have been doing something more useful.
A great example of this in action is Laravel Spark[3], a first party base for building paid SaaS apps. I built and launched a writing tool, Write Together[2], to the world in under three weeks, payment systems and all, and got 150 paying customers in a matter of a few weeks. One hell of a great way to MVP an idea and build something useful, in a low amount of time.
I'm basically developing two Laravel apps full-time at the moment, and it's the most fun I've had in years...compared to the hellscape of NPM dependencies and other complexities I'm usually bogged down with. Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy.
[1] https://forge.laravel.com
[2] http://writetogether.space
[3] https://spark.laravel.com