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

131–140 of 489 posts

Re: PHP in 2019

#131

Post by return1 »

cntainer wrote: post #121
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.

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.

Re: PHP in 2019

#133

Post by out_of_protocol »

pornel wrote: post #97
alexandernst wrote: post #63

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…

> (PHP devs memorize the common functions..

Nope (c) Me, after 5 years on trying to but still falling back to googling every 20 minutes despite years and years of using the language.

... And just writing code without looking into docs much after a week with ruby

Re: PHP in 2019

#134

Post by cljs-js-eval »

GrumpyNl wrote: post #91
zaphar wrote: post #81

Earlier quoted context omitted.

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.

You can be burned by every program language if you dont know the in and outs. It all boils down to, pick the right language for the job and more important, know the language you choose.

Seems like to know PHP, though, you need to know all the history that the author has picked up by following the PHP space since forever. Which mysql functions are appropriate, etc. If knowing the language means "being a working programmer in 2010 so that you could gain a working knowledge of the old APIs and some context for the new ones" I'm out. Keep PHP, I'll move to a different language where knowing historical baggage isn't a prerequisite.

Re: PHP in 2019

#135

Post by mateuszf »

GrumpyNl wrote: post #91
zaphar wrote: post #81

Earlier quoted context omitted.

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.

You can be burned by every program language if you dont know the in and outs. It all boils down to, pick the right language for the job and more important, know the language you choose.

There are languages which have great design from the start though (like Clojure).

PHP, javascript are not them.

Probably that's the reason why Clojure tends to be in top of the "developer happiness" polls.

Re: PHP in 2019

#136

Post by lugg »

jbrooksuk wrote: post #61
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…

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

Re: PHP in 2019

#137

Post by [deleted] »

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…

[deleted]

Re: PHP in 2019

#138

Post by sethammons »

GrumpyNl wrote: post #91
zaphar wrote: post #81

Earlier quoted context omitted.

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.

You can be burned by every program language if you dont know the in and outs. It all boils down to, pick the right language for the job and more important, know the language you choose.

Languages have foot guns. Most however don't default to being loaded and already pointed at your foot.

Re: PHP in 2019

#139

Post by mritchie712 »

nickjj wrote: post #27
owenwil wrote: 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…

There are comparable things with other frameworks too. For example I wrote a course on building a SAAS app with Flask. It's available at: https://buildasaasappwithflask.com/ It covers everything about user registration, profiles, subscription billing, 1 time billing, invoicing, and about 50 other things you would likely want to do in a SAAS app or any application really. The course comes with the source code along wi…

Seem's like it'd have to be the "honor system". They could certainly add somethings to detect the software being used on multiple domain, but you could ultimately remove that if you were motivated to.

Re: PHP in 2019

#140

Post by jbrooksuk »

jbrooksuk wrote: post #22
scandinavian wrote: post #14

php > echo count(get_defined_functions(TRUE)['internal']); 1196 They should clean up the global name space, but that will never happen, so I'll continue not using PHP.

Why does the number of methods in the global namespace bother you? * Genuinely interested in the rationale behind this. Sure, it's a lot, but why does that matter?

Why the downvote? This is a genuine question!
Post reply on HN