The problem of over-engineering isn't just related to the big PHP frameworks - the same problem exists in Python and Ruby.
At its core, web development is about taking some user input, validating it, throwing it in a database, and displaying it again (perhaps slightly modified) to users. That's a fairly simple concept, and frameworks should reflect that.
I've seen some horrible cases where simple blogs done in wordpress were incrementally extended to the point where they're absolutely unmaintainable, un-updatable monsters.
The marketing manager who says today "I just want a blog" IS going to come back next week and say "I want to a white paper on the blog, for which people have to register, and then it automatically subscribes them to a newsletter".
After enough feature requests, you've built yourself a crap framework anyway. At least, by starting with a decent framework, the foundation of your code is solid.
OTOH, the "complexity" may also be "configurability" or "pluggability" with missing shortcuts. And quite often the "simple" version ends up being insufficient when one needs to tweak something: http://lucumr.pocoo.org/2013/2/13/moar-classes/
> That's a fairly simple concept
When going for pithy statements and omitting most of the actual issues, even encryption, clustering or networking "[are] fairly simple concepts". Which effectively they're not.
Ideally, a framework would have some basic elements and then additional components that can be included if required by a project but aren't core to the framework.
Maybe most HN startups are that, but web development _at it's core_ certainly isn't limited to CRUD apps.
I'm criticizing, because it's funny. I'm just trying to figure out if theres some wisdom being conveyed that I'm missing.
At least PHP is not a language known for massive over-engineering. Usually people associate the exact contrary with PHP.
But there is indeed a recent trend towards better object oriented designs in PHP and with it comes also more over-engineered code. But I have yet to see any Java-style absurdity. Maybe we'll still get to that ;)
Then you probably haven't tried Zend Framework ;)
Well, I can't talk for the author, but there is some over-egineering going on in the ecosystem, that's undeniable. I think that since the reputation of the language is low, there's this need to make sure the code doesn't look amateur, which ultimately drives overusing classes and OOP design patterns for the sake of using them.
I'm pretty sure there's already one in PHP.
Though, I'm not a real fan of reading other people's nested ternary ops, because if you're going that deep, just write an if/then in whatever language you're using? It will keep you under 80 chars which is a polite way to go.
UNITY_VALUE? Seriously? The agile approach would be to contact the customer, ask them what kind of user story they need to interact with the number 1, e.g. "As an admin, I want to interact with the number that is the square root of 1, which is also the product of i^4, and the multiplicative identity." There may be some back and forth on this, since regular users (not just admins) will want to work with the number prescribed above.
Then, you need to draw up a quick prototype. We don't need any crap like UNITY_VALUE polluting our beautiful agile code. Instead we'll declare a constant called ONE somewhere. (It doesn't matter where you put it, since we'll probably just Martin Fowler that code anyway in 10 weeks--actually, make that 2.)
Then you go back to the customer, show them the prototype. In my opinion, it helps to show them Euler's identity or the multiplicative identity just to assure them it works, in case they doubt it. (They probably will doubt it, since all this agile process stuff looks like automagic to the unenlightened morons we call customers.)
Then move on. Done. Bam. No need for this UNITY_VALUE junk. No additional libraries. Agile magic.
Relevant: http://me.veekun.com/blog/2013/03/03/the-controller-pattern-... (by the same dude who wrote "PHP: A Fractal of Bad Design", no less)
Also, in what version could we expect ability to handle 2 digit (or more!) numbers?
As you can see, the library is quite advanced.
Frameworks code looks ugly because PHP looks ugly . But has anybody seen Rails source code ?Django's ? or even Sinatra's ? it is bloated too, but because Ruby and Python a well designed , when using them , you dont feel they are bloated.
That's why you end up ( in PHP ) writing yaml config files for DI, ORM , etc more than actual PHP.
If php looked more like Ruby or Python , using symfony 2 or ZF 2 would be less painfull.
Now let's consider something else. in Python you have WSGI , Ruby Rake ,etc ... which are really good stuff , universal in the way you plug into them to write your own framework.
Up until now, PHP devs felt they did not really need it. But as the PSR effort improves , we need frameworks to implement the same http kernels so we can plug any middleware no matter what the lib is , that's very important. You cant use raw PHP anymore. You need middleware you can use ACCROSS frameworks.
So should php devs use frameworks ? yes. just like Ruby , Python devs dont do raw CGI programming. Should i use guzzle instead of CURL ? yes because it has a beautifull and fluent API , and CURL is just plain ugly. Should i use Silex/Slim/Laravel instead of raw PHP ? yes because your application will scale with these simple frameworks. Writing raw PHP without PSR-0 autoloading , and no framework doesnt scale , period.
PHP has a real problem. I admit. It needs a real deep , breaking redesign, a clear separation between the core and libraries , and fat trimming. But framework designers did a great job trying to correct its flaws and making PHP development bearable.
This is great news - it means PHP is going down the same route that very nearly lead Java to its death and still makes it the laughing-stock of the Dev world. PHP does not have this much traction with enterprisey enterprises, so following Java here probably means PHP is heading for a painful and ugly end.
"Good news, everyone" - Prof. Farnthworth
It may also be useful to include a message queue (RabitMQ / SQS are good candidates) implemented using the pub/sub model to allow arbitrary scaling of the compute nodes.
I have some other ideas about something like JMX / MBeans here to allow arbitrary instrumentation of methods. This would provide more flexibility than the benchmarking module already included.
To get anything from the db, one needs to get a "service locator" (just a dumb global object but with a cooler name) that will parse a namespace and returns a repository that will call a mapper, which in turn will instantiate an entity, which somewhere deeps in the Zend Framework is going to run an SQL query (going through dozens of classes, just to make stack-traces more readable...) and, maybe, if I'm lucky, I'll actually get some usable data back.
Of course, adding a new table is just as much fun - dozens of modules, controllers, repositories, mappers and so on to create, and just as many configuration files to update. And, of course, if something's not quite right, good luck getting any sensible error from the framework.
And I hope that after all the types of fad programming (that work almost as good as the fad diets) we will get to the "common sense programming" - use the proper tools and scale for the problem and don't try to fit the problem in your tools and frameworks.
This made my day.
