It's not hard to write structured elegant php, that is horseshit. Please look at code for symfony or laravel. Hell, my annoyance with writing good code in PHP is that it ends up looking like Java, which begs the question, why not just do it in java.

https://github.com/symfony/symfony/tree/master/src/Symfony

or you can look at simpler sample codes I wrote for a class in design patterns with php

https://github.com/segmond/phpThingz

Symfony is the worst thing that could've happened to PHP. Dependency injection with varying degrees of XML/YAML madness everywhere. It's terribly slow and pretty much unusable w/o several caching layers in front. I can honestly say that I hate this framework with a passion, and the language too. PHP's core and a big part of the community is copying features and methodologies from Java, but they will never get close to its performance, nor its functionalities. I left the ecosystem when PHP 5.1 was around... I left for good.

This! Symfony is so wrong, i actually can't believe it. First version was kind of rails, replacing all that ruby awesomeness with PHP madness. Newer Versions suddenly want to be like Java only 1000times slower.

I won't say it's the worse thing, it did bring some good and really help drive plenty of new projects towards being OOP. I'm no fan of it either! My point is that the code is structured! Now is the framework architecture good? Whoops, that's another discussion, and I can't likewise stand the layering upon layering of components and configuration nightmare.

I think that Symfony is SpringMVC for poor, and slower, and crappier.

Your right, its not hard, but it is on the scale of how easy it is to write bad php.

I disagree. Namespaces help hugely, as do Traits, etc. It used to be difficult back in the pre 5.4 days, but we have come a long way since then.

Older projects will suffer till they're brought up to spec, true.

I don't think what you say really invalidates his point though. Namespaces and traits might help a lot, but that still doesn't make them used wide spread or introduced them to the overwhelming amount of terrible legacy code bases that have no namespaces and untested functions that are hundreds of lines long. You can write bad code in any language, but PHP used to be a much worse language and many developers got socialized with that. When you are leaning PHP it's easy to pick up bad habits because the code base tut are using is likely full of them. You are likely to look at code examples using old versions of PHP that don't teach you good practices. That of course doesn't mean you can't error awesome code in PHP it just means it's easy to write bad code.

In which ways do Traits of all things help write good, disciplined code bases?

I think traits, and their Java equivalent, are OK to touch up legacy APIs (as they did with the Java collections API) but I have found no good place to stick them in a new project.

Not to say PHP hasn't been introducing functionality for writing good, stable code bases (type hinting in function signatures, namespaces, better garbage collection, an actual AST — as an aside: how ON EARTH did they do without an AST pre-PHP7?) but traits don't strike me as the feature to think of when designing a new code base.

They're not extendable, they're not overridable, they're monolithic, and classes expose their implementation details to them, which makes traits super fragile.

They emitted oplines to the opcode array directly from the parse production.