One thought on “Polyglot Programming: When all you have is a hammer…”
Hi Matthew,
Thanks for your thoughts on this subject. The questions I ponder after this blog are linked to maintainability. I certainly agree with your assessment that you should look beyond just the hammer. Multiple tools however also bring along multiple libraries, coding guidelines, overhead, etc.
Won’t you end up with a product that becomes difficult to maintain as most of the tools evolve in time? (A problem a hammer is less subject to).
Many tools used (serious tools that also continuously improve themselves) come with new versions with deprecated methods, functions, etc. that eventually become obsolete.
I’m not against bringing rigid single tool choices in my teams lives, but currently one of my teams is constantly battling keeping up with earlier tool choices that seem to affect our products majorly.
Hi Matthew,
Thanks for your thoughts on this subject. The questions I ponder after this blog are linked to maintainability. I certainly agree with your assessment that you should look beyond just the hammer. Multiple tools however also bring along multiple libraries, coding guidelines, overhead, etc.
Won’t you end up with a product that becomes difficult to maintain as most of the tools evolve in time? (A problem a hammer is less subject to).
Many tools used (serious tools that also continuously improve themselves) come with new versions with deprecated methods, functions, etc. that eventually become obsolete.
I’m not against bringing rigid single tool choices in my teams lives, but currently one of my teams is constantly battling keeping up with earlier tool choices that seem to affect our products majorly.