Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PHP in 2019

stitcher.io

Post reply on HN
Print view View original

201–210 of 489 posts

Re: PHP in 2019

#201

Post by aczerepinski »

coblers wrote: post #21

Maybe it isn't, but other languages/frameworks have improved the past ten years as well. I don't see the selling point in building something in PHP in 2019 when you have similar if not better/more mature languages/frameworks at your disposal. Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more stable surface to build upon it? I really fail to see where PHP has its place in 2019. For your "buil…

That's how I feel. I'm glad to hear it's improved, but "not as bad as it used to be" isn't a compelling argument that would make me consider PHP over Elixir/Go.

Re: PHP in 2019

#202

Post by jfengel »

rob74 wrote: post #198
chriswarbo wrote: post #123

Earlier quoted context omitted.

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

To understand that, you have to take a closer look at its origins. For me, this talk by Rasmus Lerdorf (creator of PHP) was a real eye-opener: https://www.youtube.com/watch?v=SvEGwtgLtjA He mentions that what we now refer to as the "PHP language" was originally intended to be only the templating system, and you were supposed to write your business logic in a "real language" such as C. However, as PHP got more popular…

That's kinda the problem with any domain-specific language: it either requires a full language for support, or it becomes one (and generally not a very good one). Every language is an opinion about what things should be easy and what things are allowed to be hard.

I've got nothing against DSLs and template languages and such, but most of the ones I encounter make me sigh and say, "I know you thought it would be easier but it's just one more thing I have to figure out how to debug, without any of my usual debugging tools."

Re: PHP in 2019

#203

Post by efficax »

larzang wrote: post #78

As a primary PHP developer, PHP has improved by leaps and bounds in the ten years I've been working with it, however there's still a major fundamental issue that has seen improvement but remains unresolved: function overhead. Contrived example: - https://3v4l.org/eEtFl - https://3v4l.org/8QMFh Two identical ways to do the same thing, one with nicer FP-like syntax, but because of function overhead even on 7.3.x it's s…

Do you really find function overhead to be that great of an impact on performance? I work on a php app that sees around 15k/rps and I use a lot of functional patterns (feels best to me, my brain was formed in a lispy way).

By far database time remains our biggest bottleneck, especially since we finally made it onto PHP7

Re: PHP in 2019

#204

Post by myspy »

Working with Laravel for more than a year now and it enables writing quality code. Testing is nice, as is building models, routing, validation, and authorization.

PHP itself is not that important. The language is solid and does its stuff. I'm moving mainly in the framework to create functionality.

Re: PHP in 2019

#205

Post by mattferderer »

I think the easiest thing to forget is what made PHP popular was how easy it was to get started writing software that worked good enough. The barrier to entry was incredibly low. It caused a lot of bad code & gave PHP a bad reputation but a lot of good was also made from it.

PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses.

While PHP is nothing like its former self, most people who developed web apps in the first decade of the century will probably always remember PHP for what it was.

Re: PHP in 2019

#206

Post by maxxxxx »

LoSboccacc wrote: post #196

eh my problem with php never really was performance (up to a point) or the language itself, it was the default library making figuring out every operation an exercise in googling like, why the weird _ difference between strtok and str_split, why str_replace has the search first and string as third parameter but in strpos the source string is the first parameter and then the search term the second it's all confusing a…

When I did more PHP I quickly ended up writing my own sort of standard library with consistent functions and unit testing. It doesn’t really take much time and makes things much more predictable.

Re: PHP in 2019

#207

Post by stefanfisk »

stickfigure wrote: post #167
chriswarbo wrote: post #123

Earlier quoted context omitted.

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

You can't remove those old APIs without changing culture, and culture is really hard to change. One thing that shocked me during my brief foray into PHP was how heavily popular PHP apps like WordPress rely on the filesystem. Want to move a site? Copy the database, and copy a bunch of files . It seems like there's a cultural expectation that applications run on a single server in your closet. Of course you don't have…

WordPress is NOT an example of modern PHP practices though. The amount of legacy insanity in WordPress is enough to make any sane dev cry...

Re: PHP in 2019

#208

Post by icedchai »

pragmaticlurker wrote: post #189
chriswarbo wrote: post #123

Earlier quoted context omitted.

> 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

The difference is React actually handles escaping properly. It won't just dump out raw HTML by default, so you won't have an XSS issue.

PHP, on the other hand, requires manual escaping with htmlentities() ... It is very, very error prone.

Re: PHP in 2019

#209

Post by Moru »

Klathmon wrote: post #110
deanclatworthy wrote: post #75

Earlier quoted context omitted.

I've been coding in PHP for almost 20 years now. I think I can count on one hand the number of times where I have had an issue regarding inconsistent function signatures. It becomes second nature, and if I forget, the documentation is available online or in worst case built into my IDE. I can understand why people make this into such a pain point, but quite frankly it isn't for anyone who works day in day out with PH…

That's what really gets me. Anyone that works with PHP on a daily basis very quickly gets used to some of the naming differences or inconsistent signatures. Anyone that works with PHP rarely is almost assuredly going to have to look it up regardless of how inconsistent it is. (do people really guess at function names, signatures, and return values in other languages!? I've guessed that they exist, but I don't ever th…

For a while it was popular to just create your own functions with your own naming convention and parameter order, easy to do and you have whatever order is sane for you. Lots of frameworks around now so you don't even have to do that any more.

Re: PHP in 2019

#210

Post by kibwen »

mywittyname wrote: post #178
swalsh wrote: post #153

Earlier quoted context omitted.

I was pretty anti-PHP before I worked for a multi-billion dollar company that was built on top of it. It's not a beautiful language, but it offers a lot of side benefits in terms of dev-ops, and tooling, and frameworks. As a company, the language was not something that held us back. The company moved really fast, and PHP was a large part a big part of why. In my career over the past 14 years I've done web work using…

I have to echo this. I worked on a data pipeline that was a mountain of PHP scripts bolted together with Bash and it was such a breeze to maintain. Using Symfony ensures that every command is well documented and consistent in design and use. Something I never appreciated about PHP until recently is that character encoding is so much more robust in PHP than other languages. We were forced to replace our pipeline with…

Which version of Python? I ask because making fundamental changes to character encoding was the single most disruptive feature of the Python 2/Python 3 split.
Post reply on HN