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

281–290 of 489 posts

Re: PHP in 2019

#281

Post by ilmiont »

Writing with PHP is better than ever... and getting better and better.

And... you don't need too worry too much about the server, or the request lifecycle, or networking... you just write your app, in a language which is, in my opinion, going in the right direction with a stronger slant towards OOP and types.

Of course it's still entirely possible to write garbage PHP code... but it's possible to write garbage in anything.

I'm increasingly proud to say I'm a PHP developer; it still gets a lot of bad commentary but it all tends to be based on historical stigmas which are increasingly untrue. Yet all the original benefits are still here, and the language itself is going from strength to strength...

Re: PHP in 2019

#282

Post by eithed »

joemaller1 wrote: post #245

I've been using PHP semi-regularly since the late 90s. It's been empowering and infuriating. The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards. For whatever reason, I often feel clu…

Laravel has Collection class that wraps arrays - as such you can do `(new Collection([your array]))->filter(function(){})` or `(new Collection([your array]))->map(function(){})`. It also adds other helper methods. I guess Symfony has something similar

Reference: https://laravel.com/docs/5.8/collections

Re: PHP in 2019

#283

Post by earthboundkid »

taytus wrote: post #254
joemaller1 wrote: post #245

I've been using PHP semi-regularly since the late 90s. It's been empowering and infuriating. The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards. For whatever reason, I often feel clu…

Infuriating? I'm not here to defend php but even when I do agree that inconsistencies are not nice, nothing stop you of creating your own wrapper for these functions. Infuriating? really?

Yes, it is really infuriating that PHP literally cannot commit to any coding standards whatsoever for its standard library. Even if you choose to write your own wrappers, it doesn't change other people's code which you have to read. It's idiotic that the developers of PHP didn't take 5 seconds to consult their other functions before adding new ones with the arguments reversed, and it is totally appropriate to feel angry at them for their unconscionable shortsightedness.

Re: PHP in 2019

#285

Post by dark1 »

davidy123 wrote: post #264
toastal wrote: post #112

Earlier quoted context omitted.

I dunno... Their home page looks like something out of the Panera Bread playbook looking at the homepage. 'Web artisans'? Why is it 'clean' because it has an absurd amount of whitespace and comments of platitudes for the code example?

PHP frameworks crack me up. They so often claim they're "powerful." What does that mean exactly, who is that language aimed at? Then there is Laravel, why "artisans?" The word generally means pre-industrial. In my mind, that evokes devs doing edits on live code. Also, "Laravel" sounds like something to do with larvae. Then there's Drupal, which for the longest time was "community plumbing," which did match the experi…

Your complaints about Laravel are hilariously shallow. If that's all it takes to turn you off of something... wow.

Also, who's talking about Drupal here? There are complex legacy CMS's for every language.

Re: PHP in 2019

#286

Post by johnday »

gog wrote: post #23
johnday wrote: post #5

Thanks for sharing. The thing that I am most concerned about with PHP is not, strictly speaking, the language itself. The syntax is slightly odd but otherwise fine. And the semantics are much the same as any similar language. The real problem that I find with PHP is that the designers seem (from an outside perspective) to take a similar approach towards language backward-compatibility that, for example, C/C++ have. T…

The amount of legacy applications being run on the internet is huge. Breaking stuff would put a great financial burden on the companies running those. It is a sensible approach IMHO. What kind of bad stuff are you talking about? If you talk about function names and parameter ordering not being consistent that is not an issue for developers using the language daily, most of them are using an IDE so it doesn't matter a…

> If you talk about function names and parameter ordering not being consistent that is not an issue for developers using the language daily

It does feel like this is analogous to saying "the holes in the floor of our building aren't an issue - all the senior devs know where they are by now"

Re: PHP in 2019

#287

Post by hiccuphippo »

The thing I like about php the most is how all the different frameworks have come together to create standard interfaces for building frameworks. I was able to easily create my own microframework using packages from zend, symfony and the php league.

Re: PHP in 2019

#288

Post by noir_lord »

Shish2k wrote: post #230
golfer wrote: post #57

So much of the web is powered by PHP. Wikipedia (MediaWiki software) and Facebook are two of the largest footprints of usage. And of course, WordPress. PHP has a lot of firepower behind it.

The Facebook www code is written in Hack, which started off as a PHP-compatible language / stdlib, and then dropped PHP compatibility when it was holding them back. Having worked with both, any one of the major additions (XHP, good type annotations, sane collection types, etc) makes my development experience 10x better; going back to vanilla PHP now just makes me sad...

Collection types is a big one for me, I miss those like crazy when working in PHP.

Re: PHP in 2019

#289

Post by stephenr »

ryeguy wrote: post #262
stephenr wrote: post #166

Earlier quoted context omitted.

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

The vast majority of people using a package manager in the PHP ecosystem are using composer. It makes sense to call it "the" package manager.

I’d argue that the only “the” is one that’s distributed with it, which is PEAR. I’m not saying PEAR is used more or that it’s better, just that it’s the only one close to “default” with the language distributions.

Re: PHP in 2019

#290

Post by xrd »

xrd wrote: post #231

I think the way to analyze a language and framework should be: "what does this framework permit the worst developer on the team to do?" I think the story for Php in this regard has not been a good one historically. You can put processes like PR review, and add coding standards, but getting things done will always trump those things, especially when you are bootstrapping. If you can tell me modern PHP is better than t…

For example, coding standards:

`There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.`

https://github.com/php-fig/fig-standards/blob/master/accepte...

A language that has to permit this kind of thing (or thinks it has to) is just going to lead to developer infighting. This is an important issue because GitHub PRs are going to be unreadable if one developer can insist that "this line needs to be 145 characters..." and then no-one can diff changes to that code. You can break the PR process with this kind of thing.

Post reply on HN