PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
> - No long compile times because there is no compiling needed. I respect that some people accept dynamic typing as a better tradeoff for various reasons (I've worked with Ruby for many years before I discovered my love for type systems), but to me that statement reads similar to: "No long CI builds because we skip all the tests." :)
I still love PHP and JavaScript
341–350 of 402 posts
Re: I still love PHP and JavaScript
#342Earlier quoted context omitted.
Everything you say is well and good, but the businesses with the legacy codebase (PHP or Javascript) are still trying to pay someone to work on their systems, and quite frankly, their money is the same shade of green.
Their culture is different though. Prepare to fight for every minor technical improvement.
That's actually not my experience. I pretty much always had complete technical freedom when brought in as a freelance on e-commerce PHP applications. As long as it enables the business, they let the nerd do the gobbledigook.
Re: I still love PHP and JavaScript
#343Earlier quoted context omitted.
Have you tried a more "modern" language recently? By trying I mean using it for more than 6-10 months. I've been one of the PHP "supporters" until I've found Go and Rust. PHP was really nice to get into programming and make a spaghetti website but the language itself and the ecosystem always felt like a hacking project. The killer feature of PHP has always been the hosting ecosystem. A simple FTP upload would do the…
> PHP was really nice to get into programming and make a spaghetti website Facebook manages quite well with PHP. Maybe it's your fault you didn't learn how to use modern PHP practices which have been well-documented for over a decade now.
>>well-documented
Sources?
Re: I still love PHP and JavaScript
#344I have used PHP extensively and moved to node then finally settled on using golang. I think PHP does have a place as a current programming language but much more small scale operations.
It is just more complicated, to run a PHP site you need to have knowledge of PHP, PHP config, server config, the tooling is poor, there is always something else you need to bolt on to get a similar experience to a modern development language, there are so many ways you can write bad code or write code in a different style to others around you sharing this in a team is hard.
At my company we still run PHP apps and everything we want to do as an organisation is relatively simple in Go, but hard with PHP. I imagine the issues and problems we have with it are why it is not well used in large organisations
Re: I still love PHP and JavaScript
#345PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
> PHP has so many hidden benefits: > - it's stateless by design (much easier to scale) I'll grant you this one. Though PHP in practice goes to great lengths to add state back in for performance reasons (e.g. memcached, or for a while APC). And Haskell is stateless, too, yet not a frequent choice for web work. > - it was "serverless" before Serverless This is retconning. It was never trivial to set up a LAMP stack, es…
> I can't speak about the latest stuff, but PHP5 in ~2014-15 was...
I don't understand the purpose of your post.
Do you judge all languages according to your experience from 8 years ago?
Do you go on python boards telling everyone how much you hate working with python 2.7?
Maybe spend your afternoon on rust threads to complain about it not being available to the public yet?
Do you need to like a language for 8 entire years before letting anyone know about it, or just some time within the past 8 years?
Re: I still love PHP and JavaScript
#346Earlier quoted context omitted.
On the other hand, if your production is already broken, it's much easier and quicker to apply a hotfix in PHP (just edit a file on the server directly) without waiting for the whole CI/CD to finish.
This leads in turn to testing/developing in prod. I do not personally miss it. If you have CI/CD you should not be able to skip it. Maybe putting it under a feature flag would be a safer alternative.
I was talking about a situation when prod is already down and something is better than nothing. For example, once we forgot to add timeouts to calls to a third-party service, everything worked great for a year, then suddenly the third-party server started hanging for no reason which made all our PHP processes hang, too, and those processes were holding DB connections so we went out of DB connections as well and the whole production went down. We quickly found the root cause and applied a hot fix (setting the timeout) by editing a PHP script on the prod server without waiting for the usual cycle "pull request -> code review -> deploy to stage -> testing -> release" which can take an hour.
Re: I still love PHP and JavaScript
#347Earlier quoted context omitted.
thanks for reading! I use legacy code as in "code that was written yesterday or earlier", or in a less jokey fashion as "code that noone really feels ownership for", usually a codebase that shows the sign of many developers, repeated cycles of outside pressure. What I mean by "product performing well" is that the legacy codebase is still alive for a reason: it is doing its job and the job has value. Otherwise it can…
Yes, I got that. I didn't feel that the "alternative definition" was offered disingenuously, but it's still a problem when you want to have a discussion and you use certain commonly accepted terms, but with a different definition in mind. Imagine if I talked about "democracy" and in my mind I meant "The Athenian model that only allowed men over the age of 30 to vote", when everybody else was talking about, well, demo…
I definitely studied that book when it came out. I feel my definition is the same as his "Legacy code is simply code you got from someone else". I have seen MANY legacy codebases with tests. Surprisingly often these tests are not only useless, they were partly responsible in reifying horrible wart-patching on top of an outdated abstraction, as replacing the abstraction as requirements changed would have required a new test suite.
As I'm gaining more experience tackling project from a business perspective, when encountering a legacy codebase, it makes sense to start reviewing the business assumptions. Does this codebase even make sense in view of the current business strategy? If not, there's probably big chunks of code that can be entirely "written of", yet need to be kept alive long enough to migrate without disruption. Unit tests can help, but I often found deleting the unit test suite and starting a new one a more productive approach (again, with my experience of 6-7 projects).
But we agree. The book is a bit out of date, and it's focus on approaching the problem using 2004 agile techniques is not something I would fully recommend anymore, but I have yet to find a replacement (maybe there is one out there, I haven't looked recently)
Re: I still love PHP and JavaScript
#348Earlier quoted context omitted.
I really like the serverless aspect. I still think nothing has the deployment story that PHP applications have. Just upload some source and your website is up.
Interestingly, that has been the case for 25 years or so now but none except perl was able to do that?
Perl's not unique in that way. Any language can talk cgi. That's literally the purpose of cgi. Perl was just the popular scripting language of the day.
If you're using something other than cgi to get your httpd to talk to your webapp, your answer lies in understanding the architectural decisions of that tool.
Re: I still love PHP and JavaScript
#349Earlier quoted context omitted.
I've never experienced the same kind of out-of-the-box problems with PHP as I have Python. I seem to suffer constantly from python/python3, pip inconsistencies and stuff just breaking constantly.
Python build/package management tooling is a joke, but Python the language is very consistent and usable.
Ooh, now that's a good question.
Which is more important really? I genuinely don't know the answer to this.
Re: I still love PHP and JavaScript
#350PHP has so many hidden benefits: - it's stateless by design (much easier to scale) - it was "serverless" before Serverless - surprisingly performant - no "unknown unknowns". it's so tried-and-true, there's no surprises - deployment is so simple, just drop a file on a web server. No middleware needed. - No long compile times because there is no compiling needed. EDIT: why the downvotes? If you don't agree, just reply…
> PHP has so many hidden benefits: > - it's stateless by design (much easier to scale) I'll grant you this one. Though PHP in practice goes to great lengths to add state back in for performance reasons (e.g. memcached, or for a while APC). And Haskell is stateless, too, yet not a frequent choice for web work. > - it was "serverless" before Serverless This is retconning. It was never trivial to set up a LAMP stack, es…
Thanks for the comment!
As a counterpoint, I used PHP5 when writing https://www.goldeneaglecoin.com/ and it was always Programming is about adding abstractions on top of underlying computational substrates. Ultimately our CPUs don't care if we run haskell or PHP, they just run machine instructions. I never found it too complicated to use useful abstractions in PHP.
I usually prefer inheriting a subperforming cache-free PHP site, because devising a consistent cache strategy is usually not too hard (cache static content + opcodes on deploy, determine which invalidation keys you need for the subset of dynamic content that does the bulk of the load / has latency requirement, don't cache the rest). If I have a big collection of lose php files, that's reasonably easy to do. If i have a tangled web of middlewares and ORM'd business logic, it's much harder, and I usually have to unfold it to "lose leaves".