Live data from Hacker News

PHP in 2019

stitcher.io

161–170 of 489 posts

Re: PHP in 2019

#161

Earlier quoted context omitted.

> but it is still the worse mainstream programming language. Please back this up.

https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ Well, this is still true.

I mean, apart from the huge number of items that have been fixed over the years, yeah.

Re: PHP in 2019

#162
post #107
post #82

Earlier quoted context omitted.

What ended PHP were not the worst parts of its design, but upstream's unwillingness to simply change the language for better. See, as a commercial enterprise (begware as a business) all kinds of "foundations" and sponsorship pools surrounding the language already accumulated a big enough pool of clients who were happy enough with PHP as it was in 4.0 era. They had no intensive to progress. Especially if their busines…

I think ended is pretty strong word for a language that powers a huge portion of the web. Yes the lang. has issues and yet WordPress, Magento etc. are used an order of magnitude more than alternatives written in other languages.

Behind the language, the early day of shared web hosting make it affordable.

Re: PHP in 2019

#163

Earlier quoted context omitted.

All apps I saw, written in Ruby, were awfully slow. I don't know Ruby, maybe it's just me, but would be interesting to know examples of not slow Ruby apps.

Well, github, just to name one:). Also shopify, digital ocean, stripe. I also worked on a large ruby app that was faster than another large Java app. Keep is mind that all these platforms handle a great deal of requests at any given time, so we're not talking simple web apps. In my experience bad software design, bad DB design and bad developers are the major cause for performance issues, you rarely get to that level…

Stripe is a good example, thanks.

I absolutely agree that in a good web app DB is a bottleneck and can be 10 times slower than any part of the web app itself, regardless of the language.

Maybe Ruby ORMs are not so optimized, who knows.

Re: PHP in 2019

#165
post #136

Earlier quoted context omitted.

> [...] its defenders should focus on actually showing what modern PHP code looks like. Laravel does this very well, not just by being a great framework but also in its ecosystem (Envoyer, Forge, Spark, Nova, Horizon, Socialite) and its documentation ( https://laravel.com/docs/master ).

If laravel is the best we have were fucked. Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.

Symfony is better at handling backward compatibility and managing deprecation.

Still over-engineered I guess but sometimes it means you won't have to go against the framework for some complicated tasks.

Re: PHP in 2019

#166
post #2

I've actually been really impressed with Laravel after switching back to PHP for a few projects. Not only is the developer tooling experience some of the best I've experienced, it's just really the only framework I've ever experienced with a high quality ecosystem of tools—from Forge[1], which makes it dead-simple to deploy a Laravel app into production to things like Horizon, for managing Redis queues. A great examp…

> Composer, the package distribution system

a package distribution system.

Composer suffers some of the same issues NPM does, IMO: it encourages stuff like 'install dependencies at deployment' and "why write it when you can blindly trust someone else's code".

Not everyone who uses PHP uses Composer.

Re: PHP in 2019

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

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 to write code this way... but people still do.

Re: PHP in 2019

#168

The thing that matters is language consistency... A language with a pure clean vision of itself in which the programmer can guess at syntax because they understand the general syntax principles to which the language adheres. Nothing here says PHP has been fixed in this regard. Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further…

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…

See, I code php very rarely, I review php code a bit more often, and I stumble upon these inconsistencies all the time. So because you got used to something bad doesn't mean it's not bad.

Re: PHP in 2019

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

> its defenders should focus on actually showing what modern PHP code looks like This is one of my personal side projects, written in PHP and Laravel: https://github.com/brendt/aggregate.stitcher.io Here's a list of all OSS package we maintain at work: https://github.com/spatie

some very interesting stuff in there! Thanks for sharing!

Re: PHP in 2019

#170

Earlier quoted context omitted.

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 :)

Tbh most of it is wordpress, and that is not terribly inefficient.

I haven't touched wordpress in 8 years, but with old codebases you always inherit a lot of bad design decisions that always have an impact on general performance.

Maybe the wordpress guys have done a great job in rewriting the internals and cleaning things up in the last years, I wouldn't know, I don't follow their progress.

Post reply on HN