I think I agree with many points (especially avoiding frameworks and patterns when you don't need them), but even though this manifesto is warning against extre

I think I agree with many points (especially avoiding frameworks and patterns when you don't need them), but even though this manifesto is warning against extremism, it makes some points that seem extreme for me. For instance, it's Paul Graham: > When we try to improve ourselves, and in this case more specifically our code, we sometimes get hung up in the philosophy of a particular pattern or idea and tend to forget to think practically. >> When I see patterns in my programs, I consider it a sign of trouble. The shape of a program should reflect only the problem it needs to solve. Any other regularity in the code is a sign, to me at least, that I’m using abstractions that aren’t powerful enough - often that I’m generating by hand the expansions of some macro that I need to write. But it seems like the author is misunderstanding pg. pg is claiming that if a pattern (of any kind - whether it's a "GoF-approved" design pattern or not) keeps repeating in your code, your code is not abstracted enough — either because you're not using the right abstraction for the job, or (what will be inevitable in a language like PHP) because your language is not powerful enough. The solution presented by this article is just: "Do not always use patterns" - but it doesn't clarify which patterns you should use. But Paul Graham is saying something much broader than that: design patterns are just a type of pattern, and patterns of any type should not be repeat. Essentially, this is a strong version of DRY that considers any generalizable patterns as repetition. > Later, procedural programming was derived from structured programming. Procedural programming is based upon the concept of “procedure call”. A “procedure call” is just another name for a “function call”. I'm pretty sure it's the reverse. Following this we get a justified criticism of OOP (although we should be clear here: this is mostly the bastardized Java brand of OOP). And there we get another quote from pg (who I assume was criticizing the very different CLOS and its necessity in a Lisp-family language). Then this bit ends again with the suggestion "Do not always use object-oriented programming". I can't agree more with that, but alternatives should be provided. When should I avoid OOP, and when OOP would be good (the source for pg quote is actually followed by a recommendation for Common Lisp)? What should I be using instead? The funny thing is that I probably agree with the intent behind this manifesto, but I can't ask any PHP programmer to reconsider their best practices following this. Since the rationale is not presented clearly enough, and no guidelines or alternatives are defined - or even proposed - it won't help to convince a lot of programmers from my experience.