Lessons From History Discussion

Can the history of GoTo and other older ideas be used to predict the future or make decisions about current language features?

(moved from HowImportantIsLeanCode)

[...Closure example elided...]

You may want to read LessonsFromHistoryDiscussionSummary before getting sucked into this ...

What Did and Didn't Goto's Teach Us?

The lessons from Goto's seem to be:

Unanswered questions:

This summary is intended to help find points of interest in the following sprawling mess. It is almost deliberately wrong ...

Now read on ...

Closures are one of those things that look cool on paper, but are difficult to translate into significant practical benefits. They're borderline MentalMasturbation in my opinion.

Structured programming is one of those things that looks cool on paper, but is difficult to translate into significant practical benefits. It's borderline MentalMasturbation in my opinion.

High-level languages (like FORTRAN and COBOL) are one of those things that look cool on paper, but are difficult to translate into significant practical benefits. They're borderline MentalMasturbation in my opinion.

GOTOs and assembly language are good enough for me. Are they good enough for you?

Assembly is more lines/volume of code per algorithm, and GoTo's are more inconsistent across programmers and lack the visual flow cues of indentation. Anyhow, rather than get into yet another general paradigm HolyWar, how about we focus on the above example. How would closures clearly make it better?

My point was broader, and perhaps more subtle, than to suggest we should stick to GOTOs and assembly. Back in the day, GoTos and structured programming were the subject of considerable debate. From a historical perspective, we can see that the higher-level abstractions gained preference for what we now consider obvious reasons, and (at least) structured programming and high level languages now seem reasonable choices for most purposes. At the time, however, the need for higher level abstractions was much less clear than it is now -- the goals of most programming were much simpler, and a GOTO or two for the average working programmer seemed as reasonable as the structured equivalent.

As such, the choice between GOTOs and structured programming -- or between assembly language and high level languages -- was often more a matter of personal preference (or psychology, as you put it) than rationally-based decision. That may seem surprising or illogical now, but keep in mind the context of the time.

Your frequent arguments against closures, functional programming, object-oriented programming, and so forth remind me of these classical debates.

At present, typical programming tasks do not yet need any higher level abstraction than procedural programming. Or, at least in the domains in which you work (and perhaps the domains in which most of us work), that is probably true. Whether we use a higher level of abstraction or not is more a matter of personal preference than rationally-based decision -- just as GOTOs and structure programming were once as much personal preference (or sheer weight of familiarity) as rational decision.

Therefore, there is probably little point in deprecating someone's preferences, whether they're a choice of higher abstractions -- such as closures, HOFs, etc. -- or a preferred choice of ice cream flavour. History shows us that no amount of railing against structured programming or high level languages had any significant effect. You may find it much more effective to devote your efforts to illustrating how delicious your ice cream flavour is -- i.e., show us how powerful pure procedural programming can be -- rather than continuing your persistent and poorly-defended pokes at how yucky other ice cream flavours -- closures, functional programming, object-oriented programming -- are.

I am concerned that some people are getting hung up on the idea that everything needs clear, objective, unassailable and compelling evidence before it gets made widely available.

If the telephone was invented today it would never make it.

I submit that some things need to be widely tried by non-experts and by people other than those who really understand it, to find its strengths and weaknesses, to find where it's useful and where it isn't, and to work out how to make the good bits work better, and the bad bits either irrelevant, improved, or missing.

If you don't think OOP is worth anything, if you don't think closures are worth anything, if you need hard, compelling, objective evidence for everything, then please, offer me hard, compelling and objective evidence that closures are of no real value.

So we throw crap out there and hype it as if its a given, then see what sticks? Generally there's a ratio of roughly about 10 dropped ideas for every 1 that sticks. That means we are wasting 9/10ths of our time on lame fads. That does not seem rational. Nor does it address the psychology issue: some like OO because it fits their head and some don't. Is this the right-handed argument: lefties should suffer because they are the minority? (And OO given more lip service than code service anyhow. People like it in pre-packaged libraries, but their custom app code is still mostly procedural.) It does not appear that you've explored the larger-scale ramifications of your "system" of fad-pumping here.

Let's Go To Goto's Again

I think the spirit of this debate has gotten lost. Let me restate it:

Almost nobody supports going back to the pre-nested block era. Although some support limited forms of goto's, most agree that using mostly nested blocks "improves" software. However, even something this simple and with a universal consensus has no non-psychology-tied evidence to support it. If we cannot provide objective evidence for simple things, then there's almost no hope of providing it for complex claims. What is the reason for this?

My standing theory for this is that software engineering is mostly about human and personal psychology. It's possible an alien species may dig goto's. So far, other than "we're all too new at such proof techniques", nobody has offered a compelling alternative to this Goto-Paradox. --top


CategoryDiscussion, CategoryEvidence

View edit of May 1, 2008 or FindPage with title or text search