Live data from Hacker News

25 Years of PHP

jetbrains.com

211–220 of 426 posts

Re: 25 Years of PHP

#211

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…

> I mean, who uses mysql_real_escape_string when you have PDO and bindings ?

You've made my point. A person with tribal knowledge probably would NOT. Any new user coming from reading an older blog post or perhaps a PHP book would have no idea that that "older approach" is out of date.

Furthermore, the more precise point I was trying to make there was as a language designer, how on earth would you be okay implementing something like that? (Remove my example of `mysql_read_escape_string()` and insert any of the more WTF features of PHP.

Lastly, see my comment about being able to build meaningful, fast, cool things with PHP. I never want to tear down anyone's hard work. (Rasmus/Zeev/etc included).

Re: 25 Years of PHP

#212
post #9

Fine. After 20+ years of PHP development I'm going to give it a shot. Will be attempting to migrate from VSCode. Any tips for that transition in particular, or for setting up PHPStorm in general? I have a subscription to Laracasts and plan on watching that series, but I'm not sure if it's outdated. Thanks!

Please do share your PhpStorm journey at some point. I installed it yesterday after trying out Visual Studio Code for the Nth time and again being utterly unimpressed with having to use a GUI fobic editor in 2020. Everything feels clunky and when you start adding more complex plugins things really start to fall apart, like having to use a FTP plugin through the command line. PhpStorm has its flaws [0] but so far I'm…

The cost will go down in future years as you resubscribe. I think that works on the monthly as well as annual subscriptions. The entire toolbox for me is now... $140/year I think (I use data grip, web storm, phpstorm, IntelliJ all regularly)

Re: 25 Years of PHP

#213
post #104

Earlier quoted context omitted.

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

Many smaller PHP web sites are deployed on VPSes and managed with CPanel or Plesk control panels. None of what you describe is necessary. The web server is pre-configured and PHP settings can be easily changed. Even setting up PHP on Ubuntu or CentOS is a 5 minute job. Tweaking configuration settings for max upload, max post size, etc. are very common and well understood.

Once everything is in place, most deployments are as simple as copying the new build over and changing a symlink. No process restarts, nothing.

Re: 25 Years of PHP

#214

Earlier quoted context omitted.

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

Yeah, using prestissimo makes package installation sooooo much faster. My Laravel project with over 100 dependencies downloads in under a minute, where it was like... 10 minutes before

Re: 25 Years of PHP

#215

Earlier quoted context omitted.

He might be referring to the UX problem they have on the sales page where it is non-intuitive that you have to click a button to switch to the individual pricing. This affected me recently.

Holy shit I was just looking at their site the other day and bounced because the price was way beyond anything I'd consider spending. It didn't occur to me that they price differently for individuals, or that it'd default to showing me organization pricing, and after reading theses posts and checking the site my first guess was that individual pricing would be higher (it's much lower for some reason? Are the org. one…

I think the org/business ones are 'seat' - not named licenses. Devs may come and go, but the org can have, say, 8 seats.

Re: 25 Years of PHP

#216

Earlier quoted context omitted.

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…

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 now harmonious and (relatively) pain-free.

There was Cold Fusion, but it was Windows-only. The sane world, at the time, wouldn't serve websites on windows software unless there was a dedicated uptime team involved.

One of these was clearly the better solution. For things it didn't do, it was easy to extend (I wrote the PHP database support for Illustra, a now-defunct object-orientated database that we used)

These days I use it for shell-scripts, and I can bash out something that I need/want in much shorter time (basically because of the enormous standard library) than using any of the other options. My criterion here is "a text editor and 10 minutes"... There are some, very modern, languages that it takes 10 minutes to spin up the IDE and set up the damn project...

Re: 25 Years of PHP

#217
post #161

Earlier quoted context omitted.

Incorrect. Old PHP was more like C. If you see a modern, best practices, PHP code base today, it reads like Java 7 did in 2011.

Whats old is new again. Laravel et al read like java. Nobody wants that crap anymore. Everyones moving codebases back to more procedural styles with a good dose of functional leanings towards immutable values.

I'd say that Symfony reads like Java, whereas Laravel reads like a weird copy of Rails.

Re: 25 Years of PHP

#218

Earlier quoted context omitted.

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…

> I mean, who uses mysql_real_escape_string when you have PDO and bindings ? You've made my point. A person with tribal knowledge probably would NOT. Any new user coming from reading an older blog post or perhaps a PHP book would have no idea that that "older approach" is out of date. Furthermore, the more precise point I was trying to make there was as a language designer, how on earth would you be okay implementing…

Um, I'd criticize a C++ programmer who didn't know anything about the STL as well. Sure, you don't need to know the STL to write C++, but it's an odd decision. If you're going to use a tool, you have to learn it if you want the job done properly.

PHP is old and carries some cruft along with it for compatibility reasons (I suppose). When mysql_* was implemented, the world was a gentler place, and SQL injection wasn't really a thing (or at least, known to be a thing). What you're really complaining about there is "they didn't throw away the stuff that doesn't work well today". That's a decision I can see going either way.

[aside] Having said that, the number of interviews I do where the candidate, poorly, attempts to write me code that implements what could have been done with std::vector is crushingly disappointing. [/aside]

Re: 25 Years of PHP

#219
post #124

Earlier quoted context omitted.

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?

Session variables are tied to user sessions (like name suggests), so they cannot be used to persist application state (e.g. cached content, compiled templates, metrics, etc.)

Re: 25 Years of PHP

#220

Earlier quoted context omitted.

The parent comment claimed that PHP's former sins were being absolved. The quote you are referencing is about the current state of PHP.

The parent comment to mine, though, said: > No one is claiming that PHP is and/or was without fault. I'm emphasizing the "is" part. "No one is claiming that PHP is without fault." My comment is asserting that there are definitely people who say that PHP is not bad. I did not speak to whether anyone claims PHP was never bad.

Well let's be clear ... "bad" is a little more subjective than "faults," which can at least be qualified.

By some measure, every language has warts. PHP in 2008 had a ton of them. PHP in 2020 has fewer of them. Which is a lot like JS.

Post reply on HN