Live data from Hacker News

25 Years of PHP

jetbrains.com

241–250 of 426 posts

Re: 25 Years of PHP

#241

Earlier quoted context omitted.

1981? The title of the article is "25 Years of PHP", which checks out because PHP appeared in 1995, and this is 2020, and 2020-1995=25, but 1981 was 39 years ago. The ARPANET was using NCP with 8 bit host IDs in 1981, and nobody was listening for the HTTP protocol on port 80 back then, and homosocketuality was still prohibited. https://news.ycombinator.com/item?id=14178993 >The act of trying to connect an even socket…

Yup. My bad. I started trying to figure out when it was by when I was at college, how long I did the PhD for, how long I was in the first job, how long into the second job I started using it and I screwed up the maths along the way. It was in 1996, not 1981... No excuses, that's just bad.

You also said you wrote the asset management system that was used by Lucasfilm on Star Wars, which was released in 1977. Are you sure you don't mean one of the later J. J. Abrams films, and not the film whose title was actually "Star Wars"?

Mistakes about dates and context aside, I still can't believe you're actually trying to make excuses for mysql_real_escape_string. It has the word "real" in it. I mean, come on, who would ever name a function "real", and why?

That implies the existance of a not-so-real mysql escape string function. Why didn't they simply FIX the gaping security hole in the not-so-real mysql escape string function, instead of maintaining one that was real that you should use, and one that was not so real that you should definitely not use, in the name of backwards compatibility?

Or were there actually people out there using the non-real mysql escape string function, and they didn't want to ruffle their feathers by forcing those people with code that had a security hole so big you could fly a space shuttle through to fix their gaping security holes?

The name of the function "mysql_real_escape_string" says all you need to know about the culture and carelessness and lack of security consciousness of the not-so-recent PHP community.

And you shouldn't be making excuses for it, or blaming it on the wrong people for using it, instead of the right people for creating it then evangelizing it then not fixing it. It was a TERRIBLE mistake.

The crappy code was PHP itself, and the code was crappy because the culture was crappy. I'm not going to start linking to all the anti-intellectual Rasmus quotes, or to the bug report about the time he checked in huge security regression to the crypto code that would have been caught by the tests, and then CUT A RELEASE, but didn't bother running the tests first because they produced so many errors. But you can google that debacle yourself.

Re: 25 Years of PHP

#242

I've been using PHP for most of my web development career (a decade). What are the industry standards for backend web development languages in 2020? I was under the impression PHP was the way to go for back end web development.

I would say golang has been a strong contender for that role for a while now besides the usual java/ruby/python stacks. You can use many languages for your backend, but golang is IMHO the best out there right now (but as always: it really depends on your use-case)

Re: 25 Years of PHP

#243
post #32

I 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…

>My only real gripe with PHP is the annotation syntax. Yikes. Stuff that's in comments SHOULD NOT AFFECT RUNNING CODE. Who came up with that?

Don't check out Golang then...

Re: 25 Years of PHP

#244

Earlier quoted context omitted.

Not really. As I thought I'd alluded to in the above, when I was using PHP "in anger" as it were, there were 3 options for dynamic content: 1) Write a C program, and use the GCI-BIN interface. In developmental terms, this sucked dead bunnies through thin straws 2) Use some god-awful server-side script thing, updating static files with externally-invoked changes. Yes, people resorted to this. 3) Use PHP/FI. Life is no…

You're moving the goalposts. PHP was a great option in 1995. It is not today (except as a basic scripting language, where you and I agree completely. I would use PHP as soon as my bash script gets to about 100 lines). Your post here is arguing about 1995 or whatever. The post I replied to was full of present-tense about "just use the good parts" and "all languages have issues", etc.

I disagree that PHP was a great option in 1995.

It was an accessible and good enough option, for multiple reasons. The primary of which was the fact that it was built up for the web and was extremely cheap to host.

Re: 25 Years of PHP

#245
post #151

Earlier quoted context omitted.

> PHP's low entry barrier is a blessing That's the error.

What's up with that elitist attitude? Are you saying that people shouldn't be able to write code unless they've first how to do it properly?

I think he's saying that PHP enabled a lot of people to build disastrously broken systems to do jobs they had no idea how to do.

I worked for a shop in the past that had this problem in spades - huge ColdFusion and PHP ecommerce sites that were a gigantic ball of horrifying security and functionality failures, started by people who taught themselves how to program on the job because someone said "we should sell our stuff on the web".

I guess the world is probably net better for those sites existing, even as they are, but it feels like PHP could have done a better job of helping learners not shoot themselves so violently in the foot.

Re: 25 Years of PHP

#246
post #121

While I don't use PHP today, it always makes me wonder at deceptively easy it is to deploy a PHP app. There's no having to worry about restarting processes since the next request picks up the code changes and deploying at scale has so many problems auto-solved by that such as rolling restarts. You can then handle things like percent based feature roll outs at the application level which is likely where it belongs any…

>There's no having to worry about restarting processes since the next request picks up the code changes and deploying at scale has so many problems auto-solved by that such as rolling restarts.

Nearly any serious PHP deployment will use an opcode cache which has to be invalidated, though maybe they are smart enough to do that from the filesystem now.

>On the flip side, for single server deploys, you can also get by with zero down deploys without needing to set anything up

Mod_python works about the same as mod_php although you are right insofar as most advice is to use a separate uWSGI process.

>You can then handle things like percent based feature roll outs at the application level which is likely where it belongs anyways.

You want incremental rollout essentially every time you change code; if you feature flagged every single change, you'd have your codebase's entire history all hanging out on master, with far too many possible combinations of feature flags to ever test. The nice thing about rolling back and forth with code is that each version is internally coherent.

Re: 25 Years of PHP

#247

Earlier quoted context omitted.

> It has a very rich standard library Yet I still have to define startsWith() and endsWith() any time I touch PHP code... (More importantly, PHP is the one language I can never write from memory without referencing the manual for each and every function call because of how inconsistent it is. Eg Sometimes $haystack is the first parameter and sometimes it is $needle.)

str_starts_with() and str_ends_with() are coming in PHP 8.0.

That would be str_starts_with() and strendswith(). &$ing up functions names is a feature of PHP.

Re: 25 Years of PHP

#248

Earlier quoted context omitted.

PHP is way less verbose. I wouldn't say it really looks like Java, maybe more like C++.

Stop looking at the syntax, then. PHP semantics almost completely match Java's- single inheritance, no const, everything is a reference, effectively no top-level functions, etc. And in what way is it actually less verbose? It's almost identical to Java...

As in defined outside of any class, object, or interface? PHP has a million of those and people write their own that way all the time. Everything is certainly not a reference and constants exist. Are you just talking about some narrow subset of PHP used in some frameworks?

Re: 25 Years of PHP

#250
post #95
post #53

Earlier quoted context omitted.

Yeah I worded that poorly, but once I went full on caps I decided to leave it, ahem :/. I get the idea of a compile step, and that's totally fine. But these annotations are commented out. It's very icky to be using them for anything other than documentation -- which is what comments are for, after all. Java's annotations are a bit different. Sure, the compiler does things with them -- the runtime does, too --, but th…

Is a heftier compile step totally fine? The biggest difference between PHP and Java in my mind is that you start Java and pay the compile cost on server start, in PHP you pay the compile cost on every request, frameworks and language features increasingly hide this future cost in caches but caches are one of the two hardest things in computing and often act like pushing things under the carpet, why optimise the compi…

Meanwhile with something like NextJS/TypeScript/React you can just enjoy instant reloads without ever caring about F5 again

The more languages the better IMHO though

Post reply on HN