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

PHP – The Right Way

phptherightway.com

Post reply on HN
Print view View original

291–300 of 349 posts

Re: PHP – The Right Way

#291

Post by dncornholio »

berkes wrote: post #88
akie wrote: post #77

Earlier quoted context omitted.

Quoted post unavailable.

Why do you presume this is "hearsay PHP hatred"? I (not parent) have PHP hatred. It is fuelled by decades of PHP development and -exposure. My hatred is based on failing projects, missed deadlines, burnouts, money stolen, severe downtime, and companies going bankrupt. PHP had a role (not the primary, mind you!) in all of them.

You literally said you had only experience with WordPress. Yeah those failing project make a lot of sense now.. Do you know WordPress was build by web-designers, not actual developers?

Using it for anything else then a forward facing website is a bad idea. Even using it for a website is a bad idea btw, because it was made for blogs, but whatever, nobody listened then, nobody will listen now. But I have peace with it, as long as it's only used for simple stuff.

Re: PHP – The Right Way

#292

Post by inoop »

dotancohen wrote: post #287
inoop wrote: post #275

Earlier quoted context omitted.

> If you're conversing with someone who believes that the JVM is a resource hog, then you are likely conversing with someone with decades of experience As someone who has actually read the JVM specifications many times, has actively worked on a JVM implementation, and has a pretty good grasp on virtual machine design, I beg to differ. But hey, I'll take the bait, what makes you think the JVM is a 'resource hog'?

I no longer think that the JVM is a resource hog. In fact I implied that it was an archaic mindset by suggesting that someone who thinks so has been decades in the industry. That said, many Java applications themselves are resource hogs. Even my preferred IDE, the Jetbrains suite which I love, are resource hogs. Perhaps I'm simply not configuring it properly, but arguably I wouldn't ask an end user to tune JVM parame…

> Even my preferred IDE, the Jetbrains suite which I love, are resource hogs

Ok, so you're saying that because a large, complex desktop application uses a lot of memory and is also written in Java that therefore the JVM is a memory hog?

Well then, given how much of a memory hog Chrome is, I guess we can all shitcan C/C++ as well.

Look, in any reasonable apples-to-apples comparison the JVM blows anything PHP has out of the water, including haxe, hiphop, etc.

And even if you write a PHP-to-bytecode compiler (e.g. https://github.com/jphp-group/jphp) then there are certain limitations to how fast and efficient any dynamically typed language can be. Look at all the shit V8 has to go through to do field lookups: https://v8.dev/blog/fast-properties

And then there's so much useless request-level overhead to PHP, even with pre-cached bytecode, you're never going to get even close in terms of latency to a well tuned JVM running something like spring boot.

And if you really hate Java as a language, you can always use something like Kotlin.

Re: PHP – The Right Way

#293

Post by ramesh31 »

cies wrote: post #186
jonwinstanley wrote: post #161

Earlier quoted context omitted.

The main comparisons I have are building sites with Ruby/Rails and doing JS front ends attached to REST APIs. All three types of project have their own pros and cons.

The fair comparison: PHP/Laravel to Ruby/Rails... How is PHP/Laravel better? I'm of the opinion it loses hard in every aspect.

>How is PHP/Laravel better? I'm of the opinion it loses hard in every aspect.

Performance. Ruby (with the official implementation) is brutally slow compared to PHP on Zend Engine [0], which is probably only behind the JVM in terms of VM performance and optimization for any language. PHP, if done properly, is a really great choice nowadays for a scripting language that can approximate C++/C#/Java levels of performance.

[0] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...

Re: PHP – The Right Way

#294

Post by inoop »

tehbeard wrote: post #290
inoop wrote: post #283

Earlier quoted context omitted.

> That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the o…

Because, suprisingly, Noone is forcing you to update immediately! Hell, there's still a lot of 5.x deployments out there that work just fine. I even manage one or two (both of them being very old, legacy installations in enterprises. In both cases I'm making slow and steady progress to getting them up to 7.x or 8.x so that we can benefit from engine improvements etc). > Why would anyone in their right mind use a lang…

> Because, suprisingly, Noone is forcing you to update immediately!

Excuse me, where do you work? Do you not have a company policy about not using software that isn't actively receiving security updates?

Re: PHP – The Right Way

#295

Post by cies »

ramesh31 wrote: post #293
cies wrote: post #186

Earlier quoted context omitted.

The fair comparison: PHP/Laravel to Ruby/Rails... How is PHP/Laravel better? I'm of the opinion it loses hard in every aspect.

>How is PHP/Laravel better? I'm of the opinion it loses hard in every aspect. Performance. Ruby (with the official implementation) is brutally slow compared to PHP on Zend Engine [0], which is probably only behind the JVM in terms of VM performance and optimization for any language. PHP, if done properly, is a really great choice nowadays for a scripting language that can approximate C++/C#/Java levels of performance…

> PHP, if done properly, is a really great choice nowadays.

Same for Ruby. I found them both slow compared to compiled to native langs.

JVM is also slow (especially startup)

Re: PHP – The Right Way

#296

Post by 9dev »

inoop wrote: post #294
tehbeard wrote: post #290

Earlier quoted context omitted.

Because, suprisingly, Noone is forcing you to update immediately! Hell, there's still a lot of 5.x deployments out there that work just fine. I even manage one or two (both of them being very old, legacy installations in enterprises. In both cases I'm making slow and steady progress to getting them up to 7.x or 8.x so that we can benefit from engine improvements etc). > Why would anyone in their right mind use a lang…

> Because, suprisingly, Noone is forcing you to update immediately! Excuse me, where do you work? Do you not have a company policy about not using software that isn't actively receiving security updates?

PHP releases receive three years of updates :)

Re: PHP – The Right Way

#297

Post by inoop »

mkdirp wrote: post #288
inoop wrote: post #283

Earlier quoted context omitted.

> That's precisely what I'm saying: The whole purpose of a major version is to indicate breaking changes. this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? I just don't understand why people accept this from their tools. Imagine if Google would just randomly change their APIs every couple of months and then stop supporting the o…

> this is what I don't get. Why would anyone in their right mind use a language ecosystem where each major version upgrade breaks their code? Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve. For the longest PHP was really great with backwards compatibility, refused to address…

> Great so let's just leave all of the legacy terribleness in it. Let's not address all the quirks and horribleness that sounded like a good idea at the time. Let's not let the language evolve.

Nobody is saying that. The golden rule of API design is do not break your customers.

The way you let a language or API evolve is by introducing a new API. For example, instead of changing the semantics of count() you might introduce len() and then try and not fuck it up this time.

Re: PHP – The Right Way

#298

Post by dncornholio »

berkes wrote: post #131
rvnx wrote: post #94

Earlier quoted context omitted.

It had a role because PHP is the most used web technology in the world.

No. In each and every of these cases the design of the language, the quality of community-code (libs) or the quality of the language was the cause. I'll admit that in all cases, the humans involved where the actual root cause, but that is silly, because it always is. What PHP lacked in all these cases, was guidance, support or limitations to direct these humans to better architecture, or guide them away from bad deci…

Don't know why i'm biting but I will.

1. MtGox could have been written poorly in any other language and it could have been hacked. We find SQL injections in every language. 2. Facebook started with PHP, still runs a lot of PHP. It's not unsafe.

Re: PHP – The Right Way

#299

Post by lotyrin »

pak9rabid wrote: post #280
hooby wrote: post #258

It's a decent website - a useful collection of information and links to additional information, that can serve as a starting point to learn more. For those who use PHP, or for those who'd like to learn to use it, this might be useful resource. The same thing can't really be said of the comments in here though. I don't see how emotionally charged debates over what is the "best" or "worst" language, help anyone. It's a…

In its early days (version 4 and below) PHP was a bit of a mess. However it got its act together with version 5, as it implemented an object model almost on par with Java's, which I thought kind of set the standard for how OOP should be done. It's just unfortunate that much of the mistakes with version 4 and below had to be kept in order to preserve backwards compatibility.

More than the design of the language itself, the culture suffered (and still suffers to a lesser degree) from the legacy of those bad designs, such that if you wanted to avoid a whole ton of awful codebases, poor practices and mediocre developers you could have easily done so by putting a language barrier between you and them and "graduating" to some other language.

Many teams and codebases these days have moved onwards and upwards toward a world where sensible design exists.

Re: PHP – The Right Way

#300

Post by simion314 »

onion2k wrote: post #255
simion314 wrote: post #192

Earlier quoted context omitted.

> Languages should provide simple primitives that frameworks and libraries build on. This had tons of disadvantages. Say CoolLang is such a language. Since is msall CoolLang has a micro standard library so has no DateTime or JSON, so you have a package manager and maybe 1 repo where 15 different JSON packages, you decide to use JSON_A but you also want to integrate with Amazon and they used JSON_B in their API and yo…

CoolLang sounds a lot like JS.

There are more languages not only JS, with small standard library and the community offers multiple packages for same thing(like more packages for json) but you install them at your own risk - though this weaknesses are promoted by Cool.lang fanboys as features.
Post reply on HN