Language elitists

It surprises me how often I run across programming language elitists who express opinions such as those found in sizeof(char) is 1. The prevailing opinion here is that if you write extraneous code, it’s obvious that you don’t know enough about the language.

The author’s primary rant here is that the C standard defined sizeof(char) as 1. So writing (sizeof(char) * StringLength) is the same as writing (1 * StringLength), and that’s just silly. After all, everybody knows that 1 * x == x.

Whereas he’s right in saying that writing sizeof(char) is unnecessary, his assertion that doing so shows a lack of understanding is complete and utter bullshit.

Computer programming is in large part an exercise in applying familiar patterns to solve unfamiliar problems. We benefit from using patterns, and the general pattern for using malloc is malloc(size_of_thing_to_allocate * number_of_things_to_allocate). Why change that pattern just because you know that the size of the thing you’re allocating is 1? It’s not like it matters in terms of performance. The compiler is going to output the same code, regardless of which way you wrote it.

At the end of the article, the author points out that there are two forms of sizeof. When the argument is a type, then the syntax is sizeof(type). When the argument is an expression, you can write sizeof expression. That is, you can eliminate the parentheses. He goes on to say:

If you don’t need the parentheses then don’t use them, it shows that you know the syntax of sizeof and generates confidence that you know what you’re doing.

I suppose, then, that all extraneous parentheses should be removed from all constructs? After all, by removing the parentheses from this code:

if (((x == 22) && (y == 33)) || (z == 15))

You have:

if (x == 22 && y == 33 || z == 15)

Never mind that by removing the parentheses you’re losing contextual information that actually helps in understanding the code. Sure, the minimal version works just as well. But the first version groups the expressions and shows me explicitly what the code is doing. I don’t have to dredge the operator precedence chart out of my brain and apply it. I can look and know. The “extraneous” version takes less effort to decipher, and I’m more likely to understand it correctly. More importantly, I’m more likely to write it correctly the first time around.

The things that the language elitists complain about are legion. C programmers often write if (!count) in place of if (count == 0). Why? Because it’s less code to type. They’re adamant that writing == 0 is something that only the uneducated masses would do. As one person put it, “every time you type ‘== 0,’ God kills a puppy.” Idiots. Never mind that by writing if (!count), you’re implying that count is a Boolean value. If you want to check to see if something is zero, write code that checks it against zero!

C#, of course, eliminated a lot of that madness. You can’t write if (!count) if count is an integer. That doesn’t stop the language elitists, though, from complaining if you write if (Char.IsDigit('0') == true). The problem? “== true" is unnecessary. Perhaps it is. But it’s also completely unambiguous.

By the way, it’s amazing how many of those who “know everything” about the C language end up writing return (1);, even though the parentheses are not required. The syntax is return expression. The parentheses are allowed, but not necessary.

Adopting patterns frees our minds to worry about applying the patterns to solving the problem rather than spending brain cycles thinking like a compiler so that we can write the tersest possible code. Asserting that somebody who writes verbose but readable and correct code is somehow less knowledgable only shows your ignorance of what’s important. Why spend brain cycles on irrelevant stuff like that?

I freely admit that I don’t have the C# precedence of operators table memorized. And you know what? I don’t have to memorize it or even consult it. Because I know that if I fully parenthesize my expressions I’ll never be wrong. I even use { and } to enclose single-statement blocks. Terribly inefficient of me, don’t you think? And when I was writing C, I did indeed write sizeof(char) in my calls to malloc.

The language elitists would have you think that doing those things makes one less of a programmer. I, on the other hand, think that it makes one a better programmer. Why? Because the programmer who adopts such patterns spends his time solving the problem at hand rather than trying to make his code show that he knows and understands every nook and cranny of the language specification. The kind of elitism espoused in the linked article and by others of the same ilk is fine for college students and hobbyist programmers. But those of us who are paid to solve problems don’t have time for that kind of bullshit.

Swallowing exceptions is hiding bugs

The whole idea of using exceptions is to catch and handle unusual situations that could crash your program or corrupt state such that the results your program produces are incorrect. In modern programming languages, exceptions have been perverted and are used in place of normal everyday error handling. But that’s a rant for another time.

One of the basic tenants of exception handling is catch only what you know how to handle. For example, in .NET the File.Open method can throw any one of several different exceptions.  When writing code that opens a file, you have to handle those exceptions. So, for example, you’d write:

FileStream f;
try
{
    f = File.Open("filename", FileMode.Read);
}
catch (FileNotFoundException)
{
    // code to handle file not found
}
catch (DirectoryNotFoundException)
{
    // code to handle directory not found
}
// other catch statements for other exceptions

You do not want to write this:

try
{
    f = File.Open("filename", FileMode.Read);
}
catch (Exception ex)
{
    // handle all exceptions
}

Why? Because there may be exceptions there that you don’t know how to handle. Sure, you can check the type of exception and re-throw those you don’t know how to handle, but then you’re defeating much of the purpose of exception handling and you’re also losing information.

Failing to handle exceptions is bad, but it’s not the worst thing. The worst thing you can do is catch an exception you don’t know how to handle, and fail to pass it on. Doing that masks bugs. For example, imagine your program does some calculations using a shared variable:

public int NumberOfItems;

private double GetAverage()
{
    double total = GetTotal(); // gets the total of something
    double avg = total / NumberOfItems;
    return avg;
}

If NumberOfItems is zero, the code above would throw DivideByZeroException. That’s right and proper, since the result of dividing by zero is undefined, and you don’t want your program producing the wrong answer. That could be disastrous. It’s better that the exception escape and potentially crash your program, the idea being that no answer is better than an incorrect answer.

Now, suppose somebody comes along much later and decides to “fix” that crashing program. He writes:

// For some reason this code sometimes crashes the program.
// This will fix it.
try
{
    CallMethodThatCallsGetAverage();
}
catch
{
    // Squash that pesky exception
}

That very effectively prevents the GetAverage method from crashing the program. It also very effectively prevents any other catchable exception from crashing the program. It “fixes” the symptom (the program no longer crashes), but it doesn’t fix the problem. The programmer who writes that should be … “counseled.”

And don’t think I’m making this up. I’ve seen such code.

It’s one thing for a programmer to make a “fix” like that. It’s another thing entirely to create a Framework component that works that way. A case in point is the .NET System.Timers.Timer component. The documentation for the Elapsed event says:

The Timer component catches and suppresses all exceptions thrown by event handlers for the Elapsed event. This behavior is subject to change in future releases of the .NET Framework.

This is terrible! Imagine that your Elapsed event handler encounters corrupt data and wants to throw an exception so that the program will crash. It can’t! Try this:

static void MyTimer_Elapsed(object sender, System.Timers.ElapsedEventArgs e)
{
    Console.WriteLine("Badness! Throwing exception");
    throw new ApplicationException("something bad happened");
}

The exception will never escape to the main program. The timer handler in .NET does essentially this:

try
{
    MyTimer_Elapsed(sender, args);
}
catch
{
    // Why would anybody want to know that something bad happened?
}

System.Timers.Timer is a bug hider, and for that reason shouldn’t be used.

Unfortunately, that’s not the only component in the Framework that squashes exceptions. It seems like any event handler that executes on a non-UI thread will squash exceptions. I don’t know if that’s globally true, but it sure seems that way. I always check the documentation these days, just to be sure.

 

On a spoon kick

I’m really enjoying the spoon carving. I finished three more spoons the other night, all of which are eating utensils rather than decorative or serving spoons.

The spoon on top is from a piece of mesquite left over when I cut out the big soup ladle a couple weeks ago. I picked up a scrap to whittle on while I was waiting for the finish to dry on something else. The bowl is about the size of a half dollar, and not very deep. Maybe I could use it for eating a container of yogurt.

The maple spoon in the middle is the size of a normal breakfast spoon. I didn’t get it perfect, but it’s usable. Although you can see one spot where the wood is paper thin. I got a bit too aggressive with the gouge. I used that spoon at dinner last night. The slightly fuzzy feel of newly finished wood is oddly uncomfortable when you’re used to the perfect smoothness of stainless steel. I’ve heard that spoons used for eating get smoother with use. I hope so. In the future, I’ll use a finer sandpaper before finishing.

The spoon on the bottom is carved from a piece of fig. I should be a good spoon for soup or stew.

More spoons

I’ve been on a spoon kick lately. I’m enjoying spoon carving so much that I actually ordered some tools made specifically for spoon carving. They haven’t come in yet, so I continue with what I have.

This rectangular scoop was an experiment. I purposely left it a little rough to see how it would look. Some people like it, but I don’t care much for it. I think I want my spoons to be smooth. I think the wood is spalted maple. I picked it up from a scrap pile at the local Woodcraft store. I think I prefer rounded shapes, too. The rectangular bowl was difficult to carve.

The coffee scoops are kind of fun because they’re simple to carve and don’t take very long. And people really seem to like them. I thought I’d try another experiment: a scoop with a side handle.

The spoon is about four inches long, total. The bowl is about an inch in diameter. I still haven’t decided whether I like the side handle thing. The wood is yellow poplar.

This last is a two-teaspoon measuring spoon. I suppose I should have made it one and a half teaspoons, which would make one half tablespoon. The wood is from a fig tree in the back yard. I love the way it looks, except that it cracked.

I saw the crack in the wood before I started carving, but it looked like the crack wasn’t that deep. By the time I discovered the full extent of the crack, I was well into carving the spoon. I finished it, anyway. With the crack, there’s too much chance of stuff getting in there and staying. So this won’t be used as a measuring spoon, but rather decoration. It’s five or six inches long, and the bowl is a bit over an inch in diameter.

I have a couple of other spoons in various stages of completion. When those are done, I’m going to try making spoons for eating. Might even try a fork.

Mesquite spoon finished

I had planned to take more in-progress pictures, but then got involved in finishing the spoon. So all you get are the finished pictures. See Part 1 for photos that show the carving progress.

The spoon turned out much more beautiful than I thought it would. I knew that the mesquite is beautiful wood, but I had no idea it would look like this. I definitely have to make more of these.

Click on any picture to see the full size image.

Carving a spoon, Part 1

One benefit of all the tree pruning I did last month is I got a lot of potential carving material. I also got a lot of firewood and an impressive collection of smaller stuff that I need to burn or mulch, but like anything else I have to take the bad with the good.

As I was cutting up the bigger pieces for firewood, I put several aside for potential carving projects. This one said “spoon” to me.

It’s a piece of mesquite, about 12 inches long and around two inches thick down there at the left end. The limb it came from had been hanging dead on the tree for a couple of years.

The first step in making my spoon involved removing the bark. I did that with my Buck hunting knife, since that’s what I had at hand.

One of the things I like most about “found wood” projects (as opposed to buying a block of kiln dried wood from a store) is trying to make use of the log’s features: knots, worm holes, rotted sections, grain, coloring, etc. This piece has a lot of irregularities that make it quite interesting. Unfortunately, my photography doesn’t do justice to the potential I could see in this piece of wood.

With the bark off, I went inside to draw a rough outline of the spoon on the wood. This doesn’t have to be real detailed and I don’t have to set the final shape in stone right now. But it’s good to get a better idea of what I’m aiming to create.

That was a pretty poor picture in bad lighting. I enhanced it as well as I could. It gets the point across. The bowl of the spoon will be on the left in this picture. I’ll take off that protruding limb. The handle, too, will be trimmed quite a bit.

I rather like whittling sometimes, but when I want to create something, I don’t much like spending my time whittling away many cubic inches of waste wood. That’s what saws are for. A bandsaw would make quick work of cutting away the excess, but it takes a bit of time to pull it out and set it up. Especially since right now I have a very large and aggressive blade on it. I opted to use the coping saw with a coarse blade.

Here’s the spoon cutout to its (very) rough shape.

I goofed a bit with the saw, cutting away a little more than I had planned where the handle meets the bowl. It shouldn’t cause a problem. This spoon is intended to be a bit irregular anyway, so I can probably hide the goof as part of the “primitive” look.

The rest is edge tools: knives and gouges. Shaping the outside of the bowl always takes longer than I expect because a lot of it involves cutting the end grain. And I always end up taking away more wood than I thought I would have to in order to make it look right.

This isn’t the final shape, but it’s close. Note that the bowl is considerably smaller than what I drew. I’ve rough shaped the handle, but there’s still quite a bit of work left there. Still, the major work on the outside of the bowl is done.

The above, from when I took the first picture until the last, was about four hours’ work–most of it spent shaping the bowl after cutting the rough outline with the coping saw. That mesquite is pretty hard wood, which means taking small bites and stropping the knife blade very often.

The fun part (for varying definitions of “fun”) is hollowing out the bowl. I have a couple of small spoon gouges that are great for small spoons and detail work for the larger spoons, but the only tool I have for taking big chunks is a #9 gouge that’s about 3/8″ wide. It’s a good sharp tool, though, and it makes pretty quick work of the roughing out the bowl. I’m ordering a hook knife, which should speed the process quite a bit and also allow me to do a somewhat better job.

Hollowing the bowl took a lot of time. I spent two to three hours on it over a 3-day period. I finished that last night, and also put the final touches on shaping the handle. Here’s the result, ready for sanding.

Finished, this spoon should be quite beautiful with the different colors and the grain. It will make a nice serving spoon for soup, or perhaps a scoop for dry goods. I’ll post better pictures once it’s finished.

Photos of the finished spoon are here.

I’ve been told that scrapers are a good alternative to sanding. I haven’t tried them yet, but I’ve been impressed with the results I’ve seen from others. I think a set of scrapers will be my next purchase after the hook knife. Assuming, of course, that I continue making these larger spoons.

Categories

A sample text widget

Etiam pulvinar consectetur dolor sed malesuada. Ut convallis euismod dolor nec pretium. Nunc ut tristique massa.

Nam sodales mi vitae dolor ullamcorper et vulputate enim accumsan. Morbi orci magna, tincidunt vitae molestie nec, molestie at mi. Nulla nulla lorem, suscipit in posuere in, interdum non magna.