Decent Study Of Goto Productivity

The issue of how best to study the "goto versus blocks" issue without relying on personal introspection.

Re: "because you think there is no such thing as objective evidence when it comes to programming."

100% objective? Maybe not. However, a productivity study could be a "good" study, in terms of economic utility. For example, get say 10 actual projects, 3 experienced goto programmers and 3 block experienced programmers for each project and have each team program each of the 10 projects and make say 5 years worth of modifications based on the actual project history. (It wouldn't take 5 years because we are doing them all at once rather than spread out.) Thus, there would be 20 groups (10 projects with one goto team and one block team) and a total of 60 programmers (3 people x 2 teams x 10 projects). At least 3 different languages should probably be used to avoid language bias. Then score time taken and the number and severity of bugs (judges would not know which team type, only the result of the bug).

Now that could be a "good" study. "Objective"? I am not sure because we may be just testing human psychology. That gets into the definition of "objective". ("Objective study of psychology" can be contradictory because psychology is often the study of subjectivity.) However, I'd consider such a useful study. But you ain't got notin' like that to present. -t

You can prove something a lot quicker using logical reasoning, which was done with notes on structured programming decades ago. Since the logical reasoning was so strong in structured programming, structured programming won - and nobody ever needed to do lab experiments with goto. That's one advantage of math vs science - math, and much of programming, can be proven using proofs and reasoning - whereas science (study of the natural universe) requires more tedious experiments. In math, one does not test to make sure that 100 + 100 = 200 (how can we be sure? what about 103 + 108? how do we know it is still going to add up correctly? rhetorical questions). In science, one would have to test this to be sure, since the universe is a complex odd place and not everything is straightforward in the universe. In math, we can easily prove it in a general way, whereas science isn't so general. The relational model was another example, like structured programming, which Won due to logical reasoning - not lab experiments. It has nothing to do with psychology and everything to do with logical reasoning. Why would it be psychology anyway, and not psychiatry? But yes you could do lab experiments proving the productivity of structured programming over the less productive goto - the reason these experiments are not done, is because a person would have to be a complete ignoramus to think that goto programming is as maintainable as structured programming. The reason someone would waste money performing these experiments is because they haven't read notes on structured programming, and they didn't understand the logical reasoning in the said articles.

Bull! The "logical" reasoning was not strong. Reasoning about goto's or queries takes place in the human mind, not in machines and not on math paper. Some of those papers don't explicitly state it (bad form), but for the most part they are assuming a model of the human mind. The human mind is incredibly complex and diverse. There is no road-tested accurate model of the human mind to date. Somebody may create an "elegant" model of human reasoning, but an elegant model is not necessarily the same as an accurate model. Blocks (structured programming) and relational become popular largely because programmers and/or power-users liked it, not because good proofs were made. Related: HistoryOfRelational

Re: "In math, one does not test to make sure that 100 + 100 = 200"

Productivity is not pure math. And we CAN test that 100 pebbles + 100 pebbles = 200 pebbles. And we can test it on a variety of items to strengthen the case. Thus, there is a road to empiricism in this case.

Would you fly a crew to the moon without test flights, relying entirely on a simulation? "But God, it's all good on paper, look! Please unkill the astronauts for me, the model is right, dammit!"

It turns out that this is also a very good example of ItDepends at the same time as being a good example of very near objective evidence. The counter-example of when goto statements improve productivity isn't likely to come up in something like this because the situation is rare. A direct threaded finite state machine can only be realized as a pile of goto statements and is in certain rare conditions (say hand-coded lexer) the correct code structure for the task at hand. And yes, there are good reasons to write hand-coded lexers. --BottomMind