Pretty much sums up how I feel about most of the big frameworks (Zend in particular, but also Symfony and CakePHP).
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 think the main issue is that alot of things just don't remain static. You choose the right tools for the job and then the moment you're finished a new set of requirements are bolted on and suddenly it's no longer the right tool for the job. So instead you start off doing the "simple" things with over powered (and hence more complicated) frameworks. Zend, symphony, cake, drupal you pick your poison in the sure knowledge that when that inevitable list of extra stuff lands on your desk you'll be able to do it.
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.
Yep, YAGNI is a great rule of thumb, but there are cases where you know that you ARE going to need it.
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.
> The problem of over-engineering isn't just related to the big PHP frameworks - the same problem exists in Python and Ruby.
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.
I know what you mean, and I realize there's more to web development than what I just wrote. Nonetheless, I think frameworks such as Zend add a level of complexity that is rarely justified. Zend fans would probably claim that doing things the "right" way in the beginning means less work when you need to maintain the app three years later. I'm not so sure. To be honest, three years from now I'd rather be maintaining a CodeIgniter app than a Zend one. I'm not a CodeIgniter fan per se, and I realize that it gets a lot of criticism for being written the "wrong" way - but the point here is that simple (and well-documented) solutions often win the day.
Frameworks are also very useful. They can provide a tested database layer that prevents SQL injection, form data validation and escaping, straight-forward MVC structure, and a library of common functions that are well tested and help developers avoid common mistakes.
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.
Sure - but if you compare, say, Zend with Laravel, you'll see that the former is hugely complex compared to the latter - and what I'm saying is that the complexity doesn't seem to make the code more maintainable later on - possibly quite the opposite.
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.
Maybe most HN startups are that, but web development _at it's core_ certainly isn't limited to CRUD apps.
The only flaw I can see is that the string literal '1' should have been declared as a const somewhere, preferably in another unrelated library, and called something like 'UNITY_VALUE'.
See, this is why I'm tired of freelancers and architecture astronauts at companies who just like to make things more complicated.
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.
Reminds me of something I wrote a few months ago on how to detect negative numbers: http://stackoverflow.com/a/11910993/1329367 but obviously the one above has much more value add and follows better design patterns.
I opened a few bugs to help get this library in a more usable state. I'd really love to see a SOAP API on this as well as result templating, a request router, and a controller.
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.
It reminds me of a Zend Framework project I'm maintaining, where the previous dev apparently tried to apply any OOP pattern they've ever head about.
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.
Welcome to the enterprise world. If you are already working for a typically huge enterprise, you would have realized that this kind of coding (Engineering) is just another day at the office and people actually get paid (more) to over-engineer! Infact, anything done to reduce complexity is actually frowned upon, or will even get you labelled as an ignorant employee.
I'm not familiar with the PHP ecosystem. Is the author making fun something other than obvious over-engineering? Does he or she feel like that's a problem in the PHP ecosystem?
I'm criticizing, because it's funny. I'm just trying to figure out if theres some wisdom being conveyed that I'm missing.
I think he is mocking the general pattern of over-engineering and PHP just happens to be the language he wrote this in.
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 ;)
Don't you think that, when it comes to OOP features, PHP recklessly introduced lots of Javaisms which lose lot of sense when applied to a dynamically typed language? I believe the author had exactly that in mind.
Yeah ... Take a look at Drupal 8 and you'll start to see this creeping in. I overheard Dries saying he wants to see Java style comments and wants to be more like Java.
> Does he or she feel like that's a problem in the PHP ecosystem?
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.
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.
The addition operator takes a collection of numbers, and add the first two? Given the lack of documentation, I find this extremely misleading and I couldn't recommend this library.
This is so funny. The author's description is great on github, really fooling you at times. Even if this isn't intended as a joke, the dedication to doing something fun to prove a point got me thinking about over engineering design patterns too.
The library supports adding other numbers than 1 and 1. Your use case of adding 2 to 1 is supported. As are multi-digit numbers. As are negative numbers.
there's a lot of stuff in PHP that bothers me...mostly consistency of function arg orders and function naming. but this has to be the one that really drives me up the wall. i cannot believe they choose to maintain this broken implementation because it's defined improperly in the spec. just yuck.
I'm not sure, but probably historical reasons like much else 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.
I think this has potential to scale, but you'd probably need to throw in more servers if you plan to handle more than few hundreds of additions per second.
Yes this is a good joke until you realize there is no other way to get some level of type safety in PHP other than adding a bunch of unnecessary classes.
That's like saying the only way you can get your car to remain buoyant over water is attaching a huge flotation rig to it and even then it won't be as fast as driving on the road
Strong typing and dynamic typing are orthogonal. You can have the former and ignore the latter - see Python - and you can completely forget about both - see PHP.
Negative numbers are supported. But if you want a clean solution, implementing a SubtractionOperator is easy enough. Just implement the OperatorInterface.
while i get the joke , i'm sorry , but serious PHP development means bloated frameworks. You cant avoid it.
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.
>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.
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.
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.