Nicht, wenn sie für legitime Zwecke Alternativen anbieten (Prozeduren, Zyklen, Exceptions, usw.)

In SpracheLava verzichten wir sowohl auf "goto", als auch auf herkömmliche Programmschleifen (und damit zugleich auch auf die Mehrfachzuweisung von Werten an (Schleifen- und andere) Variablen; Rekursion, Quantoren und Single-Assignment-Variablen treten an ihre Stelle. Und dies löst in der Tat ein Problem: Es ermöglicht die statische Analyse des Datenflusses, der in Lava streng "von oben nach unten" im Programmtext verläuft. Man kann also immer leicht feststellen, wo der Wert einer Variablen "herstammt", d. h. wo im Programm er der Variablen zugewiesen wird. Während der goto-Verzicht den Kontrollfluss übersichtlicher gemacht hat, vereinfachen diese weitergehenden Maßnahmen in SpracheLava darüber hinaus auch die Analyse und Verstehbarkeit des Datenflusses und ermöglichen damit zugleich eine strenge Kontrolle der Initialisierung von Variablen. (Siehe auch http://www.sit.fhg.de/Lava/LavaDoc/html/RepetComputSamples.htm).

Andererseits kann ein goto ein Programm auch einfacher und durchsichtiger machen, namentlich bei Programmverzweigungen (if/switch o. ä.), nämlich wenn in einigen Zweigen zuerst eine spezifische "Vorbehandlung" erfolgt, auf die dann eine für mehrere Zweige gemeinsame "Haupt-" oder "Abschlussbehandlung" folgt, die etwa nur im letzten dieser Zweige hingeschrieben wird, während man aus den übrigen dieser Zweige nach der "Vorbehandlung" mit goto dort hin springt.

Alternativ kann man natürlich die "Hauptbehandlung" auch in eine eigene Funktion stecken, die dann am Ende aller dieser Zweige aufgerufen wird, wodurch das goto wieder entbehrlich wird.

Diese Abspaltung der "Hauptbehandlung" ist jedoch besonders dann nicht sehr natürlich, wenn die "Hauptbehandlungs-Funktion" auf lokale Variablen der Aufrufumgebung zugreifen muss, die dann eigens als Parameter übermittelt werden müssen. Dies lässt sich wiederum etwa dadurch vermeiden, dass man die "Hauptbehandlung" als Makro statt als Funktion ausdrückt, und dieses Makro am Ende jedes Zweiges einsetzt.

Diese unschöne Parameter-Übergabe kann aber auch durch etwas mehr Objekt-Orientierung vermieden werden: Man deklariert eine neue Objekt-Klasse, deren Membervariablen gerade die bisherigen lokalen Variablen sind und macht die "Hauptbehandlung" zu einer (dann parameterlosen) Methode dieser Klasse, die mit einem entsprechenden Objekt aufgerufen wird.

Ich denke, dass z.B. das /BeispielMicrocontroller auf diese Weise 1. ohne goto auskäme und 2. zugleich in sehr kurze, wesentlich übersichtlichere Teile (Verzweigungslogik, spezifische Vor- und gemeinsame Hauptbehandlungen) aufgegliedert werden könnte. Es ist eine andere Frage, ob die extremen Einschränkungen der Mikro-Controller-Programmierung eventuell zu einem mehr assembler-nahen Programmierstil mit vielen goto's und wenigen Functions zwingt.

Siehe Diskussionsbeitrag in news:comp.object

Explizit sichtbare Makros gefallen mir deshalb nicht, weil sie ja eigentlich auf einer metasprachlichen Programmier-Ebene angesiedelt sind, wo sie beschreiben, wie der eigentliche Programmtext durch Operationen auf der makrosprachlichen Ebene erzeugt wird. Diese zwei Sprachebenen machen Programme nicht gerade übersichtlicher, leichter verstehbar und automatisch analysierbar (letzteres z.B. um die korrekte Initialisierung von Variablen zu überprüfen).

Anstelle einer Makrosprache würde ich in SpracheLava lieber den dortigen Struktureditor für ausführbaren Code so ausbauen, dass er das Benennen und das wiederverwendende Referieren von Code-Passagen in besonderer Weise unterstützt, so dass die referierten Passagen an der Referenzstelle (wo bei Makro-Verwendung nur der Makro-Aufruf stünde) direkt "eingeblendet" wird. Die gleiche Idee könnte darüber hinaus auch für eine Technik der "inkrementellen Spezialisierung" von Klassen-Methoden verwendet werden (siehe den entsprechenden Abschnitt in meinem Artikel http://www.sigs-datacom.de/sd/publications/pub_article_show.htm?&AID=442&TABLE=sd_article im OBJEKTspektrum.)

Generell sehe ich herkömmliche Programmvariablen und goto als begriffliche Relikte aus der Zeit der Assembler-Programmierung (adressierbare Speicherplätze, Instruction-Counter (IC), Sprungbefehle, die den IC auf eine neue Befehlsadresse setzen). Die experimentelle SpracheLava kann als Versuch vertanden werden, diese Relikte vollständig durch mehr mathematisch-logische Begriffe zu ersetzen: Lava-Variablen sind keine adressierbaren Speicherplätze mit wechselndem Inhalt, sondern "Unbestimmte" im mathematischen Sinn, deren mögliche Werte durch automatisch auswertbare/ausführbare mathematisch/logische Bedingungen spezifiziert werden. Schleifen werden teils durch Rekursion, teils durch All- und Existenz-Quantoren ersetzt. Lava soll demonstrieren, dass dies auf intuitiv eingängige Weise machbar ist, ohne dem Programmierer allzu viel Umdenken und Lernaufwand abzuverlangen.

--KlausGünther

Soweit ich das verstehe, wendet sich GoToConsideredHarmful gar nicht unbedingt gegen jegliche Verwendung von goto, sondern nur gegen die undisziplinierte, z. B. um unkontrolliert in Blöcke hineinzuspringen etc. (man denke an frühe Basic-Programme, die man verbrochen hat ... ;)

Genau genommen gibt es ja in vielen Sprachen wie z. B. der SpracheJava auch noch "abgespeckte" goto Befehle (break/continue o. ä.), die halt die Änderung des Kontrollflusses nur in ganz bestimmten Dimensionen zulassen. -- IljaPreuß

"[...] wendet sich GoToConsideredHarmful gar nicht unbedingt gegen jegliche Verwendung von goto, sondern nur [...]": Dijkstra wendet sich sehr wohl gegen jegliche Verwendung, er schreibt "[...], and I became convinced that the go to statement should be abolished from all 'higher level' programming languages [...]." -- VolkerGlave

aber auch:

"The unbridled use of the go to statement has an immediate consequence that it becomes terribly hard to find a meaningful set of coordinates in which to describe the process progress. [...] 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. One can regard and appreciate the clauses considered as bridling its use. I do not claim that the clauses mentioned are exhaustive in the sense that they will satisfy all needs, but whatever clauses are suggested (e.g. abortion clauses) they should satisfy the requirement that a programmer independent coordinate system can be maintained to describe the process in a helpful and manageable way."

Mir scheint daher, dass er nicht gegen das goto statement ist, weil er dessen Verwendung grundsätzlich für falsch hält, sondern weil er die Versuchung für zu groß hält, es "falsch" einzusetzen. -- IljaPreuß

Bin ich bescheuert? Ist das Englisch zu hoch für mich? Ich lass mir jetzt mal den entscheidenden Teilsatz "[...] I discovered why the use of the go to statement has such disastrous effects, and I became convinced that the go to statement should be abolished from all 'higher level' programming languages [...]." mit WorldLingo vom Englischen ins Deutsche übersetzen. Statt "the go to statement" schreib ich "snow", um es dem Übersetzer leichter zu machen. "higher level" lass ich weg, das können wir uns dazudenken. Übersetzungskategorie: "Computers/IT". Ergebnis: "Ich entdeckte, warum der Gebrauch des Schnees solche verhängnisvolle Effekte hat, und ich wurde überzeugt, daß Schnee von allen Programmiersprachen abgeschaffen werden sollte." -/- Mithin bleibe ich bei meiner Überzeugung, dass Dijkstra für die Abschaffung von "goto" bei Hochsprachen plädiert, womit logischerweise "jegliche Verwendung" nicht nur erschwert, sondern gänzlich verunmöglicht ist. -/- Dijkstras Kommentar ""The unbridled use ..." bezieht sich auf (existente) Sprachen, die "goto" faktisch haben, bei denen er seine Beobachtungen ja gerade eben erst gewinnen konnte und woraus die Kritik sich begründet. -- VolkerGlave

Sehe ich doch vollkommen genauso! Er ist für die Abschaffung von GoTo? in Hochsprachen, was dessen Verwendung dort unmöglich macht. Wir scheinen nur seine Motivation unterschiedlich zu interpretieren. Wie ich das verstehe ist er nicht gegen GoTo?, weil dessen Verwendung grundsätzlich schlecht ist, sondern weil es zu oft schlecht verwendet wird um die Vorteile der gelegentlichen "korrekten" Verwendung aufzuwiegen - zumal es für letzteres ausreichend Alternativen gibt. -- ip

Ich stimme zu. -- vgl

Ich habe mir das "goto" nie verboten, allerdings habe ich es in den letzten 10 Jahren auch nie gebraucht. Alternativen gibt es ja genügend: break, return und throw ersetzen "goto" in allen praktischen Fällen.

Geht mir auch so. In C++, Java, PHP brauchte ich goto nie. Wenn ich "goto" höre, dann denke ich an den guten alten C64 und meine ersten BASIC-Programme. Das waren Zeiten. 38kBytes free!!! ++ Und Assembler fällt mir ein, wo durch branch und jump ja ständig in der Gegend herumgesprungen werden MUSS. Assembler ist auch Steinzeit. Mir tun diejenigen leid, die 3D-Engines programmieren ;-) --DanielBrüßler

Aber bei solcher Gotteslästerung sollte man nicht vergessen: Hell's considered harmfull.

Beispiele

• /BeispielMicrocontroller

Da fällt mir ein, in der SpracheIntercal gibt es kein GOTO, aber dafür ein ComeFrom.

Hmm, Intercal? Kenne ich nicht. Wie funktioniert das dann? Etwa so?:

10 tue irgendwas
20 tue nochwas
30 tue etwas mehr

1000 come from 20

So daß man am Ende halt weiß, von wo der Kontrollfluss übergeben wird, aber dafür an der Stelle, wo der Kontrollfluß umgelenkt wird, nichts sieht?

Exakt. Dazu sollte vielleicht noch gesagt werden, dass Intercal absichtlich dazu entwickelt wurde, um das Programmieren so umständlich wie möglich zu machen.

Links:

• GoToConsideredHarmful
• DonaldKnuth Notes, http://logos.eecs.uic.edu/476/476 ProgLang Fall 01/notes/GoToKnuth.html