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.
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.
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.
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
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.
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.
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.
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.
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.
Negative numbers are supported. But if you want a clean solution, implementing a SubtractionOperator is easy enough. Just implement the OperatorInterface.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
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.
88 comments
[ 3.3 ms ] story [ 102 ms ] threadUNITY_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.
I'm pretty sure there's already one in PHP.
Be careful, though, the argument order swapped.
http://phpsadness.com/sad/48
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 ;)
The only one i can think of is object type hinting which alone isn't that big of a deal.
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.
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.
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.
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.
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.
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.
Maybe most HN startups are that, but web development _at it's core_ certainly isn't limited to CRUD apps.
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.
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.
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.