A look at modern PHP • Hacker News Board

Re: A look at modern PHP

#431

Post by MrPatan » Tue, May 05, 2020, 6:06 PM UTC

Supermancho wrote: post #419

ragnese wrote: post #405

Earlier quoted context omitted.

It takes 5 seconds on Google to find a myriad complaints about weird, unexpected, and downright incorrect things that PHP does. That wasn't the point of my reply. The point was that language choice CAN affect productivity. And having a bunch of gotchas is something that will negatively affect productivity. I simply gave the first example that popped into my head that actually tripped me up.

Unit tests would have caught this, if you wrote them.

>Unit tests would have caught this, if you wrote them.

If I hadn't considered string-number-keys in my code, I would also have forgotten about them in my unit tests. Maybe you're different.

Re: A look at modern PHP

#432

Post by joeldg » Tue, May 05, 2020, 6:06 PM UTC

fatbird wrote: post #321

techopoly wrote: post #302

Earlier quoted context omitted.

I wonder how many developers hate PHP because one is just supposed to hate PHP. I'm sure there are many with well-thought-out reasoning though, like seen in this thread. It's useful to keep an open mind about things though. I'm probably more a PHP fan, but I can't say that I'm a huge fan of its programming style. It's much more enjoyable to me to churn out applications in .NET or in Ruby, but it's hard to argue with…

I think you're missing a third group of PHP haters that's actually a majority: those who've used PHP, sometimes extensively, and built up a backlog of "this is stupid" bits in their head about it. They don't have deeply reflective reasons or a strong theoretical basis for hating it, they've just suffered with it for a good while, found some better alternative, and are now sceptical that any amount of improvement will…

oh man.. I hate js so much... (personal reasons, I have not extended that to js programmers)

it's such a mess right now.

Re: A look at modern PHP

#433

Post by wtetzner » Tue, May 05, 2020, 6:07 PM UTC

Supermancho wrote: post #419

ragnese wrote: post #405

Earlier quoted context omitted.

It takes 5 seconds on Google to find a myriad complaints about weird, unexpected, and downright incorrect things that PHP does. That wasn't the point of my reply. The point was that language choice CAN affect productivity. And having a bunch of gotchas is something that will negatively affect productivity. I simply gave the first example that popped into my head that actually tripped me up.

Unit tests would have caught this, if you wrote them.

Assuming you thought to test using a string that's all digits. You have to know about PHP's brokenness to even think to check that. In a sane language, it doesn't matter what the contents of the strings are, they're just strings.

Re: A look at modern PHP

#434

Post by nucleardog » Tue, May 05, 2020, 6:08 PM UTC

AegirLeet wrote: post #175

Ygg2 wrote: post #164

Earlier quoted context omitted.

So I take it all the things in this article ( https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ ) are no longer relevant? For example "foo"==TRUE, "foo"==0 and TRUE !=0 are logically consistent now? Or json_encode no longer returns null for invalid input?

Some of it is still true, some of it isn't true anymore and some of it simply isn't very relevant. Comparison still isn't transitive. Not very relevant in the real world because you simply don't use "==" unless you know what you're doing. json_decode still returns null on invalid input, so you either have to use the JSON_THROW_ON_ERROR option to make it throw an exception instead or use json_last_error(). Both are un…

And for many of us, these 25 year old warts are a benefit...

Rather than just "fixing" json_decode and breaking backwards compatibility, old code still works.

The business doesn't care about the new shiny. When someone pays to have a simple site developed, they don't want to be paying a contractor in a year to have a bunch of stuff updated so the language it's written in is "more correct" or whatever the overriding reason is to change this. That is completely tangential to what they care about.

I recently went through "modernizing" a 15 year old, 1.93 million line php 5.x app.

We put in a shim for the mysql_ extension as it had been depreciated with 7.x, and fixed up maybe a dozen places where it was doing something exceptionally wacky and then tested like crazy and sent it out the door. Works fine.

The business doesn't care that the code is shit. They care that it makes them a million dollars a month and no matter how gross it is there's no defensible rationale as to why they should stop doing things that make them more money for the next 2-3 years while a team goes through and rebuilds the entire thing to be "more correct".

Something like pyenv/nvm/etc doesn't exist for PHP. You can just install the latest version and with very few exceptions whatever code/library/etc you find will just work. There's a lot more value in that in the real world than "fixing" json_decode.

Re: A look at modern PHP

#435

Post by 72deluxe » Tue, May 05, 2020, 6:10 PM UTC

mrkeen wrote: post #142

72deluxe wrote: post #92

I still can't see how it can be "mature" if it offers an iterable returnable type like in the article example yet doesn't indicate the type of the object it is returning! It has type hints for function parameters and return types but not for arrays. This makes it useless to me. I know everybody will say "just add comments so an IDE can interpret it" but this should be a feature of the language. Just adding comments t…

I still can't see how C++ can be "mature" if you have to indicate the type of object it is returning! I know everybody will say "just add a type declaration so the compiler can interpret it" but this should be a feature of the language. Just adding type declarations to hint to a compiler is not a real solution.

But it's not a hint to the compiler. It's stating a fact to the compiler. It'll stop compilation.

If I have a basket of fruit, all the items in that basket container are fruit. I can't put anything other than fruit in it. It's a basket of fruit. I know how to interact with the fruit due to its type.

If I am able to put dung into my basket, my fruit is spoiled and I cannot assume how to interact with the objects in the basket.

This is a PHP array without types at the array level. I can put dung into it and have no idea how to interact with it.

Or are you saying that a container of any type is perfectly acceptable? Did the other languages (C++, C#, Java) get it wrong?

eg. on this line can you tell me what the array holds and how I interact with it? What does array $operations hold?

https://github.com/magento/magento2/blob/420a8b6209a4e62ede9...

Re: A look at modern PHP

#436

Post by fernandotakai » Tue, May 05, 2020, 6:15 PM UTC

mywittyname wrote: post #336

AegirLeet wrote: post #232

Earlier quoted context omitted.

RoR and Django are probably the closest (Laravel was inspired by RoR). Still, I don't think they support all those features. Like I can't find any official RoR support for payments, full text search, encryption, pagination, scheduled tasks or building CLI commands. With Django, full text search seems limited. It supports PostgreSQL, but I couldn't find first-party integration for Algolia, Solr, Elasticsearch etc. or…

Python has an Elasticsearch API available as a package, which is probably why it's not packaged in with Django.

also, wtf payment integration? if i need payment integration, there are myriad of libraries to chose. i don't need my web framework to decide that for me.

Re: A look at modern PHP

#437

Post by bigtunacan » Tue, May 05, 2020, 6:16 PM UTC

rgbrenner wrote: post #334

lucideer wrote: post #319

Earlier quoted context omitted.

Node developer here, but... two notes about your comment concern me a little. 1. "I can't think of a single reason to use PHP over Node" this is fine but can you think of a single reason to use Node over PHP. Is adoption cost the only one? 2. "you might be a bit behind the curve" while the original commenter was talking about PHP being "modern" and dimissing talk of it existing because of legacies, criticising someon…

1. Off the top of my head: SSR of JS apps, performance, better security track record. It also fits in the modern architecture better: you can certainly write a rest API in PHP, but that's not typically what you would use PHP for... and if you're going to write a react, vue, etc app, you're likely writing an api also. 2. This is not my attitude at all. I've been programming since the 90s.. In the past I've maintained…

"you can certainly write a rest API in PHP, but that's not typically what you would use PHP for..."

This just shows a lack of understanding of modern PHP. REST APIs are dead simple in PHP using Slim, Lumen, or Symfony REST.

Re: A look at modern PHP

#438

Post by ragnese » Tue, May 05, 2020, 6:18 PM UTC

macinjosh wrote: post #308

ragnese wrote: post #262

Earlier quoted context omitted.

I'm a PHP "hater", so take this for what it's worth. You are very close to implying that the language doesn't matter if you can hire developers and there are a lot of good packages in the ecosystem. Having worked on several PHP projects (Most being version 7.0+ and zero of them being older than 5.3), the languages is STILL full of gotchas, and it's a huge drag on productivity. I assert that this DOES matter. Even bas…

> if you try to use a string as a key, but it is a string of digits. It will automagically(sic) convert your string to an int and totally F-up your dictionary I've been a PHP programmer for over 15 years and I cannot think of a single time this has been an actual problem. It sounds like you were embarrassed by a bug in your code and have just decided to blame it on the tools.

You remember every bug you've written in 15 years?

I'm not that talented. I write bugs all the time. Most of the time, tests save me.

You can size me up as just childishly trying to divert blame when I made a mistake, but you're missing out by doing so.

Re: A look at modern PHP

#439

Post by Washuu » Tue, May 05, 2020, 6:23 PM UTC

ragnese wrote: post #402

jrumbut wrote: post #380

Earlier quoted context omitted.

My guess is that the numeric indexing thing happens a lot but it's definitely rare for it to cause a visible problem and even rarer to be identified as the cause since it is unexpected. I've been bitten by it and also stuff like 800=="8E2". I've never been able to make an adequate defense of PHP, yet also have never seen another language match its success rate of getting useful software into the hands of users. I hav…

I'm in a similar boat. I've decided that whatever it is that makes PHP successful must be exactly the same thing that has made JavaScript successful. It's going to sound extremely condescending, but here it is, anyway: I believe that the majority of people who defend PHP (and JavaScript) are people who have ever only written code in Java (especially <=1.6), JavaScript, and PHP. Maybe C for fun or in college. In light…

I have done PHP for 15+ years. I also use Javascript.

However, I also use C/C++(Mostly low level embedded), C#, and Golang regularly.

If I was given the choice of what language(excluding C/C++) to launch a new web site I would still choose PHP with `strict_types=1` enabled.

Re: A look at modern PHP

#440

Post by anonyfox » Tue, May 05, 2020, 6:24 PM UTC

Many emotional language bashing comments here, and everything between „php is dead“ to „php is awesome now“.

Personally I liked that php has an ultra low entrance bar: shared hosting for $2, ftp deployment, no advanced syntax to understand. When starting work in teams instead of solo and coding nontrivial business rules, this ease of doing died for me. Moved on.

Many years of JavaScript, doing nodejs since 0.4, it was just like having superpowers and doing isomorphic things. Mixing things every other month with coffeescript, babel, typescript and trying a different framework for every new project. What once felt refreshing is now just exhausting and JS projects tends to end in rewrite loops.

Before/Inbetween/After there were many languages, from C at university, to C#, Ruby, Go, ... . Mostly the tech didn‘t change much, but over time emotions change for me. Longest streak of love had ruby, shortest had Go (just a few weeks before it became disgusting for me). I believe thats Personal and different for everyone.

After all my reflections I finally settled with just two choices of techstacks: Elixir/Phoenix for all things Web and Rust for everything else.

Writing highlevel businesscode , interactive exploration of things, CRUD things and realtime frontends in Phoenix is a breeze. But this ease of use has tradeoffs as always, I always feel that this dynamic code is somewhat „fluffy“, but ist seems that this is a key to prototype and ship things rapidly.

When i do want to do things that feel more „substantial“/„meaningful“ than just assembling yet another web product, I Switch to Rust. Producing a statically linked, crosscompiled binary that is „proven“ to work after discussing with the compiler is deeply satisfying for me. Unlike those „fluff“ / yet-another-web-product work.

Full Circle to PHP: awesome to see static typing available now! But this alone doesn’t make it feel so heavily baremetal for me, still fluffy with types bolted on. It is the fastest php ever, but still in the ballpark of scripting languages. It has mature, productive frameworks, but Phoenix feels superior and leading the way (next rails? Dunno), so why bother if php plays catch up to moving targets?

Software Development has become somewhat like fashion now, and PHP looks like those jeans jackets people had in east germany. Not inherently bad, fully functional for its purpose, but once you experience the taste of freedom in the western world you insist to have „real“ things. Best metaphor I can think of, but as stated: most discussions here are highly emotional, and it’s hard to put that in words.