I think the underlying art is in striking the right balance between the specific and the general. In studying PLs for almost a decade now, I always ask PL desig

I think the underlying art is in striking the right balance between the specific and the general. In studying PLs for almost a decade now, I always ask PL designers I meet to try and distill their wisdom in one sentence. Andrew Sorensen said something along the lines of "Avoid all abstraction". That shocked me, because my pet theory at the time was that abstraction was basically a force multiplier: good abstraction makes everything exponentially better, while bad abstraction makes everything exponentially worse. Nevertheless that quote stuck, and later I've started to appreciate it in terms of the YAGNI arguments. Regarding abstraction, I've come to believe that a common anti-pattern is deductive abstraction: working down from a general pattern towards a specific implementation. This resembles what a sibling comment called "applying all sorts of design patterns from books to my code" (and not getting great results). The opposite, inductive abstraction, is starting from a specific task and introducing gradual abstraction. Abstraction in lambda calculus is a beautiful example of the concept. Now make that thing a lambda term! There's a Bret Victor classic that touches these themes [1]. [1]: http://worrydream.com/LadderOfAbstraction/ http://worrydream.com/LadderOfAbstraction/