Adding an ad-hoc, informally-specified, bug-ridden, slow implementation of half of CommonLisp to a program. Or, in greater generality, writing an ad-hoc, informally-specified, bug-ridden, slow implementation of ''any'' language in another language, for the purpose of working around deficiencies in the target language.

''Or in even greater generality, implementing domain-independent language feature(s) in a language which lacks the feature.  See LevelsOfGreenspunning''

''Or, in even '''greater''' generality, making a bad tool instead of using an (already existing and available) good tool.''

This usually leads to extremely complicated code. It is GoldPlating to the ultimate degree.

----
Is it still GreenSpunning if it is for the purpose of working around perceived deficiencies in corporate procedures rather than the primary development language?  
For example, if changes to C++ code require QA reviews but changes to configuration files do not, I can extend the configuration language to make it Turing-complete and give it access to GUI widgets.  Once I have these features accepted, I can use them to add functionality or bug workarounds at any time, bypassing the QA procedure.

Is this a case of GreenSpunning or is it some other AntiPattern?
----

I've noticed a lot of this in software containing a social element -- if it isn't a wrapper around IRC (e.g. WormNet in the venerable invertebrate massacre simulator Worms Armageddon) then it invariably contains an ad-hoc, informally specified, bug-ridden, slow implementation of half of IRC. The example that actually made me realise it was Pokémon Showdown, but it goes as far as instant messaging from ICQ to Facebook -- many of which have tried to expand outwards to cover multi-user communications and succeeded only in providing an ugly interface.

I can't help but think the IRC protocol is to blame -- it's extremely conservative in that rather than providing a vibrant mechanism for common features to be rolled into the protocol itself on a semifrequent basis, it gives server developers carte blanche to extend the protocol in whatever direction they please and indicate support via the ISUPPORT response, which client developers then have to play whack-a-mole with. Perhaps we need a Common LIRCsp...

----

See GreenspunsTenthRuleOfProgramming, ImplementingLisp.