dreadnip

I guess the main takeaway is that you don’t care about the quality of the generated code. The end result is all that matters.

If I ask it to “add drag & drop”, I already know in my mind what the correct code should look like, because I’ve implemented it many times in the past. LLMs just never deliver the -code- that I want. The end result might look ok and the drag & drop will work, but the code will be atrocious and on first glance I can pick out 10-20 mistakes that I’ll have to ask it to fix. And even if I ask for a fix, I’ll never get the same code quality as hand written code. And how can I push this kind of sub-par code to an employer’s repo when I know that I can (and should) write better quality code myself. This is what I’m being paid for right?

Er

> it requires endless system maintenance. Otherwise all the PHP stuff becomes vulnerable to random hacks

How so? I've seen PHP websites & apps run for 10+ years in production without updates. Even longer with a simple "sudo apt update" every few months and a "composer update" every year or so. The maintenance rate is actually very very low.

It's similar to the PHP micro-frameworks back in the day, like Silex and Lumen. Those often didn't contain more than a router, middleware, request/response objects, some type utils and a validator.

I personally think htmx augmenting a MPA approach is perfect for medium-sized apps.

PHP really took a great turn with PHP 8.

It introduced such drastic breaking changes, that probably a lot of systems which were previously serving unsafe and error-prone code to their users will be abandoned. Projects that should have been updated ages ago and served their users dangerous code.

It fixed the order of parameters in join statements.

It fixed calling static functions without declaring them as static.

It fixed adding properties dynamicly to objects.

It fixed string handling for many functions where Null was rendered as an empty string.

And these changes make PHP code more secure. There is now no way around adding more declarations to your codebase than before.

Most of these breakages had 70% votes in favour:

https://wiki.php.net/rfc/deprecate_dynamic_properties

There is a big difference between drugs like alcohol and nicotine, which are extremely addicting and something like MDMA, which isn’t.

> This is not acceptable

Why? I'm a software engineer working in an agency and I work exactly like you're describing. If I feel like going on a run, I'll mark myself as AFK and go on a run. If I feel like closing my laptop at 3 and go shopping, I'll work later in the day when I'm not busy.

I still deliver on my deadlines and contribute more to the company than most colleagues. If you ping me on my phone I'll probably reply at any given time, and I put emphasis on written communication about issues I'm handling. Ideally, I've already written down all of the information you'd want to talk to me about.

This "style" works really well for me.

Symfony is more explicit, configurable and has way less magic.

The Dharma Bums - Jack Kerouac

The Tao of Pooh - Benjamin Hoff

Both offer a fictitious and simplistic introduction to eastern philosophy. Growing up as an atheist in Western Europe, I never realized just how deep the influence of religion on our culture, traditions and history was. These books gave me a playful look at Buddhism and Taoism, right when I needed it. Shifted my entire worldview.

> Php 8 had a lot of breaking changes and upgrading it is already an arduous task.

How so? I've upgraded most of my project to PHP 8 quite easily. Which versions were you running before, and what breaking changes did you see?

> PHP as a language and ecosystem seems to be evolving backwards from a reliable, productive and accessible tool to something that is breaking callers, introduces versioning and upgrade issues.

Having 7 different methods to do string interpolation is not "productive and accessible", it's confusing and prone to abuse.

The whole "never break user land/space" axiom that the PHP core used to follow isn't healthy for the language, and I'm glad we're moving away from it.

I want PHP to grow into a more modern and stricter language, and I can understand that iterating fast and deprecating old behavior is part of that evolution.

The odds of those things being worked into php-src are very, very small. Most of the time there has been discussion on these topics on the internals mailing list, it was clear that the majority favored keeping those things in userland.

The problem with templating systems, routers, DI containers, testing frameworks, etc.. is that they are all very opinionated. There is no one way to do it, and each implementation has upsides and downsides.

On top of that, the PHP ecosystem is so mature that for each of the possible implementations of these features, there is a stable, production-ready and actively maintained library/framework. Why reinvent the wheel?

An important detail is that most of these frameworks have also built a business around their product, which means that people are being paid to work on them. How would the financial situation work if you moved all that into the core?

For me, the current situation is close to the ideal one. For example, the recent addition of fibers into the core in PHP 8.1 was a logical step to allow cooperative multi-threading. It will be used by great userland frameworks like Revolt, Amp, ReactPHP and more. The full event loop feature would be too heavy for the core.

+ Composer is so great that installing any of these packages is a breeze anyway.

He wrote some decent articles before, and he might write some good ones in the future, but this right here, this ain't it.

Unlike other "x in 2022" articles (for example https://www.ncameron.org/blog/rust-in-2022-2/), this one doesn't actually give any insight into the future of the language. Not only that, but there is no original content in it. He's simply repeating what he's been writing about for the past year. Maybe he should've called it PHP in 2021? Oh wait, he already did that (https://stitcher.io/blog/php-in-2021) and it's eerily similar to this article. If there is nothing new to write about, why write?

I'm glad you bring up the PHP Annotated Monthly blog, it's a great resource and definitely one of the blogs to follow to keep up to date with PHP.

I'm glad the community around modern PHP is thriving, but filler articles like these are getting on my nerves. Reiterating a bunch of content that has already been covered extensively on the web in the past months (and in 10+ previous posts on your own blog), slapping a misleading title on it and filling it up with call-to-action's for your own personal video/newsletter/courses isn't good content. The author had some really good articles in the past, but this reads like fluff just to fill up his blog. Quality over quantity.