To goto or to not goto? – At first glance

Most of the languages in use today, do indeed have the gotostatement. As we do already know, the goto statement is used to unconditionally jump from place to place within a program, with destinations marked as labels. As you can already guess, this can make a program really hard to read, with its particularlyjumpy nature. The programmer, with all his wits, could well have written a perfectly unambiguous program, but what about his code? Sure ; he knows all about his own program, and is in a position to debug it and make changes, but what about debugging, when it comes to a team environment? While our smart programmer is on leave in Hawaii, rewarded for his hard work, how miserable life will be for his coworkers!
Oh, and did I mention the program had 352 goto statements?

In the days of the structured programmer, the goto statement was a very powerful tool in the hands of a very powerful programmer. His days, however, are no more. Neither him nor his tool are powerful anymore. However, it would be wrong to say that the goto statement does not have any application in high level programming. While some high level languages, like Java do not support the statement, other languages such as C#.NET continue to allow it ; and it proves to be useful in causing fall-throughs in switch-case blocks.

The popular saying among many, so-called high level programmers is, “Never use GOTO statements” ; but this need not be completely true. However, there have been several great computer scientists, whose work has formed the base for what most of computer science is today, have sternly voiced their concerns against the goto statement. The most popular of such cases is Edsger W. Dijkstra’s letter to Communications of the Assosciation for Computing Machinery in 1968, titled A case against the go to statement. (here)

Since a number of years I am familiar with the observation that the quality of programmers is a decreasing function of the density of go to statements in the programs they produce. Later I discovered why the use of the go to statement has such disastrous effects and did I become convinced that the go to statement should be abolished from all “higher level” programming languages (i.e. everything except –perhaps- plain machine code).

In reality, goto statements belong to assembly language code, where the program, has no other option, but to jump (conditionally or unconditionally) to memory locations, specified explicitly in the program itself. When structural programming was programmer fashion, the goto statement, as I already mentioned was a very powerful tool; but this was before thewhile and for loop even came into existence. Now, with better options at hand which were not available at earlier times, we must strive to do whatever we can to make our programs easier to manage, read and debug – we must strive to make our programs more high-level.

The go to statement as it stands is just too primitive, it is too much an invitation to make a mess of one’s program.

The use of the word mess, in my opinion is quite apt. Imagine a program with 352 goto statements. You’re probably going to spend more than half of your office hours scrolling up and down, trying to locate the labels, and make sense of what the program actually does. (And I’d sincerely hope you’re not using the vi text editor.) Owing to this seemingly random flow of controlbetween various statements, programs that use too many gotostatements earn the “Spaghetti Code” nickname, which falls very short of a complement.

So why would you use a goto statement anyway? It is also a proven fact that every goto statement can be replaced with a suitable implementation of a set of looping constructs. (except for the fall through case in switch blocks I mentioned earlier). The reason for this is probably, that most programmers think (or like to think) in the way a computer thinks; executing a set of statements, and jumping to a new set of statements when a branching instruction is encountered. In a way, this is what dividing your programs into methods/functions also achieves, but it is much easier to manage code.

So, to conclude, to not go to is a much more sensible decision.

Leave a Comment

Chrome Experiments (Not your mother’s JavaScript)

Google Chrome (Google Chromium) is an internet browser (just like Internet Explorer and Mozilla Firefox) that is popular for it’s speed and simplicity. Though it doesn’t yet support plugins, for which Firefox has extensive support, it is widely acclaimed and used.

ChromeExperiments.com is one site each and every Chrome fan must visit. It is a set of so called “Chrome Experiments”, that showcase just how powerful the browser is. Thse are programs written primarily in JavaScript and Flash that show how effectively and smoothly they run with Chrome. Many programs (such as one which writes your name over New York City) show how the browser seemlessly handles tens of hundreds of objects (lines, shapes, etc.) that are created dynamically, and animated. Another application, called “Google Gravity” is also very interesting. The classic Google homepage succumbs to gravity and falls! You can then move around individual parts, brush them against others, and see all the movement with very realistic physics. You could grab the “I’m ready” button and swing it into the “Business Solutions” link, and see it flying away! There are tens of more such interesting applications.

Most of these programs can even be run from other browsers. But there are some that only Chrome can run. For example, there is one application in which a ball jumps across multiple windows of the browsers. It’s fascinating to watch, and is only supported by Chrome.

Not that a ball bouncing across windows is of any real utility, but still Chrome has something special to it, as usual!

Comments (1)

Is the coffee cup getting colder?

Is Java better that .NET? Yes? No? Maybe? Well, it’s quite futile to argue about this issue without strong reasoning. We’ll rule out the “in-depth-analysis” method of reasoning for now (we’ll pick that up later). For now, let’s just compare how both environments perform similar tasks. Piyush Sahay (piyushsahay@live.in) joins me in conducting various tests to do the same.

Since the C# compiler (and every other .NET language’s compiler) converts the written program into MSIL (Microsoft Intermediate Language), it’s perfectly accurate to say that comparing  a program written in VB.NET with one in Java is same as comparing the latter with a C#.NET program. What I’m trying to say, is that the difference is actually between the environments (Java and .NET), and we’re not concerned about any differences the two languages may have.

For all tests, unless otherwise specified, we use .NET Framework 3.5 SP1 and Java SE 6 for our comparisons. We used command line compilers for both Java and C# (just incase any of the IDEs would want to earn a good name by automatically refactoring our code). All tests were performed with the same laptop (rather slow, but that doesn’t make a difference in this case), running Windows XP Service Pack 3.

The following are the tests that have been performed, and are part of this series.

  1. Looping and printing till 1,00,000 (.NET wins)
  2. Bubble sort of 1000 elements (worst case, and worst algorithm) (.NET wins with big margin)
  3. Drawing a hell lot of stuff (Java wins with extraordinary margin)
  4. Adding controls to window (Java wins)

Leave a Comment

My first post

Hello everyone. Practically, in a way atleast, this is the first blog I’m ever writing for. I did own another one over at http://www.withdotnet.blogspot.com, but I couldn’t really fit in that well with Blogger. It has all the features one needs to create a host a blog with just a few mouse clicks; yet, I find WordPress, which I’ve been using for around 28 minutes, much better.

If my decision to shift to WordPress was wise or not, only time can tell. Or maybe you can too?

I’ll be keeping this blog posted as frequently as possible (not, however, more than 2 times a week) on stuff related to programming. I myself am a .NET enthusiast, but plan to also learn Java in the near future. I have, for quite some time now, been almost “Anti-Java” and “Anti-Goto”, but I’ll be doing a lot of research before posting about any of my opinions.

So, stay tuned for more articles, all of which I guarantee to be better than the one you’ve just finished reading!

Leave a Comment