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

321–330 of 349 posts

Re: PHP – The Right Way

#321

Post by berkes »

dncornholio wrote: post #298
berkes wrote: post #131

Earlier quoted context omitted.

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.

I've avoided, with care, the statement that PHP is unsafe. I've not even hinted at the statement that it is impossible to write good software in PHP.

PHP is not unsafe. You can write magnificent software in PHP.

But PHP makes the safe often harder than the unsafe. The community even more so. It direct newbies to write crappy software more than that it guides them to learn about architecture, maintenance, patterns. All the stuff the article we're discussing is promoting.

And yes, mtgox could have been hacked even if it was written in pure functions only (well...). What the exact reason is, is unclear. But researchers have pointed out that the sourcecode (leaked by the hackers), contained self-written elliptic curve cryptography, in PHP, which was flawed[1].

Before you comment 'writing your own cryptography is always dumb, has nothing to do with PHP', please note that 1. PHP lacked any libraries for this at that time (it still does?), 2. someone has to write these libs or bindings and 3. in this case it was written, in a language that is -and certainly back then was- unsuited to write such code in. It was not the language itself. But PHP is more than a language, it is an ecosystem. And that ecosystem has brilliant code and magnificent contributors. But is overwhelmed with crappy wordpress hacks and similar WordPress "developers". As well as, apparently, frequented by people who think it is wise to write their own crypto libraries in PHP for a Bitcoin Exchange.

[1] https://hackingdistributed.com/2014/03/01/what-did-not-happe...

Re: PHP – The Right Way

#322

Post by that_guy_iain »

inoop wrote: post #292
dotancohen wrote: post #287

Earlier quoted context omitted.

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 o…

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

Actually, no. They said they didn't believe that.

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

I think the point you need to specifically define that the JVM needs to be well tuned kinda shows you know there is a grain of truth to the fact that you dislike so much.

And really comparing performance of a compiled language to an interpreted language is kinda cheating. Compiled should be faster.

From my experience I can run a Go application with the same performance requirements as a JVM application with less resources. For example, for the same requirements I had 50mb of ram assigned to a Go docker and 250 mb assigned to the JVM. I'm sure we all agree 250MB is not so much but that adds up. Then we get on to the fact it's quite common in the real-world to see lots of apps built on the JVM needing lots of resources, sure you can say that's the devs problem and if they just did it properly it wouldn't be the case but if so many people are doing it wrong then maybe it's being the JVM makes doing it wrong so easy. (Which was PHP's problem so many years ago)

Re: PHP – The Right Way

#323

Post by ofrzeta »

Updated in January but not really up to date. It doesn't mention union types, the nullsafe operator, matching expressions and a lot of other features you can find here: https://stitcher.io/blog/new-in-php-8

Maybe not everything is "the right way" but at least the nullsafe operator is, I think.

Re: PHP – The Right Way

#324

Post by kgeist »

xigoi wrote: post #246
bowersbros wrote: post #179

Earlier quoted context omitted.

That first article is a decade old.

The article has been updated over the decade. It mentions which things have been fixed — most of them haven't.

I used to hate PHP with passion myself (having read those articles too) before I had to take on a large project which used modern practices (PHP 7+, latest Symfony) and I can say it's been a surprisingly smooth sailing so far, most of the time you use nicely designed abstractions over the core APIs provided by the framework (or its modules) and don't use built-in functions directly. The actual annoyances I notice everyday are things like inconsistent argument order in array_* functions (people prefer to use them directly), but you quickly get used to it and there's not that many of such functions in day-to-day work. What you usually do is generic stuff like defining models, writing controllers etc. and most of the time it doesn't feel much different from other enterprisey languages I've used such as C# or Java. From time to time you have to use some arcane PHP function because the framework doesn't provide it for you but there's a custom, at our company at least, to wrap such functions in nice utility classes once and forget they exist.

Re: PHP – The Right Way

#325

Post by pluc »

tzs wrote: post #259
pluc wrote: post #214

Earlier quoted context omitted.

Quoted post unavailable.

Before 2017-12-01, the documentation for count() said: > Returns the number of elements in array_or_countable. When the parameter is neither an array nor an object with implemented Countable interface, 1 will be returned. There is one exception, if array_or_countable is NULL, 0 will be returned. If the languages developers did not want programmers to use that behavior they should have said that it is undefined when t…

Do you not think languages should evolve? Do you think the count() behaviour should never have changed because at some point the documentation said this? How do you propose languages deal with evolution if not graceful deprecation? This isn't Go or Rust that have been around for a few years, this is a 30 year old language that was designed for an entirely different web than what we have today and has had to reinvent itself multiple times. Let me know when Go and Rust deal with half of the problems PHP dealt with.

Re: PHP – The Right Way

#326

Post by inoop »

that_guy_iain wrote: post #322
inoop wrote: post #292

Earlier quoted context omitted.

> 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 o…

> 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? Actually, no. They said they didn't believe that. > 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…

> the JVM needs to be well tuned

You don't need to tune it to beat the pants out of a PHP-based solution.

Honest question, have you ever owned a large-scale, low-latency service in both Java and PHP, and have you compared latency characteristics between both runtimes?

Re: PHP – The Right Way

#327

Post by that_guy_iain »

inoop wrote: post #326
that_guy_iain wrote: post #322

Earlier quoted context omitted.

> 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? Actually, no. They said they didn't believe that. > 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…

> the JVM needs to be well tuned You don't need to tune it to beat the pants out of a PHP-based solution. Honest question, have you ever owned a large-scale, low-latency service in both Java and PHP, and have you compared latency characteristics between both runtimes?

> Honest question, have you ever owned a large-scale, low-latency service in both Java and PHP, and have you compared latency characteristics between both runtimes?

No, if I've worked at a shop with a large scale low latency PHP app, they aren't not bothering their ass with Java, no need. They clearly have a highly comptent dev team who know their tools.

The only time I've dealt with Java is when companies are moving away from Java because their Java app is bloated beyond hell. They have a dev team that aren't highly comptent and think switching languages will help.

If I was dealing with the two, I would most certainly expect the Java one to handle scale better. But if I'm at lower level scale I would expect the PHP one to require less resources. Once PHP starts to scale up it can be a resource hog.

The reality is the comptency level of your dev team is the most important thing.

A think you need to remember, the JVM can scale massively well but the majority of systems don't need to scale well.

Re: PHP – The Right Way

#328

Post by [deleted] »

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…

[deleted]

Re: PHP – The Right Way

#329

Post by azangru »

9dev wrote: post #303
cardanome wrote: post #236

Earlier quoted context omitted.

Actually no. Rust will teach you. The difference is that errors do a great job and telling you what went wrong and how you can fix it. You just fix one error after another and the borrow checker will guide you to the correct solution. For example you get an error like: error[E0433]: failed to resolve: use of undeclared type `Environment` --> src/main.rs:9:19 | | let mut env = Environment::new(); | ^^^^^^^^^^^ not fou…

Hah, let me just chime in with a recent TS error that almost drove me nuts[1]: Type 'Record ' is not assignable to type 'T'. 'Record ' is assignable to the constraint of type 'T', but 'T' could be instantiated with a different subtype of constraint 'Record '. (2322) Would you have figured out that the solution to the problem was to omit the - factually correct - return type of the method? Rust is not just better at e…

> Would you have figured out that the solution to the problem was to omit the - factually correct - return type of the method?

While I would not be able to figure out the solution to this problem from the error message alone, I would gather from it that typescript is telling me here that it cannot guarantee that it will satisfy the type contract, i.e. that the function will return a thing of the same generic type T as it received. This is useful information in debugging the type declaration of the function.

Re: PHP – The Right Way

#330

Post by pas »

withinboredom wrote: post #301
kaba0 wrote: post #248

Earlier quoted context omitted.

So basically what FP languages do?

Surprising php has a lot of FP aspects.

It .. really doesn't. (Sure, probably a tiny bit more than Python.)

It's not static types FP like Haskell/Scala (or even TS), as it just recently started gaining some type safety, and while it had map/reduce call_user_func, it wasn't that big in PHP world.

It simply has/had too much mutability for it, and most PHP practice focused on trying to implement OOP ideas in it in a nice way.

Post reply on HN