PHP in 2019
stitcher.io
stitcher.io
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.
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.
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 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.
The community since then has grown by leaps and bounds. Good to see the Pyro team still out there making a great CMS.
honestly its ok to have a different opinion, different people prefer different things.
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.
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?
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! :)))
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'm currently building another with that library.
[0] https://falconframework.org/
[1] https://klen.github.io/py-frameworks-bench/ or https://github.com/the-benchmarker/web-frameworks
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 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.
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.
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.
https://packagist.org/packages/hirak/prestissimo
Give this package a try, it really worked for me to speed up package management with composer.
I would recommend.
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).
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?
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.
That's not a sentence I expected to see. Ever. Drupal is popular for many things but for simplistic sites?
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 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 shipped apps in 2 weeks myself that the company got paid ~70k for. And we kept my clients.
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.
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.
There's also Drupal, which is very common in higher ed.
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.
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.
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.
> 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.
> 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.
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
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.
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.
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.
Unfortunately it also provided a lot of careers to developers who never got to the "make it" stage.
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...
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...
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 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.
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.
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.
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
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.
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.
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.
Oracle.
I really do need to get over all of that and give it another shot.
But after you get productive with PHP there is no feature that I think I am missing from other similar languages.
- 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'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
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.
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.
imagine the exponential complexity as old behaviours need to be kept around for various levels of opting in.
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 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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
So, it's apparently a good reason to hate, but by no means a reason not to use PHP.
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.
str_replace(old, new) vs. stri_replace(new, old) kind of thing.
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.
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)
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?"
Reference: https://laravel.com/docs/5.8/collections
https://stackoverflow.com/questions/18144782/performance-of-...
Infuriating? really?
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 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 ;)
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.
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.
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).
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. 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.
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.
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).
That's worth a lot to most people, I think?
> 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.
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?
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.
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.
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.
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.
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.
All that's happened is that the language is even more complex, has even more baggage.
My rebuttal from 2012: https://news.ycombinator.com/item?id=3821029
The PHP community has made a ton of improvements over the last few years, surely you can't criticise a project for improving?
PHP has a lot to like about it - otherwise it wouldn't be as popular as it is.
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.
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 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.
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.
In all other cases I keep thinking: "Have you seen Django yet?" And probably you can substitute ROR, Node, ASP.NET Core 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.
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.
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!
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.]
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 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"
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.
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.
By far database time remains our biggest bottleneck, especially since we finally made it onto PHP7
Seems like a pretty extreme reaction - how about trying a job with something other than PHP?
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
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.
* Genuinely interested in the rationale behind this. Sure, it's a lot, but why does that matter?
"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 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.
`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.
Doctrine, symfony, AWS, all backend API work.
For my day job, I do Python and Java... For side projects that are database-driven web apps, PHP is perfect.
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.
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.
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.
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...
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 ) ;)
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.
~ 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
21. 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.
(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.
I have no idea why you'd choose it over Go/Node.js/Ruby or similar for your standard webdev stuff.
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"
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.
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.
PHP itself is not that important. The language is solid and does its stuff. I'm moving mainly in the framework to create functionality.
public function getSomething(int $someParameter): SomeType {
return $this->someParameter;
}
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)
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.
> Node.js is faster than PHP only in adding numbers.
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.
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'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.
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."
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.
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.
I'd like to say it's a new crappy language, because that'd be funny, but it wouldn't be true either!
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)
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
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.
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.
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.
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?
It works nicely, is easy to make changes to, and gets out of my way.
/shrug
Please back this up.
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
Well, this is still true.
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 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).
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
It's 2019 guys. Please.
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.
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.
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.