Why does the dog wag its tail?

Because the dog is smarter than the tail.

If the tail were smarter, it would wag the dog.

The phrase wag the dog refers to times when some­thing of a sec­ondary impor­tance improp­erly takes on the role of some­thing of pri­mary impor­tance. As I watched the record­ing of Tim Ewald’s excel­lent talk Clo­jure : Pro­gram­ming with Hand Tools it is the phrase that popped into my mind when Tim con­cluded that

The tools that you use shape the way you view the world.

Tim’s talk is on the dan­gers of blindly auto­mate with tools with­out fully under­stand­ing them, and one of the strong points he made is that instead of being the mas­ter of our tools we have so often allowed them to dic­tate us instead. If you con­sider the pro­gram­ming lan­guages we use as part of the tools in our devel­oper tool­box, they have a sim­i­lar ‘wag the dog’ effect on us as they restrict the pos­si­bil­i­ties we see and the solu­tions we are able to cre­ate when faced with a problem.

If all you know is object-oriented and imper­a­tive pro­gram­ming, then how will you even know if a bet­ter, more ele­gant solu­tion exists with func­tional, logic or other pro­gram­ming par­a­digms? Or that they don’t?

In his let­ter to the Bud­get Coun­cil of the Uni­ver­sity of Texas, the great Dijk­stra wrote:

[…] func­tional pro­gram­ming imme­di­ately dri­ves home the mes­sage that there is more to pro­gram­ming than they thought. […] It’s not only the vio­lin that shapes the vio­lin­ist, we are all shaped by the tools we train our­selves to use, and in this respect program­ming lan­guages have a devi­ous influ­ence: they shape our think­ing habits. […]

The best way to over­come the lim­i­ta­tions and “shape” that our tools have placed upon us is to actively seek a broader per­spec­tive, by expos­ing our­selves to dif­fer­ent ways of think­ing. What bet­ter way to do that than to try out dif­fer­ent pro­gram­ming par­a­digms and lan­guages. Luck­ily for us, we’re spoilt for choice at the moment – F#, Clo­jure, Scala, Haskell, Erlang, Go, Julia, Dart, Elixir, Rust, the list goes on, and each offers some­thing unique and interesting.


In his inspi­ra­tional talk The Future of Pro­gram­ming, Bret Vic­tor offer a glimpse into a past that many of us was never for­tu­nate enough to expe­ri­ence; a past that had so much more vari­ety because there was no pre­con­cep­tion about what the “right” way is, so all of a sud­den every­thing is pos­si­ble and every­thing is permissible!

It is a sen­ti­ment that is shared by none other than Alan Kay, who spoke of a wealth of his­tory that are worth revis­it­ing as you pon­der about the future, in his 2011 talk Pro­gram­ming and Scal­ing.


To wrap up this short post, don’t let the languages/tools we use mas­ter us, broaden your hori­zons by learn­ing and see­ing the pos­si­bil­i­ties that your tools/languages might not want you to see, bet­ter your­self and become the mas­ter of your tools.


Be the dog that wags the tail.




Tim Ewald – Clo­jure : Pro­gram­ming with Hand Tools

Dijkstra’s let­ter to the Bud­get Coun­cil of the Uni­ver­sity of Texas

Bret Vic­tor – The Future of Programming

Alan Kay – Pro­gram­ming and Scaling


Sup­pose you want to merge an assem­bly A (AssemblyA.dll) with another assem­bly B (AssemblyB.dll) with ILMerge into a merged assem­bly (Merged.dll), and every­thing works fine until the user of your merged assem­bly also ref­er­ences that AssemblyB.dll, at which point that user will get Ambigu­ous ref­er­ence errors for any ref­er­ence to types defined in assem­bly B, for example:

image image

Under­stand­ably the com­piler is not happy here because it finds dupli­cated def­i­n­i­tions for TypeB under the same name­space in the two ver­sions of the assem­bly B (the one ref­er­enced in the user’s project and the one that’s merged with assem­bly A).

So how do we get out of this unholy mess?


Well, there’s this lit­tle known fea­ture in .Net called extern alias which allows you to give ref­er­enced assem­blies an alias via that lit­tle Aliases prop­erty in the Prop­er­ties win­dow for any ref­er­enced libraries (one I’m sure we have all seen count­less times and won­dered what it means).

By default the alias for an assem­bly is ‘global’, which just means global name­space, but you can change it via the Visual Stu­dio prop­er­ties win­dow or via com­mand line options to CSC.exe:


Now the types defined in the Merged.dll assem­bly will fall under the Merged name­space and to access them you need to first add a line to your code:

extern alias Merged;

and then any­where you’re ref­er­enc­ing types from the Merged assem­bly you need to pre­fix it with Merged:: like the following.


You might also want to give Assem­blyB an alias just to remove any rea­son­able doubt which assem­bly a type comes from when­ever you ref­er­ence a type defined in Assem­blyB.


Whilst this is a way to get you out of a tight spot, it’s far from a clean solu­tion, and as @BjoernRochel said below, a good gen­eral advice is to not merge assem­blies that you do not own to begin with:



I gave a talk about our use of F# at last year’s CodeMesh event, and the record­ing is now up on Vimeo.

Yan Cui — F# in Social Gam­ing from Erlang Solu­tions on Vimeo.


You can also find the slides for the talk up on SlideShare:



One of the pit­falls with LINQ which I have fallen into on mul­ti­ple occa­sions is around the use of the OfType<T> exten­sion method with dictionaries.

Either through care­less­ness or changes to the under­ly­ing vari­able (a class prop­erty being changed from list to dic­tio­nary for instance) I have ended up using OfType<…> on a dic­tio­nary which com­piles fine but unless I’m specif­i­cally look­ing for KeyValuePair<TKey, TValue>, it’s not going to behave as I’d expected…


Curi­ously, how­ever, with most other IEnumerable<T> types Resharper is able to spot the dan­ger signs and give me a warning:



Turns out Resharper has a really nice fea­ture – Cus­tom Pat­terns – which I hadn’t been aware of until recently, that allows you to spec­ify your own pat­terns which can then trig­ger suggestions/warnings/errors etc. when matched against ele­ments of your code. I can now cre­ate a cus­tom pat­tern to find places where I have tried to use the OfType<T> exten­sion method against a dic­tio­nary, like the following:




Now, if we go back to the source code, you can see that Resharper has now picked up on my mis­take using my pattern:


and since we spec­i­fied a Replace pat­tern above we can even use the Resharper helper to quickly fix our code!



Kevin Mon­trose’s Jil JSON seri­al­izer has now been added to the JSON bench­mark tests and the results are really impressive.




Kevin has also listed the tricks that he has employed to make Jil fast on the project page, which is well worth a read.