Editorial: Reduce, reuse, recycle

As some readers may be aware England recently introduced a tax on plastic carrier bags, barring exceptional circumstances such as buying an axe or a chicken. Other parts of the UK had done this a while ago, without so much fuss, as far as I could tell. I became mesmerised by various comedians on the television and radio talking about this. In particular, it seems that a writer in possibly the Daily Mail had given a Viz-style ‘Top Tip’ [citation needed] of avoiding the new tax by taking your own shopping bags to the supermarket. This led to much ridicule from topical comedy shows, since the more astute among us realise the point of the 5p ‘tax’ is to encourage the reduction in the use of the plastic bags which harm the environment. I suspect using the excuse of watching or listening to comedians and thinking about the environment might sound like a very poor excuse for not getting round to writing an editorial. I am told consistency is a virtue, and you must have expected this by now.

The ‘green’ or perhaps ‘clean’ campaigners have been pushing the three R’s for a while; reduce, reuse, recycle. This campaign started off in the 1980s, and I suspect most people have heard of the three Rs, not to be confused with the British education system’s three Rs – reading, writing, and ’rtihmetic. The internet [ all-recycling ] tells me “ Recycling has a history that dates back to the historic times. ” That’s the kind of history I like. In all seriousness, what struck me while reading about recycling is that if you spoke to Turkish people in about 400 BC about recycling glass they would possibly ask what a cycle was and then say “But we’re just using it.”

In between my hectic schedule of not writing an editorial and listening to comedy, I have started to read some of the books on our book cases that I’ve never read before. Prior to starting my Dad’s algebra book [ shameless_plug ], I read Ruminations on C++ [ Koenig ]. I rediscovered people talking about the promise of object-oriented (OO) code allowing you to reuse code easily. One of our three Rs. Have you ever reused a class? Certainly, if your class were to be a singleton [ GoF ] then you would only be able to make one of them ever, during the course of one run of your program. If you had two cores and ran two instances of your program, you might end up with two, though as ever I digress. You still might use the singleton a few times during the course of the program. Just using it once would seem single-mindedly satirical. In the long run, you may find it very difficult to unit test or manage lifetimes and start considering never using any singleton ever again let alone reusing that one. Reducing the use of singletons is one nudge towards greener, cleaner code: our second R. Reduce. We will return to this thought later. Apart from singletons, the OO coders among us have probably written several classes. Have you ever put them in a library and referenced that library from a variety of projects? Or decided your AbstractFactoryBuildManager was very specific to your last project, and had a terrible name, so you just copy and paste some of the better parts into your new project, and rebuild it having learnt to be a better programmer. Rebuild is not one of the three Rs. Perhaps programmers need four. Though we haven’t decided what recycle means yet. We will, dear reader.

Ruminations [ op cit ] talked about being able to reuse C++ classes more easily than C code. The authors tell us they had a C program for distributing other programs, which needed revision to handle larger loads. They decided to, “ Try the revisions in C++ instead. The result was successful: My rewrite increased the speed of the old version dramatically, without compromising reliability. Although C++ programs are innately no faster than corresponding C programs, C++ made it intellectually manageable to use techniques that would have been too hard to ... implement reliably in C. ” The book then explores the possibilities C++ gave over C. Some of the main points include data abstractions, avoiding conventions by making it impossible to use these structures incorrectly – e.g. C++ strings versus C-style char arrays, templates, inheritance and many other features. We even find a section entitled ‘Recycling software’ in the first chapter which talks about easily extracting a string library from one project for reuse in theirs. Note that this pre-dates C++98 and the official STL. Perhaps reuse and recycling are slightly blurred in any context. Where reuse might mean just using something as it is, recycling might mean taking something and changing its form slightly to be better suited for a similar task. You can reuse or recycle C code too. I worked at a place that had a small library of useful things, such as a doubly-linked list, which was reused in various projects. C++ would have allowed us to use a generic type rather than the traditional void * yet we could reuse it as it stood. Library code might be the ultimate way to reuse code. A large part of Ruminations [ op cit ] talks about OO and specific foibles to be aware of in C++ such as virtual destructors, assignment operators and copy constructors, encouraging you to write easy to use library code. Though OO was hailed as a way to reuse code there are many articles bemoaning this as a failed promise. For example, Ambler [ Dr Dobbs ] tells us “ Reusability is one of the great promises of object-oriented technology. Unfortunately, it's a promise that often goes unrealized. ” He digs into various ways in which code can be reused, beyond just ‘inheritance reuse’. Worth a read. As an aside, I note that languages like Java and C# do constantly reuse at least one thing – Object, not something you find in standard C++.

Different languages have different paradigms. C++ is often described as a multi-paradigm language. Specifically, the STL contains classes but does not use OO as such, rather using generic programming. Never try to inherit from std::vector , for example. Stepanov, the so-called ‘Father of the STL’, talks of starting with an algorithm, including the complexity requirements and allowing that to drive the implementation, always keeping the algorithm and the data it operates on separate. Actually, to be precise, he talks about a bacterial infection, algebra and the associativity of addition but people seem to be more interested in using the STL than understanding the mathematical foundations of his work or his health problem at the time. Now, I am aware of many other types of containers and various algorithms which are not in the STL. It is possible to code up your own, following the pattern of using iterators to access the data you wish to operate on generically rather than using OO. I started to wonder how the committee decided what to include. I see an R – reduce – in play again.

Bjarne is personally responsible for reducing the number of components in STL by a factor of two. He was trying to make it as small as possible to placate the opposition. [ Stepanov ]

In order to arrive at a usable library, which is therefore reusable, the scope was reduced. Reduced scope or even reducing the amount of code is frequently a winning formula. Furthermore, it is often possible to fix bugs by deleting code. Reducing the number of Boolean flags is my personal favourite.

What have we learnt so far? It is possible to reuse code, and not just by copying and pasting it, however tempting that may be. It is frequently desirable to reduce the amount of code, either deleting chunks of unused legacy code, or making something more generic so you just have an algorithm once, rather than once for every type. You can take genericity too far, ending up with terse statements that are difficult to read. Sometimes a plain old for loop is simpler to understand that C#’s LINQ or similar. There’s no point in reducing it down so far that the code is never used. Nonetheless, the ‘Don’t repeat yourself’ (DRY) principle encourages us to refactor, yet another R, by abstracting repeated blocks. Given reduce, and reuse where does this leave recycle? Once upon a time, not that long ago in fact, I encountered a python file entitled NewMerge5.py. This very much suggested that there had been a 4, 3, 2 NewMerge.py and possible just a Merge.py at some point. We have all done something similar. Eventually, sense prevails and a programmer might start using version control. At this point you could be tempted to rename the file Merge.py, to cover up the chequered history prior to version control. Or not. Version control is an excellent tool to help us become cleaner coders. We can reuse something, just by invoking git clone, or the specific incantation for our flavour of version control. We can reduce the lines of code, and rollback easily if something goes wrong. We can recycle (or perhaps refactor) code easily – particular if we can find it in version control, rather than lying around in someone’s home directory. Don’t forget proper refactoring should be done with the safety of tests. How many times have you found copied and pasted code in a large code base that came from the internet, but the tests weren’t pulled over too? Schoolboy error.

It seems to me that there’s a strong parallel between the three Rs and the TDD cycle. Consider both parts in Figure 1. On the left we have the reduce, reuse, recycle in order to be greener, while on the right we have the test fails, test passes then refactor steps – also known as the red/green/refactor cycle. Many things come in threes.

Figure 1

I may have stretched the analogy a little far, but while the environmental activists have started a move towards calling themselves ‘clean’ rather than ‘green’, perhaps we coders should consider striving to be green, as well as clean. Reducing code is a delight. Reusing code is possible, if it is well written. And finally, recycling is possible, given version control, libraries that are platform independent, and a willingness to use someone else’s code rather than feeling the need to rewrite your own version. If we fail to be green, we could always consider a 5p copy and paste tax. Every little helps.

References

[all-recycling] http://www.all-recycling-facts.com/history-of-recycling.html

[Dr Dobbs] ‘A Realistic Look at Object-Oriented Reuse’ Scott Ambler, January 01, 1998 from http://www.drdobbs.com/a-realistic-look-at-object-oriented-reus/184415594

[GoF] Design patterns : elements of reusable object-oriented software Gamma, Helm, Johnson, Vlissides, Addison Wesley, 1994.

[Koenig] Ruminations on C++: Reflections on a Decade of C++ Programming , Koenig and Moo, Addison Wesley, 1996

[shameless_plug] A Foundation Course In Modern Algebra , David Buontempo, Macmillan, 1975.

[Stepanov] ‘An Interview with A. Stepanov’ by Graziano Lo Russo from http://www.stlport.org/resources/StepanovUSA.html