Live data from Hacker News

PHP – The Right Way

phptherightway.com

211–220 of 349 posts

Re: PHP – The Right Way

#211

Earlier quoted context omitted.

I was curious about this rant since I'm maintaning a number of PHP projects and I haven't had any issues with "count". In the Changelog section of the "count" docs at https://www.php.net/manual/en/function.count.php we find: > 7.2.0 - count() will now yield a warning on invalid countable types passed to the value parameter. So in 7.2.0 they started raising a warning in cases where the application was doing a stupid t…

> In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Breaking changes (at runtime no less) are the worst way to improve any language. They should have created a new count method if they wanted to change behavior in a breaking way. Forcing millions of developers to comb through their code just because some designer doesn't like the way someo…

Does PHP say it follows SemVer? I don't know as I don't use it but Python doesn't.

Re: PHP – The Right Way

#212
post #67
post #60

Earlier quoted context omitted.

I, for one, would chose PHP8 over Javascript all day, every day. And there seem to be millions like me.

Well... I wouldn't recommend JavaScript. TypeScript is much nicer and removes a lot of the JS pitfalls.

TypeScript is nice, the nodejs community is not. It is a shame that such a nice language as TypeScript is stuck in such horrible community.

Re: PHP – The Right Way

#213

Earlier quoted context omitted.

I was curious about this rant since I'm maintaning a number of PHP projects and I haven't had any issues with "count". In the Changelog section of the "count" docs at https://www.php.net/manual/en/function.count.php we find: > 7.2.0 - count() will now yield a warning on invalid countable types passed to the value parameter. So in 7.2.0 they started raising a warning in cases where the application was doing a stupid t…

> In the next major version, they turned the warning into an error. Pretty understandable way to improve the language I would say. Breaking changes (at runtime no less) are the worst way to improve any language. They should have created a new count method if they wanted to change behavior in a breaking way. Forcing millions of developers to comb through their code just because some designer doesn't like the way someo…

If you upgrade without proper testing you are the only one to blame. Seems like that blaming PHP is just an excuse for poorly managing language upgrades.

PHP has one of the best track records for retrocompatibility, this is really the worst thing you could pick to blame PHP for something.

Re: PHP – The Right Way

#214

A language that changes the semantics of functions between minor versions has no "right way". "count()"less examples of crap. I have currently two weeks of code migration behind me because code running correctly on 7.0 fails on 7.3 -- while I see the reason for change was necessary I also see the hopelessness of rebuilding a flawed house with a fundament build on a pile of manure. And the good news given to me by a c…

I was curious about this rant since I'm maintaning a number of PHP projects and I haven't had any issues with "count". In the Changelog section of the "count" docs at https://www.php.net/manual/en/function.count.php we find: > 7.2.0 - count() will now yield a warning on invalid countable types passed to the value parameter. So in 7.2.0 they started raising a warning in cases where the application was doing a stupid t…

No post body was provided.

Re: PHP – The Right Way

#215

Earlier quoted context omitted.

> Typescript ... has cryptic error messages. This is very strange to hear. Typescript error messages will show you a type mismatch and explain why one type isn't compatible with the other. What's an example of a cryptic typescript error message?

Have you ever used Elm or Rust? Maybe you expectation of how decent error messages should look like is just lower. The problem is that the type system in TS can get crazy complex and has many uncommon features like structural typing. You need to have a really good mental model of how TS works to be able to make sense of what TS tries to tell you.

> You need to have a really good mental model of how TS works to be able to make sense of what TS tries to tell you.

Won't this sentiment hold true for Rust as well? You need to have a good mental model of how Rust works, with all its borrowings and lifetimes, to understand what its errors are trying to tell you, and especially how to fix the problem?

Re: PHP – The Right Way

#216
post #212
post #67

Earlier quoted context omitted.

Well... I wouldn't recommend JavaScript. TypeScript is much nicer and removes a lot of the JS pitfalls.

TypeScript is nice, the nodejs community is not. It is a shame that such a nice language as TypeScript is stuck in such horrible community.

Can you give some examples of why the nodejs community is not nice?

Re: PHP – The Right Way

#217
post #67

Earlier quoted context omitted.

Well... I wouldn't recommend JavaScript. TypeScript is much nicer and removes a lot of the JS pitfalls.

And pulling ~67 dev dependencies just to be able to transpile TS to JS? No thanks. https://www.npmjs.com/package/typescript

This comment shows perfectly that people has no clue what they're talking about, these dev dependencies will never be pulled into your project, they're just for typescript's own development.

Re: PHP – The Right Way

#218
post #184

Earlier quoted context omitted.

I'm not the OP, but I have plenty of comparative experience working with Python and JS on the backend (node) and I find PHP to be a very decent option compared to those two. PHP has an amazing infrastructure of third-party libraries/packages around it, particularly if you're using PHP for web development. In comparison, Python simply does not have the same quality of framework for web like Symfony or Laravel. Django…

So compared to JS and $DYNAMICALLY_TYPED_LANG, PHP is "decent these days". These languages all suffer from very similar problems. Compare to C#/MVC.net, Kotlin/whatever, Go, Rust to get something noteworthy.

At least for Go and Rust, they have a much steeper learning curve. If you are a startup with limited funds you are not able to target engineers workings with those languages.

If it's just a matter of speed, PHP already is good enough for the great majority of cases. The bottleneck is the data layer, usually. If your problem is being faster than the latest versions of PHP can achieve, you can certainly look for Go/Kotlin/Rust. But if you start your startup optimizing trying to shave off some milliseconds out of a response time you are setting yourself for failure.

And in any case, languages like Go have their own part of quirkiness around the language or tooling (should we talk about how dependencies are managed in Go? that's ages behind npm/composer). Or shall we talk about the lack of exceptions, but then people regularly ask for them?

Re: PHP – The Right Way

#219
post #212

Earlier quoted context omitted.

TypeScript is nice, the nodejs community is not. It is a shame that such a nice language as TypeScript is stuck in such horrible community.

Can you give some examples of why the nodejs community is not nice?

Perhaps ecosystem is a better word than community.

How npm works and the policies by company behind it.

PHP composer is much more sane than npm.

And all the different package controversies like leftpad.

Lots of bogus and malware packages.

Re: PHP – The Right Way

#220

Earlier quoted context omitted.

> I don't think there's a good reason to design a language specifically for web projects. If that's how PHP works these days (I haven't used PHP in a decade or so), I'd suggest that might be a bad thing. It's very rigid, and if the language gets anything wrong that compromises the design of every project that uses it. Languages should provide simple primitives that frameworks and libraries build on. That has always b…

> With PHP, it's literally one-line of code. With Python and any of the Python frameworks, it's two lines. And one is most likely not explicitly bringing in HTTP request parsing, but just connecting all the plumbing. > With PHP, it's literally one-line of code. In that narrow domain, few things are simpler than Cold Fusion. If you go further, the Zope application server offers lots of nice ways to iterate over datase…

> With Python and any of the Python frameworks, it's two lines. And one is most likely not explicitly bringing in HTTP request parsing, but just connecting all the plumbing.

Yes, but in the case of PHP, PHP itself is the plumbing. You literally write `$_POST['param-name']` and you have the data. Using Python would require you to either write a bunch of logic enough to abstract it to have it like PHP, or require a 3rd-party library (or framework) for it to be one line.

> You seriously need to play more with other languages. I suggest you learn one or more of the "weird" ones, such as APL (avoid the ASCII notation, dig deep into the symbols), Erlang, or Lisp. It'll bring in a lot of perspective for you.

I'm saying this as someone who does play with lots of languages almost every day and my day-job is writing Clojure code (for both backend and frontend work). I might have missed a "As most of every new language" part in my previous statement. I'm not saying all languages are C-like, they're obviously not. But most of the popular new language do have a syntax-heritage stemming back to C (compared to languages with S-expressions), like Rust, TypeScript/JavaScript, Java, C++, C#, Python, Ruby, Golang and more, and they are mostly focusing on being general purpose useful.

Btw, I don't think lisp-like languages are the weird ones, the C-like languages are the ones that are weird. You should play around with more languages and you'll see why :)

Post reply on HN