And I thank God for…

In my previous post, I told about my experience trying to port a
windows-only C++ program first to the cross-platform glib toolkit, then
to the Squeak environment. I gave up because I thought it would take too
long, and because I was not willing to ask for help using Smallapack, a
Squeak/VisualWorks matrix library. Now I have finished the short project
assigned to me and can look at what happened in retrospect.

The code was even harder to work with than I had imagined it to be. In
spite of being written in C++, the program has no modularity whatsoever,
since all the work is done in a single instance of a single class, and a
mighty fat class it is. The class contains three separate, but heavily
related, algorithms to analyze a stream of data using overlapping window
analysis. So, from the very beginning, there is extreme code
duplication, with up to four functions with nearly the same role; only 3
of the functions were actually shared by all three algorithms.

But what of it? This code is a maintenance nightmare, but will it be
maintained? No! So no maintenance means no nightmare. Harvey, my
adviser, said that he had the same problem I had when he first started
making disposable systems: He had to learn how to write bad code.

So what did I do? I just erased the functions that did something they
did not need to do and made them do what I wanted them to do. Sure; I
accidentally deleted a bit of key functionality, but I could just look at
an old version of the code in subversion to put it back in, and then I
had it: an ugly working program, built from another working program;
neither worse than the other. Each separate functional unit is a
separate program in a separate subversion branch; never to be merged
with the trunk. Again; a maintenance nightmare, but no maintenance
means it is all good.

So is my experience applicable in the real world where code lives on?
I hope not. My code has no future. If it did, a refactoring would be
necessary.

So I wonder, is this more of a problem with early-bound, bottom-up
systems like C++ than it is late-bound, top-down systems like smalltalk?
I don’t know. I started the port with the goal of portability and
maintainability in mind, and chose smalltalk because I wanted to see if
it really was easier to use. So was it?

Refactoring was very easy in Squeak, thanks to the refactoring browser.
However, one problem I found was I could not find a way to limit the
scope of a method rename to just my own classes. I managed to trash the
image twice by renaming a message globally.

Backtracking in Smalltalk was easier than in Subversion, thanks to the
ability to view all changes to each method rather than a coarse
commits. However, I did have a little trouble importing changes after a
crash; the change viewer seemed to file in a range of changes in a
non-temporal order, then abort because it tried to define a method on a
non-existent class. That is probably easy to fix.

The smalltalk debugger actually works. The MSVC debugger just crashed. I
had to resort to printf’s and debugging macros. C++ got totally owned in
this respect.

Squeak does not have a stable matrix library. I sincerely wish I had
been able to Smallapack; the only thing that stopped me was the
deadline pressure. It was not the deadline itself, but the pressure of
“just get it working, now” that prevented me from debugging the very
nice Smallapack library. Without that, Smallapack would be slightly more
stable, and Squeak a pre-alpha dataflow framework.

So, what have I learned? The best way to make a deadline is to cheat.
Therefore, I am going to do whatever it takes to make my next project be
free of milestone deadlines, where functionality always trumps code
sharing. This project is open-source in spirit, especially within our
research department, but the focus on the present seems to prevent
the code from having a future, other than as mutant forms of itself.
Luckily, my internship at Intel seems, at least right now, to be free of
milestone deadlines. I have created milestones to track my progress, but
not for scheduling purposes.

Yesterday was my first day on the internship at Intel. It was a lot of fun, and the cafeteria is amazing. But I found out what I had been dreading to hear: I am to develop proprietary software for Intel to use in-house.

I was considering dropping the internship for that reason, but I talked to my father about it first. We talked about the values of free software (for the first time), and I decided that the cost of developing the proprietary software in-house is not very high, as opposed to distributed proprietary software, and that I will only work on proprietary software if it is not distributed.

Here is how I weighed the cost:

Proprietary software costs everyone who uses it a certain amount of freedom. It costs everyone who does not use it the ability to use it, which is not too bad. The software I will be making is a Python program to string together and record the results of proprietary Intel testing and measuring equipment, and so has very little use outside of Intel. That is why I say that denying everyone outside of Intel the right to use it is not too bad: they will not want or use it anyway.

Now consider the cost to the user: the freedom to share it. First, all users are being paid by Intel,  and second, nobody wants it anyway. Thus the users are compensated, and the non-users have a negligible interest in the software, so I think it is OK to work on this proprietary program.  None of this would be true if the program was distributed; thus I will never work on distributed proprietary software.