Archive for March, 2011

Nice stunt for St. Patrick’s Day

Saturday, March 19th, 2011

Via Ace.

Headline: 16 superheroes on streets of Britain

Friday, March 18th, 2011

As Dave Barry would say, I am not making this up. Somehow, though, I suspect that “costumed individuals” is a more accurate description than “superhero.”

Crud!

Tuesday, March 15th, 2011

So, I’ve managed to come down with the crud. I’ve barely moved off the couch for the last two days, and the congestion, coughs, and chills are not endearing themselves to me.

I haven’t done anything more strenuous than read – check that, I’ve had to throw the cats off of me a time or two – but I’ll leave you with a link to the best license plate/license plate holder combination. Evar. It’s nice to see that kind of flow from one to the other.

Old home week

Tuesday, March 15th, 2011

So, I’m staying at home today because I’m sick, and I’m watching a rerun of Junkyard Wars on the Science Channel. It’s an episode from 2002 in which the teams had to make hydrofoils, and it’s an episode I haven’t seen before.

Imagine my surprise when their judge turned out to be one of my old Naval Academy classmates, Pete Squicciarini.

You know you’ve been watching too many horror movies …

Thursday, March 10th, 2011

when you react to the clichés.

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.

Glad to have missed the trouble

Thursday, March 10th, 2011

I’ve had some trouble getting my mind in a state to write about this, and it’s no longer all that timely.

I’m glad that the troubles in Egypt and Jordan didn’t get going until after Marion and I had returned from our trip. Apparently, the first incident (in Tunisia) occurred a couple of days after we arrived in Egypt, but we’d finished our tour before it spread to Egypt or Jordan.

I’m not going to recap the entire tour, but here are some of the things that stuck with me:

It was a marvelous tour; besides sights I’d heard of all my life, like the Giza Pyramids and Abu Simbel, we saw things I’d never heard of before looking at the tour schedule, and learned a lot I hadn’t known. I came back with a few thousand photographs, which I’m still going through. I wasn’t the most prolific photographer on the tour, either. I kept a log of what we did day-by-day, so I can associate the photos with what was happening. After a while, many of the temples tend to run together, so you need something to help keep track (“Was that the Temple of Isis at Philaea, or the Temple of Edfu?”). I also took photos of the admission tickets, which helps keep track of what was what.

We got in a day before the tour group met, just in case we had problems getting there, so we had a day to ourselves in Cairo. We ate lunch at a small restaurant in Tahrir Square – in the photo of Tahrir Square in this article, the restaurant is just off the right side of the photo. Or maybe it’s just inside the right side; it’s kind of hard to tell.

Pretty much everyone in Egypt was friendly. Sometimes, too friendly – some days, it seemed like just about everyone you met was a pushy con man. That first day in Cairo, we had someone try to run the “I’ve got a friend at the government store; there’s a sale there today” scam not more than an hour after I’d read about it in our guide book.

I had my pocket picked while visiting the pyramids. I guess the small black Moleskine notebook looked like a wallet or a checkbook. The tragedy there was that it contained my day-by-day notes from the Galapagos/Ecuador trip we took two years ago, so I’ve lost those. It also contained the first couple of day’s notes from Egypt, but I was able to reconstruct those, since visiting the pyramids was the first stop on the tour.

I hadn’t realized just how close the pyramids are to town; Giza and Cairo grew together over the years, so they’re now part of a single metro area, and the pyramids are right on the west edge of town. Our guide told us that Egypt had a population of about 80 million, and 22 million of them lived in the greater Cairo area. I can believe that – the traffic certainly suggested it. Heading from the airport to our hotel in the tour group’s van, there were five lanes of bumper-to-bumper traffic at one point, with motorcycles and scooters advancing between the lines of cars. This was on a road with three lanes marked for traffic. Crossing the street was not for the faint of heart.

Abu Simbel was tremendously impressive, not just for what it was, but for the engineering effort put into saving it from Lake Nassar when the High Aswan Dam was built. The massive temples were cut into pieces and moved away, after which the area it had been removed from was built up. The temples were then put back into place, 64 meters above where they’d originally been. There is a sanctuary in the main temple that the sun lights up two days per year – it’s now lit up one day later than it had been lit up before, which shows how closely it was restored to the original alignment.

Marion and I were the only ones in the tour group who took the optional tour in Aswan. We saw the unfinished obelisk, the High Aswan Dam, and the Temple of Isis at Philaea (“feelay”). The unfinished obelisk was impressive. It was abandoned before it was completely carved out of the quarry because it broke. It wasn’t found until 1922, because that part of the quarry had been covered in rubble. The Temple of Isis had been moved from an island that flooded to a nearby island. The High Aswan Dam is a dam – not much to say there.

Our hotel in Luxor was right across the street from the Luxor Temple. We didn’t tour it, though. We were two of the three people on the tour who went to Karnak, though, which was a pretty impressive sight. The third person said she went because, after seeing some photos of it, she realized that Karnak was what she thought of when she envisioned Egyptian ruins.

Jordan was a lot cleaner than Egypt. The people there were just as friendly, but nowhere near as pushy. Drivers actually obeyed traffic signals, even when there were no police around. Speaking of police and similar authority figures, Egypt’s highways were full of military checkpoints. We went through a lot of them when we went to the Sinai Peninsula, and normally, everyone on the tour would have had to show their passport. We didn’t have to, because our driver had a couple of current Cairo newspapers, which apparently sufficed to show that we weren’t dangerous spies or something. We saw sunrise from the top of Mt. Sinai on Christmas morning, which was beautiful, but pretty damned cold.

Metal detectors were a bugaboo for me during the first part of the trip – I got the naked scan and a patdown at the airport when we left, I got a patdown after going through the metal detector at Saladin’s Citadel, and we had to go through a metal detector and bag inspection at the foot of Mt. Sinai before they’d let us climb the mountain.

Everyone on the tour got sick at one point or another. For most of us, it was the normal “tourist trots.” I got them when we were in Wadi Rum in Jordan. The person who got it worst came down with amoebic dysentery while we were in Aswan. She had to stay overnight in the hospital; I’ve got a photo of some dirt floor outside her fourth floor room.

There’s a marvelous bakery that has stores in Amman, Jordan and Jerusalem. Among the things I brought back were two tins of goodies, one of which is not sold online. Of course, my luggage took a detour in Frankfurt, Germany on the way back, and it took me ten days to get it. The luggage had split completely open, but they’d put it into a plastic bag, and nothing was missing.

I’m glad we went, and I’m glad that we missed the trouble. I think I’d be willing to visit Jordan again, but as for Egypt, I think it’s “been there, done that” for me. Sure, there’s more to see – for one thing, I’d have liked to be able to spend more time in the Cairo Museum, but I’ve seen the big stuff, and I’m not an Egyptologist. I don’t need to put up with the irritants in order to see more of the minor attractions.