crappy coding practices

I've been working with my professor's code for the past 2 years, and it's got a reputation for being hard to work with. At the same time, my prof is so incredibly proud of it, and claims (correctly) that it can do things no other code can do for problems. The hard part is getting it to do what you want correctly.

A quick coding philosophy lesson - like Shrek and onions, good code should have layers, each with a different level of immutability. This tends to hold in general for any algorithm, program, set of instructions for a problem - make it so that small changes to the problem require only small changes to the program in order to adapt to the new problem.

An example of what not to do - say a program uses some general algorithm to solve a mathematical problem. Hard-code information about a particular problem into the algorithm code, however, and you have a code that's intertwined too much, so that things are connected where they shouldn't be. When you change the problem you're solving, you end up needing to change what should be a general algorithm as well.

Of course, this means that if your code is layered, your inner most code will be used by almost everything else, so to change something there may mean recoding most of the code base. My prof's code is a great example; he built things based around coding protocols and methods of the 70's and 80's, so the heart of the code boasts some pretty annoying outdated practices (for those that are interested, two phrases - implicit declarations and global variables). To further complicate matters, since he needs to maintain some form of control over the code, he refuses to let anyone but himself change these data structures.

So you have a code that has worked for my professor, but has been packaged in a way that nobody can fix it, and few people want to use it because it's so user unfriendly.



N.T. Wright's remark about the rigid intertwining of religious belief with political agendas (abortion, evolution) and specific doctrines (specific inerrancy, literal interpretation) reminds me of my experiences with coding. When coding with my professor's code, I have to write the code in a certain way in order for it to fit the logic of the overall codebase.

Similarly, I feel like theological thought needs then to be executed a certain way in order to fit into the framework of such religious thought. Dr Tour at Rice who I've discussed apologetics with is a good example. When we discussed inconsistencies with the gospel accounts, I interpreted it like Luther - the differences exist, but they do not undermine the overall message. Dr Tour took 15 minutes to discuss the details of how the story, told from two different people's points of views, could appear different but be exactly the same. In the end, I walked away fairly confused by the presentation. This isn't to say he's wrong; however, if he is, then I think his faith would take a fairly significant blow because it was built up from a very specific doctrine which may or may not be true.

In this video, Wright makes an observation about Genesis that I've never heard before - that the 6 day description was written for the Jewish people because that's how tabernacles were described as being built. I think I can appreciate his flexible faith - he doesn't start from doctrine, and thus has room for change - especially for when we make mistakes - when new developments arise.