At the time I was trying to calculate π using what I now know is the Leibniz formula, and was explaining to her that it was converging very slowly, and she said that her program for calculating π ran forever because π is irrational. She also was writing programs to calculate π!

But I didn’t quite see how π’s irrationality would affect the program running forever, and she had a hard time explaining, so eventually she got impatient, grabbed a piece of paper, and started writing code. She could write code from memory! This is what she handed me:

    10 INPUT “What is the circumference? ”; c
    20 INPUT “What is the diameter? ”; d
    30 PRINT c/d

And that’s the first time a girl broke my heart.

Kurt already had the 2-D table from a previous project that cut styrofoam using a hot wire. We replaced the wire with a stand to hold the magnifying glass and added various bits so that the machine could face the sun.

To burn a pattern, we bring it into Adobe Illustrator and use a plug-in that Kurt wrote to generate a file of G-codes, which are industry-standard codes that control CNC (computer-controlled) machines. The file is imported into a program called Mach3, which uses the parallel port to communicate with a board that controls the two stepper motors for the two axes.

One interesting thing about a solar plotter is that the sun moves as you’re making your plot. Even a simple circle that takes a minute to burn won’t finish exactly where it started because the sun will have moved by then. A 10-minute burn (like the above) will have major errors in it.

You can see the effect in this burn, which was one of our first:

The “O” on the bottom starts at its upper-left, and that’s where the discontinuity is. We burned the second “E” (lower-right) more slowly to verify that the problem was indeed the motion of the sun. The entire word shifts up because of this problem.

I wrote a program that compensates for this. It reads a G-code file and some other data, such as your location on earth, time of year, time of day, and height of the magnifying glass above the wood, and generates a modified G-code file that adjusts for the sun’s motion. It assumes that the board is perpendicular to the sun’s rays when the burn starts. You have to run it just before you start the burn for the compensation to be correct.

Here’s the final picture of the fox that was being burned in the video above:

I wrote another program that converts a raster image into a file of G-codes. It adjusts the speed of the plotter to generate different levels of gray, zig-zagging down the image. Naturally, I tested it with a photo of Bertrand Russell:

(The low-resolution version is what was actually converted. The high-resolution one would have taken too long.)

Unfortunately this doesn’t work well because the relationship between speed and blackness is very non-linear: once the wood burns at all, it’s already quite black.

One possible solution would be to install an iris on top of the magnifying glass. This would allow us to control the size of the spot being burned. Kurt’s already designed and built it:

We now have to hook it up to Mach3 somehow. One idea is to use the Z axis to encode aperture size, and use an Arduino board to convert stepper motor pulses into servo pulses to open and close the iris. (We would also close the iris when moving from object to object, which we do now by moving as fast as we can, hopefully faster than the wood can start to burn.) Another idea is to keep the iris small all the time and make darker patches using dithering in software.

With package managers life is vastly better. I was recently reminded of this when I tried to install the code-review tool Review Board, which was too young to be in any package and depended on cutting-edge version of other libraries, also not in any package. I spent two full days failing to get all the related software installed properly.

And yet by removing the initial hurdle to installing a program, packages create a large hurdle to scratching an itch. Today if I want to add a flag to “netcat” (which I did years ago to add a delay), it would be enough work that I wouldn’t bother. Before package managers we were forced to do the work, which then made it easy to tweak the code. It also made it easy to examine core dumps when programs crashed.

I was excited to try the Linux distribution Gentoo years ago because everything is compiled from scratch, but I found that they weren’t keeping the source around in a way that you could easily go in and mess with. Perhaps I missed a configuration setting somewhere.

I suspect that package managers have substantially hurt the open source movement. They’ve raised the bar of the commitment needed to contribute. As Wikipedia has shown, it’s critical to have a large number of people who just want to fix small things here and there. I wish Ubuntu had a flag to “apt-get install” that would install from source Gentoo-style and keep the whole thing in your home directory where you could muck with it.

And although everyone knows this, they still do it every day in object-oriented programs, except the globals are now called “fields”. Setting a field in one method and reading it in another is just as bad as doing so with a global variable, but because the variable is inside an object on the heap somehow it has become okay. It’s not; it’s just as bad and it should be avoided. You must think of all fields as globals and minimize their use.

Whenever possible, make fields “final” (in Java) and pass mutable data around through method parameters and return values. This can be hard in Java when returning multiple values, but it’s still better to make a one-off class to hold both values than it is to use fields as a way to pass data around. At least it’s clear how the data is moving through your code.

Update 4/25/2010: I want to clarify that I’m only addressing the case of a single call from a user of a class. If the user calls the class two different times, then clearly a field might be necessary to keep state between the calls. I’m objecting to this kind of code:

    public void doSomething() {
        mStatus = OK;
        doSomethingHelper();
        if (mStatus != OK) {
            fail();
        }
    }

    private void doSomethingHelper() {
        if (problem) {
            mStatus = FAIL;
        }
    }

The status could have just been returned from the second method. Here’s a case where the variable could have been passed in:

    public void doSomething() {
        mParameter = ...;
        doSomethingHelper();
    }

    private void doSomethingHelper() {
        if (mParameter == ...) {
            ...;
        }
    }

I see the above two patterns distressingly often, and from people who would never dream to do the same thing with a global variable in C.

The C++ Standard Committee has been hard at work defining the next version of the language. Here’s a provisional list of changes to be included:

1. For consistency with strings, integers have been split into built-in constants of type int (3, 100, 0xFF, etc.) and the std::integer class. The class has operator overloading to make math easy. The built-in int type no longer has these operators. Constants must be cast to the class for the operators to work:

       Before: 5 + 6
       After: std::integer(5) + 6

   Note that the 6 does not have to be cast because the + operator is overloaded to take integer constants, conveniently casting them for you. This new consistency between integers (and floats, doubles, char, bool, etc.) and strings will reduce confusion.

2. Functions often want to return pointers to local variables, or pass pointers to local variables to other functions. This isn’t safe because when the stack is unwound, those pointers are no longer valid. This has been fixed in the new standard by extending the lifetime of local variables indefinitely. The programmer is responsible for releasing the memory explicitly. For example:

       int add(int a, int b)
       {
           std::integer sum = std::integer(a) + b;
    
           delete &a;
           delete &b;
    
           int sum_value = sum.c_int();
    
           delete ∑
    
           return sum_value;
       }

   The local variable sum was explicitly freed. Note that the parameters also had to be freed. Did you spot the bug? The local variable sum_value was returned (by value), but its address was never freed, resulting in a memory leak. APIs will have to be carefully documented to specify whose responsibility it is (caller or callee) to free both passed-in parameters and returned values. Addresses can be returned by reference parameters to pointers to variables, but remember to free those pointers too.

3. Current C++ compilers must maintain complicated data structures of the functions that are declared or used in each source file, in order to generate the appropriate binary object files. In order to reduce this burden on the compiler, footer files have been introduced. These are files that are included at the bottom of a .cpp file, which summarize all functions that are defined or used by that file. The format is somewhat different than a traditional .hpp file (because the needs of the compiler are different there). The standard recommends the extension .fpp for declaring these methods and their signatures.

4. To remove the confusion over the distinction between the NULL constant, the “0” constant (for pointers), and C++0x’s nullptr constant, and to increase type safety, the null constant is now a template:

       MyClass *ptr = std::pointer_constants<MyClass *>::null();

5. Implementing the Singleton Pattern (Gamma et al) requires writing the boilerplate method to create a single instance. To facilitate this common pattern, the language introduces the keyword “old”. The program should create one instance of the object at start-up:

       MyClass *ptr = new MyClass;

   and other methods can get a reference to that instance using the following construct:

       MyClass *ptr = old MyClass;

   If there are several instances of MyClass in the heap, it is undefined which one is chosen. If there are no instances, a null reference is returned (see previous item). Be careful to not accidentally get a reference to an object on the stack.

6. To reflect the enhancements to the language since 1983, the name of the language has been changed to: dynamic_cast<std::integer>(C)++.

]]> http://www.teamten.com/lawrence/writings/in_defense_of_design_patterns.html Lawrence Kesteloot http://www.teamten.com/lawrence/writings/in_defense_of_design_patterns.html 06 Oct 2009 It’s fashionable to bash software design patterns. “The Singleton Pattern? You mean, a global variable? Hahaha!” It’s hilarious. But I’ve noticed that those who mock are also, curiously, those who’ve not learned about them. I think they (the patterns) serve a useful purpose.

My analogy is to data structures. Imagine that we didn’t have names for data structures, and you had to repeatedly say, “Let’s put data in objects where each object has a reference to the next object, and the last reference is null, and we keep track of only the first one.” It’d be hard to communicate. There’s a bunch of information in your head associated with the name linked list and without the term you wouldn’t be able to organize it or communicate effectively about it.

Design patterns are just that: names for common ways of organizing code, so instead of saying, “Let’s make a class that you can configure and then ask it to atomically make another object so that the other object doesn’t need a long constructor or ever be in a half-constructed state,” you can just say, “Let’s use the Builder Pattern.” Along with the name comes a shared understanding of how and when to implement it, advantages and drawbacks, and what to call the class.



People often crack open a pattern book and say, “There’s nothing new here!” That’s the point. It’s for code structures that we’ve been using for a long time but never had a name for. In fact, seen that way, it’s a bit ridiculous to bash design patterns. Why wouldn’t you want to name a commonly-used thing?

]]> http://www.teamten.com/lawrence/writings/asking_why_in_interviews.html Lawrence Kesteloot http://www.teamten.com/lawrence/writings/asking_why_in_interviews.html 01 Oct 2009 The question “Why?” can be interpreted to mean “What’s the cause?” or “What’s the purpose?” Why do you go to work every day? The cause is the employment agreement, the purpose is to make money. Some questions have only a cause (“Why do you like spinach?” “Why did the sun rise this morning?”).

In everyday conversations I try to ask the unambiguous form of the question, but when interviewing job candidates I’ve found it useful to keep it ambiguous to see which one they’ll pick. It reflects something about the way they think.

For example, I’ll ask a senior database administrator (DBA) candidate what style he uses to name tables (capitalization, prefixes, underscores, pluralization). I have a preferred answer to this, but whatever answer they give I’ll ask, “Why?” Most candidates will interpret this to mean, “What’s the cause?” and will answer “Because that’s what the style guidelines say at my company.”

At this point the interview is pretty much over, but I’ll usually ask something like, “Well what if you worked here?” The answer is usually, “I’d follow your guidelines.”

“What if you had to write the guidelines?”

“I’d use the same ones.”

“Why?” (again)

“Cause that’s what’s in the guidelines of the company I work for now.”

At no point is the candidate considering the “purpose” interpretation, which is the interpretation I’d expect from a senior candidate. He should be thinking about the benefits of the style he’s using over the alternatives. Not doing so shows a lack of introspection, and someone who doesn’t introspect won’t improve and isn’t senior.

My ideal conversation would go something like this:

“What style do you use for table names?”

“All lower case, with underscores between words, singular.”

“Why?”

“Uppercase can cause problems in some dialects because of the case-insensitive nature of the parsers, and you’ll get different results on Windows and Unix with MySQL because they use the table name for filenames. Underscores make it more readable, and singular reads better in most places (though not in the actual join clause).”

At that point the interview is also over, but in a good way.

]]> http://www.teamten.com/lawrence/writings/every_line_is_a_potential_bug.html Lawrence Kesteloot http://www.teamten.com/lawrence/writings/every_line_is_a_potential_bug.html 19 Sep 2009 Last summer I wrote some code to get a message out of a hash table. The message was going to be put there by another thread. There was a small chance of a race where it wouldn’t be there yet when I initially looked for it. The code looked something like this:

    while ((message = map.get(key)) == null
        && System.currentTimeMillis() < timeoutTime) {

        wait(1000);
    }

The wait() call blocks the thread, waiting for the notifyAll() from the thread that puts the message into the map. The 1000 means one second. The timeout was going to be on the order of five seconds.

The above code is simple and correct. It’ll just keep looping until the value comes in or until it has timed out. The timeout may go over by up to one second, but that’s not a problem in this case. (Or rather, by the time that happens, you’ve got more serious problems.)

The code was reviewed by two other people. Both complained that the wait() should wait for the time between now and the timeout, not just one second. They argued that my code wakes up the thread five times unnecessarily. I replied that the key was very likely to be there within the first second, and that waking up a thread is not very expensive. I argued that their proposed code was more complex, and therefore more likely to have bugs.

They both said, “One subtraction is not complex!”, went back to their desks, and emailed me their modified versions, just to prove how simple it could be. Both had introduced a bug. One person’s bug was straightforward: he used the wrong constant for the calculation. But the second person’s bug was subtle:

    while ((message = map.get(key)) == null
        && System.currentTimeMillis() < timeoutTime) {

        wait(timeoutTime - System.currentTimeMillis());
    }

There’s a small chance that the current time will have advanced by the time the subtraction is done, resulting in a negative value passed to wait() and an IllegalArgumentException getting thrown. In order to save the computer one rare thread switch, he introduced a bug that would have occasionally and mysteriously caused operations to fail.

Update 3-15-2010: Ajit Mandalay pointed out another bad scenario: the subtraction yields 0, which means “infinity”, and the loop potentially never exits.

Every line of code you write is a potential bug. Do not write any line of code unless you absolutely need it right now and your program will suffer for the lack of it. Do not write routines speculatively. Do not write abstraction layers you don’t need right now. If an optimization will add any complexity whatsoever, even a subtraction, resist it. You will be sorry in five years when your code is riddled with potentially-buggy code that you never really needed to write.

]]> http://www.teamten.com/lawrence/writings/hiring_in_a_recession.html Lawrence Kesteloot http://www.teamten.com/lawrence/writings/hiring_in_a_recession.html 15 Sep 2009 You’d think that in a recession companies would have an easier time hiring. They should be flooded by resumes because of the high unemployment rate. But I think that recruiting actually gets harder, for two reasons.

The first is that many lay-offs are actually firings. Companies don’t dare fire too many people when times are good because the public may perceive the company as having problems. But in a recession the company can get rid of its 10% lowest-performing employees and blame it on the economy. Some companies do get rid of entire projects, where both good and poor employees are lost, but hiring is so difficult that a company will typically try to keep the best employees before flushing the rest.

The second reason is that good employees, those not getting laid off, hold on more tightly to their jobs. An employee might normally be thinking, “This job isn’t so great, I bet I could do better.” In a recession, though, he’ll be thankful just to be employed. His current situation is likely to seem more stable and safe than a position in another company.

During a recession, then, companies with good hiring standards must find it harder to hire, because although they are flooded with resumes, those resumes are of lower average quality.

]]> http://www.teamten.com/lawrence/writings/paid_vacation.html Lawrence Kesteloot http://www.teamten.com/lawrence/writings/paid_vacation.html 10 Sep 2009 When you quit a salaried job, you get a check for the vacation days you have left. They calculate the daily rate using your pro-rated salary. Every vacation day you take now is one less day’s worth of pay that you’ll get when you quit. So there’s no such thing as “paid vacation”. It’s all unpaid: “unpaid” vacation is unpaid today, whereas “paid” vacation is unpaid later.

One exception is when you max out your vacation days. Then you may as well take them or they’re lost anyway.

I unfortunately discovered this ten years ago, and ever since then my vacations have cost a lot more because I count the reduced check that I’ll get when I eventually quit.

]]>