Many people here don't understand the genius of Php. The language thrives of the ability to put out functionality that can be easily used by as many people as possible, even if it is not polished or technically perfect. This raises the ire of lots of programmers from "serious languages", which will usually take years to figure out the best syntax, the perfect framework and tooling environment, etc. While they're doing this, Php programmers are writing billions of lines of code to support millions of websites all over the world. Like many others, I sometimes hate the ugliness of what comes out from Php, but there is no question that it works to get the job done without having to learn the thousandth latest framework for language X.
25 Years of PHP
201–210 of 426 posts
Re: 25 Years of PHP
#202> PHP to have str_contains() A function that checks if a string is contained in another string? That should only take about 25 years.
For anyone else confused by the newest thing on the list who is wondering what the heck str_contains() does that you could not already easily do with strstr() or strpos() since time immemorial, the answer is nothing.
The only difference between str_contains($needle, $haystack) and strstr($needle, $haystack) and strpos($needle, $haystack) is that after they all make exactly the same C function call:
php_memnstr(ZSTR_VAL(haystack), ZSTR_VAL(needle), ZSTR_LEN(needle), ZSTR_VAL(haystack) + ZSTR_LEN(haystack))
• str_contains() return false or true, depending on whether that pointer is NULL or not,
• strstr() returns false or the part of haystack starting with needle, depending on whether that pointer is NULL or not, and
• strpos() returns false or the offset of needle within haystack, depending on whether that pointer is NULL or not.
It's equivalent to just writing (strpos(...) !== false) in your current code.
The rationale for adding str_compare() is that strstr() and strpos() are not intuitive, easy to get wrong, or hard for new developers to remember.
Re: 25 Years of PHP
#203Re: 25 Years of PHP
#204[deleted]
Re: 25 Years of PHP
#205Earlier quoted context omitted.
> One thing that still sucks is package management / composer What about Composer? Sure is in par with Slack when it comes to memory usage, bit it's functional and feature rich. v2 has partial offline support, faster downloads, etc. ( https://php.watch/articles/composer-2 ). Composer IMHO is one of the best dependency managers for any language out there. Disclaimer: the link above is a for a site I maintain.
composer is so slow tbh. It takes ages to download package and well requires me to setup swap even when i have 4 gb ram in server.
Have you used prestissimo? It allows parallel downloads and makes the process much much faster. https://github.com/hirak/prestissimo
Re: 25 Years of PHP
#206I'm not a php developer - syntax ain't for me. but props to these folks man. 25 years of getting shit done. shipping, amidst the jeers. I look at Laravel as one of the big 3 web frameworks to use if you're serious about shipping stuff. & in the PHP world, everything has been done - so you won't be doing anything new.
Re: 25 Years of PHP
#207It's so crazy to see how far the language has come, and how much it's matured! I started working in Perl around '98-99, switched to PHP in 2000 just after PHP 4 came out, and ended up running a company around it for all of my 20's. Very thankful for the language and community that made that possible.
These days I still write a fair bit of PHP, but mainly C# and Go, and some Javascript. I understand the criticisms of each language, but I don't mind the type inference/coercion in scripting languages and don't find it actually results in that many bugs. Although I do appreciate the clarity of choosing your types and understanding their performance implications in C# and Go. I guess it comes down to the right tool for the job, and some jobs do just fine without strict types.
Since 7, PHP's also gotten fast enough that most web-related tasks are just faster to solve with it, and it's so easy to deploy a Go binary alongside it for performance-critical parts that it feels like a killer combo in terms of productivity vs performance. Really itching to play with Roadrunner next, which blends those two together into a single app server (https://roadrunner.dev/).
Re: 25 Years of PHP
#208I wrote a lot of PHP from 1999-2008. First as a hobby, then professionally. From 20 LOC guestbooks to payment gateways used to process millions in payments. It wasn't until recently that I was sure I'd written more code in any other language than PHP. These days I'll occasionally poke around with it or patch a bug, but that's about it. Is it a perfect language? No. But which language is? (I can hear the Lisp crowd gr…
Every time there's a story about PHP there's a comment like yours, and then in reply there's a comment like mine: Yes it's perfectly fine to use PHP if it's a productive environment for you. Of course it's possible to write good software with it. Of course a skilled developer will manage to do great things with sub-standard tools. Many extremely popular websites were and even still are powered by PHP, that's undeniab…
> But that doesn't mean that we should absolve PHP of all its many, many design errors over the years. There were for a long time many fundamental issues with PHP as a language that didn't exist with its peers. The language was not so much designed as it was cobbled together by amateurs starting from a half-backed templating engine.
Your entitled, holier-than-thou tone here is not welcome. You must have never created a technical design that solved the stated problems but, in retrospect, turned out to be the wrong decision. Or worked on a project that started out small and flawed but eventually grew into something powerful and reasonably elegant. And clearly, no other programming languages except PHP have ever had to deal with the fallout of certain design decisions that couldn't simply be taken back.
I am looking forward to your reply where you point me to the github repo containing _your_ implementation of a project meeting all of the goals of PHP while containing none of the drawbacks. Only afterward do you have the standing--regardless of how tasteless the action--to hurl insults at the working programmers who have devoted their time (paid and unpaid) to the open source project and get phrases like "amateurs" and "half-baked" in return.
> I'm not saying that to hate on PHP
But you certainly and obviously are.
> This revisionist stance that there was never anything really wrong with PHP and it's just Lispers who hated on the language because it was popular and beginner-friendly and they didn't know what they were talking about is simply, factually, provably untrue.
I don't think you'll find anyone rational who will claim with a straight face that PHP has no issues. Thus, this is a strawman.
Re: 25 Years of PHP
#209Earlier quoted context omitted.
With modern monitors being as large as they are already, I'd say the need for a vertical monitor is likely an indication you're working with spaghetti code.
With modern monitors being as large as they are already, I'd say the need for a landscape monitor is likely an indication you are working in callback hell.
But it's not code all the way from side to side; I've got project structure on, etc.
Meanwhile on the screenshot in the comment I responded to, the vertical monitor is shown only to display a long script or program of sorts, nothing else. I googled for the images of "vertical monitor programming", and the same is true for virtually every picture of such setup. I feel it's not a coincidence
Re: 25 Years of PHP
#210I started with PHP 15 years ago, but after 5 years I just moved to Java. The worst thing with PHP was people and standards, everything was a mess, there was no right way to do stuff and larger projects had like 100 different implementations for the same thing. PHP was really challenging to work with as coming to a shared agreement for how one should implement stuff was a recipe for personal conflicts. So after a few…
> A completely different, but much more enjoyable environment and much more friendly people.
You must have found a neat subculture in Java - not been my experience at all.
The "shared agreement" thing - I've moved between multiple Java environments over the years, and there's never any agreement between companies on the 'right' way to do Java.
Open communities in Java - I've often felt they require a huge amount of tribal knowledge of their 'ways' before they'll deign to answer questions in helpful ways. Mention that you can do X in perl or php or ruby, and you're often dismissed out of hand.