This blog has been silent for a couple months, but the news I have to share is well worth breaking that peaceful quiet :) I’ve been living in Tacoma Washington since I graduated college, and I am really loving the area. Surrounded by water, two mountain ranges in sight, green all year… it really is beautiful. The only downside of the area, while having more than a few technical companies, lacks a “tech scene.” This is thankfully starting to change with the introduction of Tacoma’s first Tech Meetup earlier this month (thanks to Erik Emery for setting that up!), and strengthened by a collaborative effort between Scott Kuehn, Michael Maitlin, and myself. That effort being…
The First Annual Barcamp Tacoma!
Barcamp is labeled as an “un-conference,” where people come together and talk about whatever it is they feel like discussing. Or, from the Barcamp.org website:
BarCamp is an ad-hoc gathering born from the desire for people to share and learn in an open environment. It is an intense event with discussions, demos and interaction from participants who are the main actors of the event.
We’ve had some help getting a space to hold the event from Suite 133, a local collaborative workspace, and with that locked down we also have a date: August 8th, 2009. The event is free (food and drinks included!), and if we have enough sponsors we’ll be trying to lock down t-shirts for everyone as well.
On behalf of myself and the other hosts, we really hope you are all able to come help us make Tacoma’s first barcamp a success. Check out the site for all the details, and be sure to sign up so we know how much food to pack. If you don’t know what you would talk about, we’ve created a page with presentation topics we would love to hear about. Share what you know, even if you don’t consider yourself an expert. All we care about is sharing information, everything else is just icing :)
Hope to see you all there!
GOTO is a statement all programmers know. Most of us are too young to have ever actually used it, but anyone with a formal education has been provided with GOTO as an example of the worst enabler of ’spaghetti code.’ So after accepting that something called GOTO is bad, we return to thinking about what we’ll do after class. But why, WHY is GOTO gone?
The disappearance of GOTO can be attributed to multiple factors, most of them well presented by the famous Edsger Dijkstra back in freaking 1968 in a letter to the editor of “Communications of the ACM.” He made some humorous points, such as “the quality of programmers is a decreasing function of the density of ‘go to’ statements in the programs they produce.” Maybe I’m further gone than most (run while you can!), but it made me chuckle. The main points that he was trying to convey however are less humorous: GOTO makes it harder to ‘prove’ programs[1], removes the ability for a programmer to determine the progress of the program in execution[2], and that GOTO is just too primitive of a statement.
After some jokes among computer scientists (see COME FROM – yes, our sense of humor is in need of calibration), GOTO really did start to disappear. Most major language designs lacked official GOTO reserved words, and others like ADA included it using a syntax unique only to that statement so it may be easily found in programs. This disappearance is only surface deep, however.
It turns out that while an unbounded GOTO may result in obnoxious and nondeterministic code, the ability to jump to a segment of code outside the normal flow of execution is pretty handy. ‘Case’ statements are a popular implementation of a restricted GOTO, with one conditional evaluation resulting in a jump to one of many locations in code. More importantly, error handling would be near impossible to implement without the concepts on which GOTO was founded.
Unless the developer is an idiot, error handling is implemented as a catch in case something unexpected happens (I’ve seen it used as part of normal execution, ick). When something unexpected happens, you can no longer depend on the state of execution within the program. In this case, using a GOTO is the only way to break away from whatever caused the error and make some attempt to either rectify it or exit cleanly. Even the parody COME FROM statement has a hidden usage. In debugging, the concepts in which the COME FROM statement was founded are used to handle breakpoints.
So GOTO isn’t really dead, it is just hidden and stripped of its freedom. And more importantly, it can’t die. We rely on its concepts far too much in structured programming to do away with it. Now that you know, spread the word that GOTOs aren’t inherently bad! They are like kids: they just need boundaries.
[1] Loops and conditional statements, and of course functions, can all be reduced to formal mathematical language. Especially when converted to their recursive forms, loops are incredibly easy to prove as being valid with induction. GOTO statements broke this by making code execution able to change state at any time, greatly reducing the ease in which algorithms could be reduced to and proven with math.
[2] Some people might say “hey, loops are kind of like GOTOs. What is the difference?” Or maybe not, but here is the difference anyway. As pointed out by Dijkstra, loops are able to have some index applied to their current iteration or state in recursion (think for(int i=0; i<end; i++) – i is the index). This allows the programmer to have definite knowledge of the state of execution through using multiple indexes as “coordinates.” With a GOTO, this idea breaks because it is trivial to jump to anywhere in the program at any time, making the current indexes useless.
