Towards Cradle-to-Cradle Implications on Coding
Send us your comments.
I actually don’t want to make fun of the Cradle-to-Cradle idea. I may even consider myself a fan, more so, the whole idea of creating stuff in a way that its residues from production and usage, as well as all the parts of the product, have to be considered of being resources is intriguing. Removing the term “waste” from our dictionaries would change the whole game of humanity.
I have been listening to an interview with Michael Braungart and if you are not fluent in German, it should be worth your while to read up about Cradle-to-Cradle somewhere else (watch, read). Just to catch the idea. But the most interesting part of the interview to me has been the repeated mention that it is not sufficient to just develop better and better products. Actually, creating better, or less bad, products, has made the mess we are currently in worse. And I started to think about; what could be my part in this?
It is obvious why a chemicist like Braungart came up with the whole idea, but I am a computer scientist. What exactly is my contribution towards a sustainable humanity? How can I become “carbon positive”? I am not at all involved in designing physical stuff.
Yes, there is the Internet, the social networks and all the linked data that I am somehow part of the ongoing development. But in what direction would development in this area be an improvement to the way we are impacting our universe?
What makes the creation of code actually more Cradle-to-Cradle? What are the residues of the coding process and in which way can the products be used after they have fullfilled their function? Digital data is as endless as you are willing to store it and thus will not actually have a point in time where its time-to-live ends forcefully. The code itself is the product that must serve a part in a program and parts of the code could actually be used in different programs after they where included for the first time. But there also are the problems of finding the right code that also has to fit your particular framework (programming language, operating system, data representation, processor) and provides the required functionality.
Create re-usable code
Every minute not spent on re-inventing the wheel is time usable for other productive things, for example tending my compost to produce more and better humus. Software libraries have been invented to make code much easier re-usable. And open source made it much easier to incorporate such solutions into your own program.
But what is re-usable code? The following is rather a starting point for discussion than a complete list.
Firstly any individual function should provide only a small solution. Because if you build some monstrous do-it-all, it is highly unlikely that you are able to use it anywhere else.
Write generic code if possible, that solves a problem for a class of in- and outputs. If you have function that is “appending” different things to each other, it is highly likely that it may be applicable to many things that are “applicable”.
Try to keep your code pure, meaning that your functions should be without side-effect. And if you cannot avoid side-effects, try to encapsulate them in a way that does not affect all of your code but only a very small part of it. Keep your side-effects within distinct functions in a way that the functions using the results itself remain pure.
Ensure readability of your code. And I know, there are endless discussions about style in coding. But generally it is helpful, if you try to use meaningful names that describe the functionality well. To use syntactical structure, indentation and operators that are easy to read and not only understandable by the chosen few.
There are, of course, others who have much more specific advice, for example on coding readable Haskell, albeit with a different motivation.
I have been exposed to the requirement for small solutions, meaning tools that solve one particular problem, listening to Frank Rieger at something most likely called the Cyber Security Day. The main topic has been security and the motivation for small tools was to prevent monopolies from dominating the landscape and supporting heterogenuous software landscapes, small developers and interoparability — instead of monolithic frameworks that lock in their users.
It is actually a very good requirement for software development in general, and nothing new. “Divide and Conquer” has been the most often heard battle cry in software development for decades. It is only the public that is often confronted with a big black block of a half-finished tombstone of a program, marking the beginning of an endless succession of illegible errors and unspecific updates.
Create usable things
If no one is using your work’s results, than you worked just for practise. That is, I wouldn’t consider it a waste of time as it is, but let us be truthful to ourselves, it has yet to show its necessity. (This actually is true for this very blog here, I haven’t seen many readers up to now.)
Finding reusable code
I am not sorry in the least to — again — advertise the absolutely wonderful Haskell community, or the R community if you like statistics, where it is customary to publish your documentation and code. Both communities are filled to the brim with small libraries that provide very specific functionality for a specific area.
I am currently more involved in Haskell and thus I can only link towards the relatively good working hoogle engine, where you can provide a function’s signature and are provided with likely candidates. API Search seems to be a more generic approach to that service, but 941 API included seems a little small. Google Code also is a little bit to narrow, targeting only its own repositories.
TO BE CONTINUED—–