Archive for the ‘Voices’ Category

Blogger Day of Silence

Friday, June 8th, 2012

Ace called for today to be a Day of Silence. Given my infrequent postings, I don’t know how anyone could tell whether or not I’m participating.

In any case, the purpose is to highlight the actions of Brett Kimberlin and his associates, and to call on Congress to take action to prevent the suppression of free speech intended by these actions.

Just to make it clear, I’m joining the effort.

For Veteran’s Day

Friday, November 11th, 2011

I’ve posted this before (not on Veteran’s Day), but it’s worth posting again:

A veteran is someone who, at one point, wrote a blank check made payable to ‘The United States of America ‘ for an amount of ‘up to and including their life.’

I’ve been corrected

Friday, November 4th, 2011

A couple of years ago, I reminisced about the early days of personal computing.

Yesterday, a comment showed up on that post, pointing out that one of my memories wasn’t accurate, from the pioneer in the field who was involved.

Nice.

Ten years ago

Sunday, September 11th, 2011

I was at work when a coworker said an airplane had crashed into the World Trade Center. After it became apparent that this was something serious, I went home and brought in a small portable TV to set up in the lunch room.

I don’t know how much work actually got done that day; I spent much of it watching what was happening. There’s a saying that goes like this: Once is happenstance, and twice is coincidence, but three times is enemy action. When the second plane struck the towers, I said immediately that this was war. The Pentagon was the third strike, but there was no way that what was happening was anything but a result of deliberate actions.

The Pentagon was also my closest brush to a direct connection to the attacks; my father, although retired from both the Air Force and the civil service, had worked in the Pentagon before retirement and still went almost daily to take advantage of their fitness facilities. It was four days before I could verify that he hadn’t been anywhere near the Pentagon at the time of the attack.

I could fill this post with links to the words of those who have said things with which I agree in much better ways than I can or have, but what’s the point? I would either be preaching to the choir or convincing you that I’m deranged and dangerous. I will suggest that you read Blackfive’s post about Rick Rescorla, and sign the petition he links to, if you’re so inclined.

He must like the taste of his feet

Thursday, June 9th, 2011

He’s had them in his mouth so often.

Memorial Day

Monday, May 30th, 2011

There was a video I wanted to post for today, but I couldn’t track it down. Perhaps I’ll find it in time for Veteran’s Day. Since I couldn’t find it, I’ll repost some past Memorial Day items.

First, a poem Robert Service wrote after World War I:

PILGRIMS

For oh, when the war will be over
We’ll go and we’ll look for our dead;
We’ll go when the bee’s on the clover,
And the plume of the poppy is red:
We’ll go when the year’s at its gayest,
When meadows are laughing with flow’rs;
And there where the crosses are greyest,
We’ll seek for the cross that is ours.

For they cry to us: Friends, we are lonely,
A-weary the night and the day;
But come in the blossom-time only,
Come when our graves will be gay:
When daffodils all are a-blowing,
And larks are a-thrilling the skies,
Oh, come with the hearts of you glowing,
And the joy of the Spring in your eyes.

But never, oh, never come sighing,
For ours was the Splendid Release;
And oh, but ’twas joy in the dying
To know we were winning you Peace!
So come when the valleys are sheening,
And fledged with the promise of grain;
And here where our graves will be greening,
Just smile and be happy again.
And so, when the war will be over,
We’ll seek for the Wonderful One;
And maiden will look for her lover,
And mother will look for her son;
And there will be end to our grieving,
And gladness will gleam over loss,
As – glory beyond all believing!
We point … to a name on a cross.

And remember, when you think of those who gave their all for their country:

A veteran is someone who, at one point, wrote a blank check made payable to ‘The United States of America ‘ for an amount of ‘up to and including their life.’

This looks familiar

Thursday, March 10th, 2011

William Woody has a post about developing Java code to implement the factorial function. More specifically, it’s about how not to. He starts with a very simple (and straightforward) implementation, then produces updated version after alternate version in order to handle various possible conditions that the code may need to support.

The operative word is “may.” He concludes the post with a discussion of appropriate pains to take in an implementation, as well as which requirements for a programming task are actual requirements. As he says,

So please, do us all a favor: if you have the urge to add complexity because “someday we’ll need it, I just know it!”, or because “it’s not sufficiently flexible enough” or “we need reusability in our code” or (God help us!) because it’s “cool”–just go home early.

I’ve not programmed in Java, but the points he makes are applicable no matter what the language. I believe that part of the problem is that there is a subgroup of programmers who aren’t happy unless they’re showing off how convoluted they can make their code. I remember a cartoon I saw, either in an issue of Forth Dimensions or in one of Leo Brodie’s books, Starting Forth or Thinking Forth. The cartoon shows two programmers in space looking at the Earth-Moon system. One, the Forth programmer, is saying, “No good – too complex.” The other, labeled, I believe, “Ada programmer,” is saying, “No good, too simple.”

I’ve worked with both types of programmer, and I’m currently maintaining a large piece of code written over a decade ago by one of the “no good, too simple” types. He came from a background in academia, and felt that his MSCS made him more qualified to define application requirements and design products than the combined 30 or so years experience in the field that my boss and I had at the time, because neither of us had a Master’s degree.

It’s pretty hard to figure out what any given piece of code in that application does, because nothing is simple and straightforward. It’s all convoluted, indirect, and involved. It puts me in mind of a button I bought at an SF convention a few decades ago, which reads, “Never make anything simple and efficient when you can make it complex and wonderful.” As an example, the program maintains a pair of ring buffers. Conceptually, these are fairly simple and straightforward. There are some boundary conditions you need to be careful with, which are discussed at the link, but other than that, they’re easy.

In the software I’m maintaining, they were implemented as state machines with 64 states. Talk about violating Occam’s Razor! The C source file containing the implementation is 15k in size, with almost 600 lines of actual code. What comments there are in the file mostly relate to the encoding and meaning of the state numbers – very little of the code has descriptive comments stating what the code is doing.

Years ago, I ran across the statement that the fastest-executing and most bug-free code in a system is the code that isn’t there. That made tremendous sense to me, and it’s why the ring-buffer implementation I just described offends my sensibilities so much. To me, it’s just intellectual masturbation. He wasn’t writing for efficiency, or for clarity, although I’ve no doubt he’d claim that that was exactly what he’d done. He was writing to show off, to himself if no-one else. There may have been some attempt at job-security-through-obfuscated-code going on, as well. If so, that didn’t work. After all, I’m maintaining his code, and have no idea where he is, nor where he’s been for years. Actually, although the comments in the file describe it as a “robust” ring-buffer implementation, I had to make a correction to it several years ago – there was a bug in his code (color me surprised) that caused a persistent error condition after a particular error occurred. The code, of course, couldn’t detect that it was in that particular error state. Eventually, though, a customer could.

I probably put more emphasis on clean and simple code than most programmers. It often ends up longer than other implementations, because I tend to ignore a number of advanced features of the language, unless the code is meant to demonstrate the use of that feature. This is because most of our customers aren’t programmers; they’re engineers who want to learn as little programming as necessary to get the job done, and the code I write has to serve a pedagogical purpose, as well as being useful. As a result, the code I write tends to be very simple with a lot of comments. Unfortunately, that doesn’t always mean it’s bug-free.

Coding style may be a matter of preference, but coding complexity, at least in this regard, is a matter of corporate culture. At a previous job developing dedicated word processors (that is, a computer system that could only do word processing), back in the early 1980s, I was at one point tasked with making an update to a particular piece of code. The code was designed to be incredibly efficient; it was written in an incredibly convoluted manner in order to minimize execution time. It took me three weeks to understand the code, after which the change took less than a day. Coincidentally, the original author had taken three weeks to write the code.

The convoluted code saved several milliseconds over what a naive implementation would have taken. It executed once during system startup. I suspect that you can guess my feelings about the efficiency of that module.

The author moved on to the “new product” project that the company started. Apart from a few supervisors, nobody in the “current product” group could move over to the new product group – they staffed it up with recent graduates who’d used Unix in school. That was their problem. Apart from the supervisors, several of whom were addicted to cleverness in their code, nobody working on the new product had ever delivered a product.

The current product line that was providing all the company’s income was based on 8086 hubs and 6800-based terminals (80×24 characters, IIRC, but they might have had larger displays). The new product under development was to be 68000-based, with a bit-mapped graphical display so that you could do WYSIWYG word processing. They gave us a product demonstration at one point. The system took somewhere between 30 and 90 seconds to come up (this was around 1983 when most personal computers were effectively instant-on, and even PC-XTs only took a few seconds to boot DOS), and the bug list was written ceiling-to-floor several times on butcher paper that covered one wall. One bug was that you couldn’t print – not a good thing for a word processor company’s upcoming flagship product.

This has been a long rant, but my point is largely the same as Mr. Woody’s: complexity for the sake of complexity, or for anticipated future needs, is a bad thing. My elaboration on that point is: make sure you’ve got someone who knows what needs to be done, and ruthlessly prevents unnecessary complexity.

It’s been a quiet day

Friday, November 12th, 2010

Which is nice for Veteran’s Day. Quiet gives you time for contemplation. Some good food for thought can be found at Blackfive – just keep scrolling down; there are several Veteran’s Day posts worth reading. I also like Bunk’s post about his grandfather in World War I.

Easier than doing it myself

Thursday, October 7th, 2010

I’d collected a number of links to various takes on the abhorrent 10:10 video, and had thought of doing a post rounding up the assorted reactions I’d come across.

Luckily for me, The Daily Bayonet has done exactly that, almost certainly better than I’d have managed.

It’s Constitution Day

Friday, September 17th, 2010

Senator Orrin Hatch and Joseph Stuart both have things to say about it that I think should be widely read.

Of course, I’m not sure how many people will go to the articles from here who wouldn’t have already seen them.