25 Years of PHP • Hacker News Board

Re: 25 Years of PHP

#181

Post by guggle » Wed, Jun 10, 2020, 3:35 PM UTC

elric wrote: 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?

Hey, think about it: in Python we have type annotations that are in code, not comments, and yet THEY DON'T AFFECT RUNNING CODE ! ;-)

> But it's not fair to attack a language over its inexperienced users.

I wrote PHP code in roughly the same period as you. Before a certain point, PHP actively promoted bad practices which was not helpful to the inexperienced users.

Re: 25 Years of PHP

#182

Post by pak9rabid » Wed, Jun 10, 2020, 3:35 PM UTC

bpizzi wrote: post #124

jakearmitage wrote: post #112

Earlier quoted context omitted.

What are you using state for in a web app or API?

Yeah sure, no need for state in a CRUD API. But while it is the most common use case for PHP applications (well actually for application written in scripting languages working with http servers), it's not the only use case. When the only place where you can put state is the database then every piece of state is written in the database. Which lead to intelligent individuals (no pun/offense intended) to write clever pi…

What's wrong with using session variables for maintaining state?

Re: 25 Years of PHP

#183

Post by jeffdavis » Wed, Jun 10, 2020, 3:37 PM UTC

I have a theory that PHP is kind of like erlang -- as a framework and dev environment, not the language itself.

Each request is pretty much independent of the others, and each one can independently crash.

There was also CGI, but CGI always felt a little heavier, and the crashes were harsher (usually just a 501 error and nothing more). PHP embraced the crashes more and provided more information allowing faster debugging.

As a result, generally it was pretty easy to make resilient software.

Critically, PHP also embraced SQL databases, so that crashing meant aborting the transaction (if any). Erlang never meshed quite as well with transactional databases, so trying to keep consistent shared state in erlang felt tricky. In PHP, it was natural.

Re: 25 Years of PHP

#184

Post by karatestomp » Wed, Jun 10, 2020, 3:38 PM UTC

jonny383 wrote: post #6

PHP is damn fast now, no joke. And with all of the modern features it's actually not so bad to work in. I'm becoming increasingly puzzled every time I see PHP hate now, especially when I read tired comments like "just use rails". Laravel is arguably as good or even better than rails at this point, and PHP 7+ is definitely light years faster and lighter. One thing that still sucks is package management / composer.

A lot of PHP work is digging around in Wordpress themes & plugins with a bunch of other (third-party) themes and plugins installed, some of them paid which can add another layer of annoyance to testing and deployment and such. Hosting's usually some managed thing rather than anything under your direct control, and usually quirky or limited in some way or another. It's a pretty miserable ecosystem to work in.

PHP itself is, secretly, actually kinda OK. Some major codebases written in it are no fun at all to work with, including the 800lb gorilla that is WP.

Re: 25 Years of PHP

#185

Post by ragnese » Wed, Jun 10, 2020, 3:40 PM UTC

spacedcowboy wrote: post #176

nobleach wrote: post #138

Earlier quoted context omitted.

Just like I tell people that buy cordless drills at Harbor Freight, "sometimes it IS the tool". Does that mean you can't build fast, meaningful, cool things with it? Of course you can. But, the deeper you get, the more problems you'll have to solve with weird esoteric knowledge. I'll agree with all of your points on horribly inconsistent and broken language features. I get that people that have grown up with the lang…

I mean, who uses mysql_real_escape_string when you have PDO and bindings ? PHP isn’t perfect. As OP said, no language is, and any competent software engineer uses the parts of the language that work well for them, and just ignores the things that don’t work for them. I don’t believe for a second that the abuse the language has suffered over the years has anything to do with mysql_real_escape_string, it’s more to do w…

You're using the two super-fallacious arguments I refer to in my original reply:

1. You can write bad code in any language.

2. All languages have warts.

My response to #1: Here is a rock. Please use it, with some nails, to hang a bunch of pictures on your walls. Don't complain about your tool because it's entirely possible to use it successfully at this task. Or, less sarcastically, why use a tool that encourages bad results when you can use a tool that nudges you toward better results?

My response to #2: Would you rather have one wart, or 100 warts?

Re: 25 Years of PHP

#186

Post by [deleted] » Wed, Jun 10, 2020, 3:40 PM UTC

[deleted]

Re: 25 Years of PHP

#187

Post by johannes1234321 » Wed, Jun 10, 2020, 3:40 PM UTC

Karunamon wrote: post #149

johannes1234321 wrote: post #142

Earlier quoted context omitted.

Doing that means you have to first agree on a name, strcmp has vertical consistency with C. str_compare might be nice, string_compare even nicer. Once that debate is over you have to migrate all old code and all developers and teach them to use the new form. Throwing away all preexisting documentation and telling them why typing more is better. Only then the old form can be removed. Is it really worth it? - And yes,…

Problem 1 is basic standardization and naming things. Hard, but possible. Problem 2 is is solved by adding the deprecation warnings. The code works, but it generates warning messages. Yes, it'll take some time, but I'd argue it's necessary. Unless you've memorized the entire standard library, remembering which functions use underscores and which don't (and which ones use "to" vs "2") is an unnecessary mental burden.

Deprecation warnings which many people will ignore, while new learners still learn with old material.

It is really tough and costs lots of energy.

If you have the energy: Create a complete proposal and push for it. If people feel like you it will go through.

Re: 25 Years of PHP

#188

Post by tannhaeuser » Wed, Jun 10, 2020, 3:41 PM UTC

elric wrote: 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…

While and its equivalents for ejs, asp, or jsp are useful and a defining characteristic of PHP, it is implemented carelessly and prone to injection attacks. Using an SGML processing instruction for integrating scripting into markup languages is only a means of last resort when SGML has much better, type-safe expansion and processing features. "Modern" PHP leaves embedded PHP more or less behind in favour of Java-like frameworks, custom template engines, and other code-heavy approaches. However, the more PHP becomes like JS, the less there is a reason to use PHP over JS (which is at least standardized and has an extremely rich ecosystem) IMO.

Re: 25 Years of PHP

#189

Post by dreamcompiler » Wed, Jun 10, 2020, 3:42 PM UTC

elric wrote: 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…

I'm firmly in the Lisp crowd.

I loved to hate PHP until I was forced to dig into it to help a friend set up a Wordpress site. And now I don't hate it any more. It does the job it was designed to do in a reasonably non-horrible way. I don't think I'd ever try to build a Facebook-scale app with it ;-), but as the BASIC of web site creation, it doesn't completely suck.

Re: 25 Years of PHP

#190

Post by watermelon0 » Wed, Jun 10, 2020, 3:44 PM UTC

dgb23 wrote: post #104

joelbluminator wrote: post #12

Earlier quoted context omitted.

What are the "modern" features of php? It looks like it's trying to shed it's dynamic nature and add types (with annotations etc). Also frameworks like Symfony / Laravel look more and more like java web frameworks to me. I'm not saying this is necessarily bad but there's nothing modern about types. Also, might make more sense to choose java if you need types.

> Also, might make more sense to choose java if you need types. Java is not a replacement for "PHP with types". There is currently nothing you can deploy as easily as a PHP web app. The operational overhead is very low because cheap, robust hosting providers have decades of experience with the most typical LAMP style stack. I would also disagree in terms of language features. Gradual typing through type hints (and ot…

You couldn't be more wrong about the ease of deployment.

PHP is one of the hardest things to deploy. You need at least a web server and a process manager. Most popular choices are nginx + PHP-FPM or Apache + libapache2-mod-php.

You also need to learn how to properly configure both of them, since both have like a million options, and default installation doesn't work in a lot of cases (e.g. uploading of files larger than a few MB).

If you don't want to use libapache2-mod-php, you will have to figure out how to deploy two different services, which makes things difficult in a Docker environment.

---

As opposite to that, deployment story with Go, Rust, and similar compiled-to-a-single-binary languages, is a lot easier. Just drop the binary to a server or add it to a Docker container.