2012-09-27T14:53:25 ?

Hab es so umgesetzt:

und nun setzt du $! nicht zurück. denn es wird nur bei einem Fehler neu gesetzt, ansonsten behält es den alten Wert. Zudem kann es auch undef sein. eine abfrage mit ne ist nicht so gut.

2012-09-27T14:53:25 ?

Zur Gruselgeschichte wegen "goto":
Alle meckern _immer_ über "goto". Es ist eben so simpel zu benutzen. Und ob ich ein "sub", oder ein "goto" mache - ist doch fast dasselbe.

fast ist hier das Stichwort. mit goto hast du viele Hilfen nicht. Einmal die Übersicht verloren und du hast Probleme, die du nicht hast wenn du Funktionen benutzt.
Natürlich sind globale Variablen und goto auf den ersten Blick einfach simpel und leicht verständlich. Darum wurden sie vor langer Zeit überhaupt erfunden (mit dem Namen in BASIC 1949 meine ich). Aber es hat ein paar ganz große Probleme wenn man mehr als Bandwurm Code schreiben will.
Da wären:

• Feste Sprungmarken. Es ist mit GOTO ohne Verrenkungen nicht möglich von verschiedenen Punkten zurück zu diesen zu springen. Ein wiederverwenden von Code ist nahezu unmöglich.
• Keine Variablenübergaben. Die Werte, die an den "goto"-Code gehen sollen müssen global sein. Das frisst nicht zur Speicher, es macht den Code auch unübersichtlich, da Variablen nicht immer sinnvoll benannt werden können, ohne an anderer Stelle für Verwirrung zu sorgen.
• Gruppieren von Code in Modulen ist nicht möglich.
• Perl kann nicht prüfen ob der Code sinnvoll "terminiert" ist. Eine Sprungmarke falsch geschrieben oder vergessen und der Code spinnt. Bei Funktionen erkennt Perl wenn sie nicht geschlossen ist (Klammersymetrie).
• rekursive Probleme lassen sich nur mit enormen Aufwand lösen.

und mir fallen sicher noch viele anderer Probleme mit goto ein.

2012-09-27T14:53:25 ?

Das solche Strukturen "kompliziert" zu durchschauen sind ist wahrhaftig Fakt. Wenn ich aber an meine Ausbildungszeit zurück denke (Energieelektroniker Fachrichtung Anlagentechnik) fallen mir spontan diverse Stromlaufpläne ein, von denen ihr sofort "Augenkrebs" bekommen würdet. Ich habe die alte SPS-Variante noch erlernen dürfen.

Und das ist dein Grund es nicht besser zu machen? Nach dem Motto: Ich Schaufle nun schon seit 30 Jahren Mist mit meinen Händen ich Brauche keine Mistgabel.

2012-09-27T14:53:25 ?

Und Zeitrelaisprogrammierung über eine For-Next Schleife. Hatte man die gewünschte Zeit durch ausprobieren der Schleifendurchläufe endlich raus, dachte man alles erledigt. Irgendwann wurde der Chip der SPS gewechselt - gegen einen schnelleren... Tja, was soll ich sagen, da waren halt 10 eingestellte Sekunden nur noch 2 Sekunden lang - Der Prozessor war beim Schleifendurchlauf eben schneller...

In Embeddedsystemen ohne Timer sind noop-Waits gebräuchlich, und auch unproblematisch wenn man sie richtig verwendet (z.B. mit einer modernen Programmiersprache, die so was kapseln kann)

2012-09-27T14:53:25 ?

Wenn ich an die ganzen Steuerungen denke, wo diverse Sensoren und Mikroschalter mit in den Programmablauf einfliessen, ist eben mal ganz schnell fertig mit Struktur im Programm. Die heutigen Programme sind so umfangreich, da blick ein Servicetechniker auch nicht auf anhieb durch. Das einzig Wahre, was dir hilft, ist eine wirklich gute Doku, die dir Programmzeilengenau sagt, wo was passiert... Aber wie erwartet - sowas hat Seltenheitswert. Nicht zuletzt weil bei dem heutigen Preisdruck kaum noch jemand die Zeit hat, eine solche zu entwerfen...

Und das ist ein Grund warum sich Programmiersprachen weiter entwickeln. Die Konstrukte gibt es nicht weil Programmierer "Cool" sein wollen. Sie machen einem die Arbeit leichter. Durch auslagern von Häufigem und Kapseln des Komplexen wird die Programmübersicht um einiges verbessert.