CostsBenefitsOfMetaProgramming

A language that lets you construct higher-level structures

• + you write less code ->

: fewer mistakes

• - your code is harder to read and reason about (more like maths / compare LookMathsUp) ->

: harder to maintain without geniuses, eventually you rewrite in a more pedestrian language

Therefore, be careful what high-level capacities you encourage. You might end up like LispLanguage : brilliant but unused.

• http://blog.ianbicking.org/the-challenge-of-metaprogramming.html

Covers similar questions to GreatHackers

Compare BillDeHora In short: object languages that have a get/set idiom and do not have function passing naturally lean a programmer towards larger centralized units of behaviour orbited by collections of fields masquerading as objects. : http://www.dehora.net/journal/2005/01/javagetsetnotthatharmfulversioncontrolforrefactoring_harmful.html

Advantages:

• Allows one to write code which looks closer to a domain. In particular, this helps programmers communicate more closely to clients using their domain's concepts, rather than in terms of the tool's primitives.

• Empowers programmers with abilities previously hoarded by language designers, who can not predict all possible uses of the tool. We see the effects of this in the Python community, where an aristocracy must decide "the preferably single right way to do something."

• Guards against the tool's creeping featurism. C++ creator Stroustrup correctly predicted that Java would not be able to remain so small and neat. The same is true with Python, which must contend with increasing political pressure from users to accept "advanced" features like decorators. And these features pull the tool in different, possibly incompatible directions.

• Allows people to write code-analyzing tools far more simply, without worrying about writing messy parsers which may be obsoleted with the tool's next version.

• Common uses are idiomatic. Most macros one defines are actually quite obvious and small in scope.

• Implies a new paradigm where a community, over periods of time and through darwinism, evolves powerful extensions to the tool. Case study: Common Lisp's OOP system is either the most powerful or one of the two most powerful. It likely would not have existed if only some language designer had to also be a bleeding-edge OOP expert.

• Even if metaprogramming isn't available to normal users, language designers may use it to more easily prototype and test their ideas.

Disadvantages:

• Since you're extending the tool, helpful error messages are needed. For something which will be used by others, frustration will result if the macro is non-obvious with low-quality error messages.

• Common Lisp shows that an ensemble approach is needed. If one "paradigm," such as macros, hoards the stage like a greedy actor, hilarity will ensue. Paradigms have sweet spots where they are most powerful, beyond which the usefulness declines. So metaprogramming requires and rewards good judgment.

• Lies outside the current paradigm of deskilling programmers. Therefore it will face enormous challenges and impossible standards of proof, none of which are technical. This means you will likely not use these tools when pursuing the commodity-coder strategy of pursuing the programming profession. These tools frighten management, unlike say Java.

• Requires good tradition of education and literature, so people know what pitfalls exist. Similar to that required to use any powerful tool well; see the enormous amount of books on any programming language.

• Possibly difficult or tedious to bolt onto a currently existing language which wasn't particuarly designed for such uses. (I don't know if this is true.)

Common Fallacies:

• Lisp is unused.

** Models which rely on this argument fail to explain why Common Lisp is visibly and obviously growing. From this year's embarrassing success at conventions like ECOOP, to the fact that there are at least four healthy commercial CL implementations that charge from $200-20000/seat, means that Lisp is used and growing.

** Further, Emacs provides a counterexample. People who cite Lisp's lack of adoption never cite history, they believe in tech darwinism that was debunked in DavidNoble/ForcesOfProduction. We could also question whether we think Britney Spears and McDonalds are the best music and food in the world. Is Microsoft the technically most natural and productive OS that ever existed, or are there detailed business and luck reasons behind their success? (More PlatformWars)

** Finally, real OOP is unused, if you judge by C++ and Java. "I invented the term 'object oriented programming,' and I can tell you I did not have C++ in mind." – AlanKay.

• Yahoo's rewrite of PaulGraham's software proves metaprogramming is dangerous.

** A moment's reflection shows this is an irrational argument that people grasp for straws against when a tool is too far outside current fads. DavidNoble claims that tech which doesn't follow the management paradigm of DeskillingProgrammers will be required to pass impossible yardsticks of economic success, even given proven success.

** For one thing, Google's cofounder explained that Yahoo refused to buy/license Google, because "search quality wasn't competitively important." Forcing Google to compete and win. So Yahoo has a history of killing geese which lay golden eggs.

** Further, Yahoo chose PHP to rewrite core systems, in preference to tools like Java and Python. Following this logic would imply that PHP is clearly superior to these other tools.

** Another point is that Paul Graham was extremely successful in beating out massive competition, to cash out handsomely, and he claims Lisp was his main, secret weapon. So it seems massive competitive, market and financial success isn't enough for naysayers. In his book Hackers & Painters, he pointed out that large corporations like Yahoo required a herd of coconuts to develop software, so they choose tech based on current popularity. That does not particularly sound like a technical or merit-based decision procedure.

** There are further points, but let's let this lie for the moment.

– Tayssir John Gabbour

Thanks Tayssir. This is very interesting. Never heard of this guy DavidNoble but I need to know more. Google is pointing to a FirstMonday article (which for some reason is timing out) but if you have that ref. I'd be grateful.

– PhilJones

I hope you have that now? It doesn't time out for me. Sorry if I took some time to do this, damn holidays. ;) http://www.firstmonday.org/issues/issue3_1/noble/

– Tayssir John Gabbour

This interpretation of the difference between initial builders and maintainers isn't the only one available. See InitialBuildersVsMaintainers.

Compare :

• FunctionalProgramming (my take on why functional languages don't succeed)