Creative Programming

Last night I read a blog post on LifeDev entitled “14 ways to learn from creative programmers”. I found there to be all kinds of good ideas on how to get more creative. In fact, I plan to take actions on some of these items right away. I want to go over some of the most interesting from this blog item’s list.

Number 1 is to learn a new language. I think I would like to tackle C#. Although I tried to learn it last year, it might be time to get into it deeper and code a significant app in it. For my job I may need to move to the Java platform. We shall see.

Number 4 is to do it for fun. This one I already do to some extent. I write code in my own time. Also at work I take part in some side projects. These are coding exercises that I do just because I like doing them. In addition, I usually share my results for free on the web. This benefits me as well as my audience of my blog where I release my apps.

Number 6 is to find a passion. Over the years I have actually started to really enjoy software maintenance. This is an easy field to get work in. Many developers hate debugging code and researching bugs. I find myself fully engaged in the matter frequently. I would actually call it a passion. My top blog is one that focuses on software maintenance.

Finally number 7 is master your tools. I have worked with Visual Studio C++ 6.0 for over ten years. It is an understatement to say I have mastered this tool. However that tool has almost become obsolete. So we started using Visual Studio 2005 at work. And I can get by. But it takes a while to figure out how to do things with this version of the IDE. Time to get busy, write a bunch of apps with it, and master the darn thing.

I encourage you to check out the LifeDev post yourself. This post has reviewed the four items that most applied to me. But the other ten may be more applicable to you. Good luck.

Cited Articles

I recently read a web article that ranked the top 200 articles cited in the area of computer science. The amazing part was that, for the majority of these articles, I had never heard of them. And I do not think that this is because I am not well read. Perhaps these are specialized academic articles. Or maybe the sources that reference them may be highly academic. However I would like to mention those seminal works that I did recognize.

The 6th most cited item was “Design Patterns: Elements of Reusable Object Oriented Software” by Gamma et al. Almost all developers know this work by the Gang of Four. I have a confession to make: I have never read this book. But that does not mean I don’t know enough about it already. The reason why I have not read it is that I think, after many years of software development, I know what an iterator is. I truly believe this book is one of the most cited works given the excitement over design patterns.

The 10th most cited work was “The art of computer programming, Vol. 3: sorting and searching” by Donald Knuth. Like the last one, I have never read this book. However I know developers who worship the work done by Knuth. A past coworker of mine first read the Design Patterns book. Then he said he started a long study of the Knuth book. You have to really work hard through the examples in the book to get the full benefit of it. Someday when I have free time I may do this myself.

Down to the 34th most cited work was “Object Oriented Modeling and Design” by James Rumbaugh. I am only familiar with this book because I surveyed the literature when I got into object oriented programming. The author is one of the big time guys that got together to produce the Unified Modeling Language (UML). So you know he must have good things to say. I am surprised his work was this high in the list. I expected a Grady Booch work to be up there higher than his.

Finally at number 131 is “Object-Oriented Software Engineering - A Use-case Driven Approach” by Ivar Jacobson. A while ago I was really into use cases. So even though I did not read this book, I knew about it. It is funny. I have not read any of these top cited works. But at least I know about a couple of these. What about you? Have you read these popular documents? If not, I encourage you as well as myself to do so real soon.

Haskell Paper

I read a blog entry by Matthew Sackman regarding a paper he co-wrote. It was entitled “Session Types in Haskell” and was submitted to Haskell Symposium 2008. The paper was not accepted for the symposium. Apparently the paper was reviewed by 3 different individuals. The decision to not accept the paper was made by these 3 people. Matthew’s post essentially challenged the comments he received from his reviewers.

I must confess that it seems like he was whining throughout his response to the feedback. Now I can understand that his paper may have taken a lot of work to produce. However I cannot understand what he was trying to achieve by crying over the spilled milk. He did come forward and say that he was initially must more upset about the decision on his paper. In this word of the web, why can’t you just publish your paper on the Internet?

If your work is truly revolutionary, you can just post your paper in your blog. Better yet you can publish it on your web site. Yes you will need to do a little marketing to get your idea out. Reddit or Digg can help with that. It will not carry the same weight as if it were presented at a conference. But so what? Another angle would be that you could improve it, or come out with a stronger paper next year. The best revenge is to triumph and become famous and rich.

Somehow I suspect that Linus Torvalds may have received some rough feedback the first time he put out his ideas for a new kernel. I bet he didn’t go running home to his mommy. Well, since he actually lived with his parents when he wrote the Linux kernel he may have gone home. But he would have locked himself in the room with his computer, written tight code, and owned the UNIX world. The sooner you get a good attitude, the sooner you will overcome a bad day.

Cheer up Matt. Before yesterday I had never heard about you. If your paper was accepted at Haskell Symposium 2008, I still may have never heard of you. Now I do know a little about you. And I don’t think highly of your post that whined. Your blog is hard to navigate too. But I am hoping you take this opportunity to come back with a vengeance and become famous. Then I can say that I wrote a blog entry about you when you were a nobody and were down on your luck. Mkay?

Array Versus List

Recently I coded a small utility to search my hard drive and clean out files built by Visual Studio. In essence it removed the contents of any Debug or Release sub folders anywhere. I needed this to be able to quickly copy just the source code of a number of projects for another developer. To do this I decided to queue up the directories to delete as the program found then during search. My top choices on how to hold the list of growing directories during search was either an array or a list.

My tool of choice for coding up quick utilities like this is Visual C++ version 6. And I normally employ the MFC classes because I am most familiar with them. So I had to make a choice between the CStringArray and CStringList classes. Usually I go with CStringList because I know the class member functions by heart. However I decided to determine my needs and use the class that fit those needs the best.

The algorithm was to make use of a queue. Every time I found a directory I wanted to add it to the beginning of the queue. And when the program was ready for more processing, it would take the element from the end of the queue. I decided to go with CStringList as usual. The AddHead() and RemoveTail() operations were just what I needed. RemoveTail() is especially useful because it gives me the element I want and removes it at the same time.

I will confess that performance did not even enter my mind when making a decision on the class to use. But in retrospect, the list may very well be the fastest choice anyway. It should be easier to remove items when all that connects them with the rest of the list are pointers. A brute force implementation of the array would not best well suited to insertions or deletions at one end of the array.