As far as I am aware, and I can tell, it wasn't because of the stacks / architecture, but lack of product market fit. The fact that the response to lack of PMF was to double down on product features and tech (instead of a business pivot), in my opinion, was what made the investor money go poof and the startup die down. I've seen this happen' in too many places (as an employee or consultant) to be a coincidence.
> And, there is a good reason people shy away from PHP, and it has nothing to do with trying to be "flashy." There should be a name for this kind of fallacy.
Different stacks for different use cases. If I can't get money with a shitty PHP product offering, it's probably best to figure out why instead of attributing it to my tech stack.
I agree, I also strongly dislike Angular and MySQL in addition to PHP. But I also think a much better indicator for success is discipline. Angular, PHP and MySQL, to their credit, aren’t crazy Turing tarpits, you can write good, successful software with them.
I’ve never seen a dysfunctional project where any of the inherent flaws of those technologies even registered on the same scale as the sheer malpractice of everyone working on the product. And this is also the problem with trendy and flashy stacks, developers not learning the stacks properly and using them as intended. Probably due to commercial pressure to push prototypes to production instead of rebuilding properly after learning the stack. I think that should be the takeaway from the original comment, that CTOs need to either budget for building it twice, or stick to a stack everyone knows inside and out.
The only people pointing to PHP as the right choice that kept them from ruin are those that used it successfully. Therefore, they were building something that fit well with PHP's benefits and didn't expose too many of it's weaknesses. But no one knows for sure exactly what about that project made it a good candidate for a PHP monolith, because we don't really have any science around software engineering, just hearsay and fashion.
Having rescued several 10+ person year PHP projects from ruin, none of them were on the edge because of the language itself. However, the people building those systems made an incredible mess in a short time. I think each language attracts a certain type of developer and comes with it's own community baggage. The PHP community has some highly questionable best practices. But this is true of all programming language specific communities. They tend to be insular and have a lot of "winning the last war" advice for working around the shortcomings of the language's previous major version that have been fixed in the current major version.
How did you rescue them? What are your views on Laravel?
The projects were using Zend framework 2. We didn't change really anything about the text stack at all.
The solutions were generally three pronged. This isn't to bash anyone, but every failing project I've seen is a skill, talent, or discipline issue, not a technical one. So recusing projects tends to be about training, mentorship, and guidance. Sure, you fix things along the way, but that's more to prove to the devs that you know what you're talking about, so they start to fix things themselves.
First, start a root cause analysis on bugs before fixing them. This often meant that instead of another if statement in the UI because of bad state, there was a larger fix needed to prevent the bad state entirely. These bigger changes were scary, but they quickly turned these projects from spending all their time in emergencies into only a few hours a week.
Second tool was to deduplicate and unit test code as much as possible. No more copy-pasting whole files every time there was a slightly different use-case required.
Third, to stop treating the database like a PHP ORM connection and start treating it like a distinct tool. Things like turning serialized PHP arrays from a single column into separate tables allowed us to start using SQL to query data instead of pulling all records into memory to filter and sort. This rapidly improved performance, which meant fewer support issues.
All boring, bog standard stuff. One project we started a second service in .NET to be the location of new features because half the team didn't want to use PHP anymore. The idea was they could slowly migrate endpoints to the .NET project. But that didn't survive. They got bored with a slow and safe conversion and convinced upper management to approve a total rewrite in .NET with a whole different team building out a microservice mess. The rewrite has been ongoing for 18 months now without a release. I heard they finished their first feature a few months ago, but still aren't live. Meanwhile the PHP project just keeps chugging along. Just goes to show, it's rarely the technology that causes issues, it's the team.
I don't really know anything about Laravel. I'm not really a PHP guy, I'm a project rescuer. Just happens to be most projects I get called into are PHP, C#, and Visual Basic. I've heard really good things about Laravel, but even ZF2 can be made safe, secure, performant, and reliable. It just takes discipline and the right team. That being said, I would consider PHP to be a language that is hard to hire for. There's just so many developers that flood the inbox who don't even know what a function is.
I will say, when I took a contract to build a greenfield web dashboard at the start of the year, I chose .NET 6 and C#. The platform and ecosystem is fine. I've shipped Java, Python, JavaScript, Ruby, Perl, OCaml, Haskell, Clojure, F#, and VB.NET. I picked C# for this project because the company already has a couple dozen C# developers who are pretty talented. I figured if I shipped them something they were comfortable with maybe they'd hire me again down the road.
Rewrites rarely succeeds, it is a typical fallacy for a team to believe that their problems lie in the language they are using and not in themselves. Seen it too many times.
Please share it. And don't rely on articles that are more than a decade and 3 or 4 versions of PHP old.
1. Other languages also do not have this distinction (Python for example AFAIK),
2. It's relatively useless. I get the value of it in JavaScript which has a lot of asynchronous code and frontend where the behavior may indeed be very different between null and undefined, but in a server-side application I don't think the nuance is necessary at runtime, and potential programming mistakes involving that can be caught by a linter.
[1] https://stackoverflow.com/questions/6905491/how-to-tell-whet...
This is a discussion for us tech folks. When it comes to business. Customers don't give a rat's ass about this as long as the product provides them with value.
If you're flooded with customers and the tech stack is a pain in the ass, perhaps it would be a good time to start considering this, but until you have this problem, the technical aspects are just wasting investor money and / or engineering time.
For most companies, issues like `undefined | null` bugs can be resolved with just a few code adjustments, resulting in only minor inconvenience for customers. As long as problems are addressed and the product provides value, customers will continue to support it.
There are CEOs and CTOs that feel differently. I wish them luck.
At the language level PHP has about the same problems as JS.
Thankfully it looks uglier so people get an early warning before using it for everything.
So?
Don't similar footguns appear in Python and JS? Why single out PHP for footguns when the other languages are no better?
While I'm not a PHP programmer, I have used most programming languages, and PHP doesn't seem any worse than the competitors.
- no one
-- Matlab
Starting indexes at 0 makes sense when you want to enable the developer to manipulate memory (for example, C)
Indexes starting at 1 matches with a more natural ordinal sequencing.
"I don't understand the word 'index'".
- a functional programmer
If it’s the second option, why has (almost) every other language chosen with a GC to start arrays with 0?
Some people write whole-ass applications in bash, the psychopaths
*giggles nervously, then changes the subject.
(I mostly write Python professionally, and use Python, Swift and Rust in personal projects in case anyone is wondering.)
Nowadays im on django/python because im in a python shop and I like python too.
You're getting paid to deliver business logic, which means most work is going to be gluing together libraries. This inherently means relying on community-written code, and related stuff like documentation and StackOverflow answers.
If the community is bad, the language isn't worth using.
If you're looking for pragmatic devs that don't care much about the trends, the community or peers' general opinion about a technology, going with PHP will get you this type in spades. Especially if you're looking for experienced engineers.
If you want devs that care about thoughtful designs, elegant solutions and want to enjoy the community, it will be a lot more difficult (not impossible, but it's an uphill battle)
And this has little to do with PHP's viability per se, there's just so much baggage that most devs will self select in one side or another. A language's base design philosophy matters, and it's always better to chose a stack that matches your own philosophy.
I don't think one stack is necessarily better than the other, it's all about how well do the developers know the tech stack in question.