I have been programming in support of my work (research and teaching) for over four decades now. I started in APL, then move very briefly to C and then for a while in C++. A lot of the C++ concepts have stayed with me in terms of programming style, but I then moved to interpreted languages for a number of reasons, first to Perl and now to Python for decades.
Python allows me to at least try to write elegant code and appeals to me aesthetically, although as time goes by I do tend to focus more and more on C++ concepts of interface design, hiding implementations, test-driven development and programming by contract. (Java came along later to these things and I never warmed to Java.)
Now that my retirement is in sight (I'm about 80% of the way through my career) I've been trying to articulate my programming style. I want programs to be correct but also demonstrably correct; clarity and programming by contract are more and more at the forefront of my mind.
For the last few years an on-and-off-again-and-on project has been to develop a framework for reviewing projects that are complete, revising them to expose any logic flaws, and to make them work clearly and not just work. Toward that end I've been working on some automatic diagnostic reporting that I've not currently seen in commercial tools, very idiosyncratic stuff. I've given a talk or two over the years about identifying with group theory classes that should be extracted from an implementation, etc.
It's engrossing, then I tire of it, then I start thinking about it again intensely with a new perspective.
Comments
Post a Comment