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

81–90 of 489 posts

Re: PHP in 2019

#81

Post by zaphar »

simias wrote: 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…

Yeah, I've been burned too badly by PHP. There are languages I haven't done in years that I would go back to if there was a compelling need to.

PHP is not that language. Far to many sleepless late nights trying to clean up some security hole. PHP is like that abusive Ex that everyone says has changed. It may be true, in which case, good for PHP

But I won't be putting myself in that position again.

Re: PHP in 2019

#82

Post by baybal2 »

simias wrote: 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…

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 business depended on "fixing brokenness"

Open source and sponsorship does not always mix well. Just as with front-end frameworks/libraries that live off sponsorships, eventually it leads to people prioritising pleasing sponsors, and working on pushing their software over improving the software itself.

The current allergy in JS world about genuinely required breaking changes is all about that as well. Any times a talk of genuine "JS 2.0" starts to entertain minds of powerful players in the JS world, there will be tons of people with commercial interest coming and extinguishing the conversation with "no, we absolutely can not ever break anything, ever, even if it is already broken"

Breaking changes in JS world do occur, but most of them being near accidental, security related, or being done as part of actual sabotage like intentional breaking of synchronous AJAX requests after they were shipped.

My logic is, if breaking changes are still unavoidable in JS, why not to do them in a controlled manner, rather than through sneaky sabotage ops like one above?

Re: PHP in 2019

#83

Post by justaaron »

return1 wrote: post #73
simias wrote: 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…

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

https://crystal-lang.org

Re: PHP in 2019

#84

Post by highesttide »

thibran wrote: post #46
jbrooksuk wrote: post #20

Earlier quoted context omitted.

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

This is my opinion. Some hints why I think PHP is not great: * property type declaration in doc-strings * bad documentation * verry verbose for a dynamic language * a lot of inconsistencies * automatically loading of classes is a hack (psr4) which doesn't support importing functions without specifying it in a global project file

As a note, typed properties are coming with 7.4.

Re: PHP in 2019

#85

Post by justaaron »

justaaron wrote: post #83
return1 wrote: 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.

https://crystal-lang.org

despite it's pre 1.0 status it's arguably more production ready than php ever was/will-be etc.

Re: PHP in 2019

#86

Post by swah »

baybal2 wrote: post #43

> PHP isn't the same old crappy language it was ten years ago But it is too late. JS on the backend has nearly completely ate its mindshare in its target demographic. I think, JS itself risks ending up like this if core developers in Node and TC39 will not begin to think of the need for JS 2.0 and fixing fundamental design issues, and bug-o-features.

I usually code a backend in Go or Python, but recently been thinking if I should just abandon my "prejudice" (JS sucks, Node sucks, Node is single threaded, there are no SQL libraries, etc) and move to JS on the backend as well, since that's what I already use on the frontend - be it web or React Native.

(I actually find JS very expressive and oriented towards a style of "table-oriented programming" which is useful for software that changes a lot like UI, IMO).

Re: PHP in 2019

#87

Post by stdclass »

gog wrote: post #18
SXX wrote: post #15

Earlier quoted context omitted.

> Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy. It's also use abysmal amounts for RAM for some reason. I managed to use Chrome headless for my app with only 512MB, but not Composer.

How long ago was that? There were some issues if you had xdebug enabled, but AFAIK that has been fixed.

Just today, I had to resize the swap on a raspberry pi so composer could update the dependencies.

Re: PHP in 2019

#88

Post by bovermyer »

My major side project does most of the heavy lifting in an API written in Go, but the front end is a Laravel app.

It works nicely, is easy to make changes to, and gets out of my way.

/shrug

Re: PHP in 2019

#89

Post by mgkimsal »

pilif wrote: post #62
richardwhiuk wrote: post #56

Earlier quoted context omitted.

It can be changed. You have some syntax to opt into a later release (e.g. doing ` In a major release, you then get rid of a load of cruft.

> You have some syntax to opt into a later release (e.g. doing ` imagine the exponential complexity as old behaviours need to be kept around for various levels of opting in.

There's already been a degree of that with php.ini flags, and some of the behaviours available via those flags have been deprecated then removed over a period of years. It's not impossible. Yes, it's complex, but the process for dealing with that complexity has already existed and worked out ... relatively smoothly. The bigger issue is getting people to upgrade - I'm still dealing with a couple of projects - one started in 2017 - that are on PHP 5.6.

Re: PHP in 2019

#90

Post by majewsky »

If the author happens to read this thread: Please please please use a different font. Serif fonts with very dynamic stroke strengths look awesome in print, but they break down on screens where the narrow strokes round down to 0px and vanish. Although I'm reading this on a HiDPI notebook display (1440p over 13"), I have to crank up the text zoom to at least 150% to be able to read the article comfortably.
Post reply on HN