Live data from Hacker News

PHP – The Right Way

phptherightway.com

201–210 of 349 posts

Re: PHP – The Right Way

#201
post #65

Earlier quoted context omitted.

> Citation needed. I really like Django as an opinionated framework. I have also used Flask, Falcon, and FastAPI, all with good results in their own niche. I also like Play and Scala and Spring Boot with Java. > For folks not wishing to switch frameworks and tooling every year, you can get a lot done with PHP. You can also get a lot done with wood and nails, but that doesn't mean it's the best tool for all kind of jo…

Comparing PHP to using wood and nails feels misguided. PHP is a web framework, which makes it easy to handle writing web applications. It's more like using Python for web stuff is wood and nails, while using PHP is using wood and a nailgun when you need to stitch planks together (or something like that). PHP is made for the web, and you can tell by the specialization of the API interface it offers, which ships with m…

The nail-gun is a surprisingly good analogy. There are lots of other things you can do with a hammer, from hammering nails, to shaping metals, to removing nails, to getting things unstuck. With a nail-gun you are kind of limited on what you can do.

Re: PHP – The Right Way

#202

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…

PHP doesn't guarantee backward compatibility between minor version. It is the way things are in PHP since 5.x, when Semver wasn't even a thing.

Re: PHP – The Right Way

#203
post #149
post #137

Earlier quoted context omitted.

It looks like your projects employed PHP poorly. PHP has been great for my company and my developers. We have never had to face such grave consequences because of it, and we've employed it in companies generating millions of $ of revenue. I will pick it over any other interpreted language.

Certainly. One mistake was that PHP was chosen, when it really was unfit for the task at hand. Another one was that CMSes like WP or Drupal were shoehorned into projects that were really unfit for them. etc. But also being unable to upgrade underlying PHP versions due to breaking changes, or just p*ss-poor, bug-ridden PEAR packages. As well as the language design prohibiting proper TDD, isolation, etc. I explicitly s…

> Another one was that CMSes like WP or Drupal were shoehorned into projects that were really unfit for them.

I think this hits closer to the mark than the PHP blame. PHP is just a tool, WP or Drupal are very large codebases that each have their own inherent problems that you are not going to code your way around.

FWIW I've used PHP for a decade and a half and it never let me down.

Re: PHP – The Right Way

#204
I'm trying to learn https://haxe.org , so that if some target language does not work, I could use some other target language. Currently I have hard time updating to newer version of Node.js, dependencies etc. I tried to code something with PHP 8.1 directly, but I presume any following update could change syntax etc.

Re: PHP – The Right Way

#205
post #186

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.

There is one aspect where it wins hands down that trumps almost every other concern that you might have: availability of developers. This is a hard problem to solve.

Re: PHP – The Right Way

#206

Earlier quoted context omitted.

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

Do these dependencies actually matter when you deploy or are they just used for the actual compiling?

If they are required for the compile and someone manages to get something malicious into them, they can certainly affect the produced/deployed artifact.

See Ken Thompson, Reflections on Trusting Trust, 1984 https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_Ref...

Re: PHP – The Right Way

#207

Earlier quoted context omitted.

> The reason why people now care about PHP is that, decades ago they thought PHP would the right way to develop projects, now they are stuck I worked on many greenfield projects in recent year where the conscious choice was made to use PHP. For the majority of projects NOT using PHP is basically throwing money in the trash. Best deployment story. Great ecosystem. > Decision are made based on "copying" other languages…

> I worked on many greenfield projects in recent year where the conscious choice was made to use PHP. What kind of greenfield projects were they, and who was making those conscious choices? Without context it's just non-sense. > For the majority of projects NOT using PHP is basically throwing money in the trash. Best deployment story. Great ecosystem. What other technologies have you used in your experience, that cam…

> What kind of greenfield projects were they, and who was making those conscious choices? Without context it's just non-sense.

B2B shop, Marketplace, lots typical CRUD stuff. I don't think there is much of a pattern.

Developers wanted to use PHP. Though of course here in Germany PHP is much more popular than in the states.

> What other technologies have you used in your experience, that came to conclusion?

For server-side stuff:

Ruby, Python, JS/TS, Squeak/smalltalk (yes actually in production)

Ruby used to have some productivity advantages because of Rails but these day, as PHP frameworks have caught up, I see many shops that did both PHP and Ruby going back to PHP.

> Name features PHP avoided while copying.

Those that PHP does not have? Not sure how to make a negative list.

Re: PHP – The Right Way

#208

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…

https://getrector.org/

Re: PHP – The Right Way

#209

Earlier quoted context omitted.

> not only integers and floats, but also strings, lists and dictionaries as mutable value types (copy-on-write) Lists and dictionaries are also mutable in Python. Strings are not. With CoW, are your referring to garbage collection? (value that is no longer assigned to a name will eventually be purged). That would be independent of (im)mutability, so I'm not sure I understand.

With copy-on-write: $a = ['a']; $b = $a; $a and $b both point to the exact same bit of memory. Thus passing an array between functions is zero-cost. When you do: $b[] = 'b'; // append 'b' a new array is allocated, the old data copied to it, and 'b' appended to it (basically, but IIRC, it is a bit more optimized than that).

[deleted]

Re: PHP – The Right Way

#210

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…

I don't think that having two different count()s with different edge-case behavior is the way it should've been improved. If someone used the method incorrectly in the past it's part their fault for writing it incorrectly and part PHP's that it didn't fail (and "fail" is also kind of a stretch since the behavior was described in the docs IIRC).
Post reply on HN