Live data from Hacker News

PHP in 2019

stitcher.io

181–190 of 489 posts

Re: PHP in 2019

#181
post #51

As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like. Is performance that much of a big deal for most people? In a world where Rub…

Your comment reads as "I like ruby therefor php is dumb"

> Is performance that much of a big deal for most people? Yes obviously. Performance is important no matter the language.

> the counter-intuitive behaviour of '==' You should learn the languages type system instead of assuming it works how you think. Again this is true of every language.

> I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them? The built in linter gives you a warning that its obsolete.

The inconsistent naming and arguments. Dumb defaults and thousands of functions in a global namespace is the real problem and there is no solution to it. Oh and calling functions is unacceptably slow, that they can and need to fix the rest of this is just I like my language better.

Re: PHP in 2019

#182
post #97

Earlier quoted context omitted.

I'm not really sure why this comment is getting downvoted, but literally every single thing in that post still holds true.

No, it's not. PHP has disabled or removed the major anti-features like magic quotes, globals, URL includes and the bad mysql extension. It has a proper AST-compatible parser which removed tons of quirks, and added syntax sugar to look more normal to outsiders. The remaining things are: • the endless whine about inconsistent underscores in function names and haystack/needle. These are a bad look, but aren't really an…

And on its quest towards JIT the language becomes less and less dynamically typed. strict_types=1 is already a standard in most major applications and all the cleanup that has been done already, such as count() raises an error if you try to count a non-countable variable, and many more.

Re: PHP in 2019

#183
post #143
post #51

As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like. Is performance that much of a big deal for most people? In a world where Rub…

> Server are cheaper and vastly more powerful now than in PHP's infancy Slightly off-topic, but I think that nowdays it's actually less of an argument than when PHP started becoming popular. The thing is, back in the days, statically typed languages were just bad and unproductive. Today, they are way better, and the fact that I can run my service on $3/month server with 900M of RAM and not think about the price tag a…

With more companies moving to virtualized hosts, I bet performance becomes a real consideration. With most services I've seen, you buy server capacity in doubling increments. So either your application fits into 2 vcores @ 2.2GB with 8GB or RAM, or you step up to 4 vcores and 16GB, with costs also doubling.

Re: PHP in 2019

#186
post #143

Earlier quoted context omitted.

> Server are cheaper and vastly more powerful now than in PHP's infancy Slightly off-topic, but I think that nowdays it's actually less of an argument than when PHP started becoming popular. The thing is, back in the days, statically typed languages were just bad and unproductive. Today, they are way better, and the fact that I can run my service on $3/month server with 900M of RAM and not think about the price tag a…

With more companies moving to virtualized hosts, I bet performance becomes a real consideration. With most services I've seen, you buy server capacity in doubling increments. So either your application fits into 2 vcores @ 2.2GB with 8GB or RAM, or you step up to 4 vcores and 16GB, with costs also doubling.

Good point! Let's not forget that, unlike the old days, it's kind of a standard to require redundancy and load-balancing from day 1, so not fitting machine's RAM hurts even more.

Re: PHP in 2019

#187
I worked at a small PHP shop for about two years. There was a ton of legacy code that was utterly terrifying: a 13-deep nested `if` and the like, global variables, etc.

I convinced my boss to let me start using Laravel. It made development worlds more sane. It made development orders of magnitude easier. Laravel does a lot for you, and they’ve thought about how to solve some tricky problems in clever ways.

That being said, I would never recommend PHP as the language to solve any given problem. It is now less of a terrible language and more of simply a mediocre language. I can’t think of anything it does particularly better than another language. For any given problem, there is most certainly a better language to solve it, be it Ruby, Elixir, Clojure, Rust, etc.

I’ve been working with Elixir and Phoenix for web development for a few months now, and it is sooooo much better. It’s hard for me to enumerate all the things, small and large, that reduce developer friction in contrast to even PHP’s best framework.

Re: PHP in 2019

#188
post #73

Earlier quoted context omitted.

> Is performance that much of a big deal for most people? For most people outside VC-funded startups, yes it is. It is also an environmental concern, imagine if 80% of the web was running on ruby.

Well if 80% of the web was running on ruby there wouldn't be any difference. Most people don't understand that 99% of performance issues are not caused by language performance but by bad architecture and bad developers. Always choose the best tool for the job, you rarely get to that scale and quality of software design that only the raw language performance is left to be optimized :)

[deleted]

Re: PHP in 2019

#189
post #51

As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like. Is performance that much of a big deal for most people? In a world where Rub…

> ven assuming that "modern" PHP managed to come up with better ways to deal with all of this, I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them? I think the "path of least resistance" is important: developers are time-constrained, understanding-constrained, lazy (if they're virtuous), etc. There's a big incentive to do whatever is easiest/quicke…

funny, because it's what React.js allows to do nowadays

Re: PHP in 2019

#190
PHP isn't going anywhere. PHP is fine. Perl, Ruby, Python, all fine. That being said, for general programming TypeScript/JavaScript is the way forward. Other than PHP, I have loved all these interpreters. It's over. Accept the middle and move on. Everything else is nitch.
Post reply on HN