Moin!
Kennzeichen einer Programmiersprache ist, dass Anweisungslisten eben nicht linear abgearbeitet werden, sondern dass es im Programmfluß auch Entscheidungen basierend auf Vergleichen gibt, welche den Programmfluß dann durch Sprünge in der Anweisungsliste individuell gestalten.
Wo siehst Du nun das Problem, soetwas mechanisch abzubilden?
Es gibt da kein Problem. Nur: Man muß sich vorher überlegen, was man will, um es hinterher umzusetzen.
Der Witz ist, dass bei einem Computer mit einer Programmiersprache das Programm in einem Speicher steht und eine Berechnung durchführt, dort aber auch jedes anderen Programm stehen könnte, welches andere Berechnungen durchführt.
Damit das aber so ist, muß man vorher definieren, welche Befehle es geben soll. Darum gehts, denn das war die Ausgangsfrage: Was war zuerst da, Programmiersprache oder Interpreter - wobei der Interpreter in jedem Fall irgendwann irgendeine zentrale Verarbeitungseinheit ist, landläufig auch als CPU bekannt.
Aber das ändert nichts an der Tatsache, dass irgendjemand sich mal überlegen mußte, wie er diese Schalter zusammenbaut, und damit er sie sinnvoll zusammenbauen kann, muß er wissen, was er damit überhaupt machen will.
Das ist durchaus richtig, auch mit Deinen schleifen und bedingungen hast Du vollkomen recht.
Eben. Also ist die Antwort doch klar: Die Programmiersprache war zuerst da, denn nur wenn ich in der Theorie eine Sprache definiert habe, weiß ich, was mein Interpreter interpretieren soll, und erst dann kann ich den Interpreter praktisch umsetzen.
Oder programmierst du immer erstmal irgendwas dahin, um dadurch dann auf eine Aufgabe zu stoßen, die gelöst werden will? Gemäß dem Motto "Of course it doesn't work, but look how fast it is!".
Dann nehmen wir einfachste Steuerungen und Regelungen mit ins Boot, und Du hast Deine Schleifen und Abfragen.
Ein Regelkreis ist keine Schleife oder Abfrage, sondern eine Rückkopplung - was man aber wirklich nur mit größten Schmerzen auch nur in die Nähe von "Programmierung" rücken kann. Und eine Steuerung ist überhaupt keine Schleife oder Abfrage - das ist der Sinn einer Steuerung.
Entsprechend verkabelt mit den Senoseren hast Du auch entsprechende Zeiger und Sprünge, die je nach anforderung etwas anderes bewirken können und somit gernau das tun, was Du als Programm eben definiert hast.
Du kennst dich nicht wirklich mit Regelkreisen und Steuerungen aus.
Einfachstes Beispiel: Wasserkraftwerk.
WAAAHHH!!!!1 Ich lach mich tot. Ein Wasserkraftwerk ist vermutlich das komplexeste Beispiel, was du überhaupt hättest bringen können.
Was willst du mit diesem Beispiel zeigen? Dass ein Wasserkraftwerk programmiert wird? Ja klar, heutzutage sind Microcontroller überall drin und übernehmen Aufgaben, für die man früher ganz stinknormale herkömmliche Regelkreise gebaut hätte, zu einem Vielfachen des heutigen Preises.
Oder dass ein Wasserkraftwerk nicht programmiert wird? Ja klar, muß es nicht. Man kann auch alles mit herkömmlichen Regelkreisen betreiben - nur wird das keinesfalls heutigen Anforderungen gerecht werden, allenfalls im Inselbetrieb.
Zum einen wird anhand des Netzes und der Drehzah der Torbine das einspeisen ins Stromnetz geregelt.
Allein dieser Teilaspekt ist schon eine der komplexeren regelungstechnischen Aufgaben. Denn die Phasenabweichung zur Netzfrequenz darf natürlich nicht zu groß werden (es sei denn, man hat Inselbetrieb), und Lastspitzen weiß man (Wunschdenken) natürlich am besten eine Stunde vorher, und nicht hinterher, wenn durch den sprunghaften Lastanstieg am liebsten der Generator stehenbleiben will.
Die verschiedenen Wasserstände werden ständig kontroliert.
Schleussen geöffnet und geschlossen.
Gegebenfalls bei Hochwasser z.B. das Turbinenhaus geschlossen.
Noch eine komplexe Aufgabe, die aber auch keiner wirklichen Programmierung bedarf.
Natürlich prüft ein Wasserhöhen Messer, ob der Durchfluss noch gross genug ist und betreibt unabhängig den Rechenreiniger.
Dein "Wasserhöhen Messer" heißt Pegel, und dass dieser den Rechenreiniger betreibt, wäre mir neu. Bestenfalls liefert der Pegel Messdaten für die Steuerzentrale, vielleicht werden diese auch in einen Regelkreis eingespeist (wobei die Frage ist, was man daran ändern könnte, wenn kein Wasser mehr da ist - außer das Kraftwerk dichtmachen).
Selbstverständich habe ich nur mal knapp und grob geschildert was da abläuft.
Und genau deshalb ist dein Beispiel eben nicht vom Typ "einfachst", sondern vom Typ "komplex". Also ungeeignet.
Eine entscheidung der Schaltkreise anhand Wasserstand zu hoch zu niedrig.... kann man wohl als if Schleife gelten lassen.
Was sind eigentlich if-Schleifen? http://www.dclp-faq.de/q/q-terminologie-if.html
Und auf deine Aussage: Nein, kann man nicht. Weil es einen Unterschied macht, ob ein Pegelschalter einen Stromkreis öffnet oder schließt, oder ob man einen generischen Befehl "Wenn-dann" definiert, welcher in einer CPU zur Ausführung kommt.
Die dadurch geaenderte Funktion oder Aufgabe, dürfte man doch als "Sprung" oder Zeiger in eine andere Funktionsweise gelten lassen oder?
Auch nicht. Dein Wasserwerkbeispiel hat das Problem, dass es nicht "einfachst" ist, sondern komplexestes Multitasking und Parallelverarbeitung bedeutet. Der aktuelle Betriebszustand ist eine Mischung aus diversen Einzeldetails, welche sich in beliebiger Kombination zusammensetzen lassen. Ein paar dieser Kombinationen wird vom konstruierenden Ingenieur als "normal" definiert und ist durch die Regelung möglichst anzustreben. Andere Kombinationen sind als unerwünscht bzw. gefährlich definiert und je nach Gefahrpotential entweder regelungstechnisch oder per Notfallplan zu vermeiden.
Und für das zweite Programm baust du wieder eine Maschine gleicher Größenordnung.
Was ist bei der Programierung? Wie oft wird das gleiche zig mal neu gemacht?
Die Softwareentwicklung ist auch nicht immer optimal.
Die Frage, ob C&P angewendet wird, ist aber irrelevant für die Betrachtung, ob die erste Programmiersprache vor oder nach ihrem Interpreter entstand.
Richtig, nur bei obigem Beispiel mit dem Wasserwerk, wird wohl wirklich keiner der Ingeneure auch nur annähernd "Programieren".
Da sitzt der Entwickler tatsächlich mit dem Schaltpla bzw. einem Kontakt oder Funktionsplan da und baut sich das ganze entsprechend zusammen.
Heute wohl eher nicht mehr. Die Computer sind einfach nicht aufzuhalten.
Keine Zeile Code.. aber hinterher trotzdem ein Programm, das "sebständig" ein System am laufen hält. Das nach vorgaben und entscheidung selbst erkennt und regelt.
Du wirst es aber nicht schaffen, gegen solch ein Wasserwerk Schach spielen zu können. Es sei denn, du hast programmierbare Hardware eingebaut und änderst deren Programm.
Die Definition einer Programmiersprache ist, dass sie Abfragen (IF) und Sprünge kennt. Deswegen ist HTML keine Programmiersprache (die Conditional Comments für den IE sind zwar Bedingungen, aber es gibt keine Sprünge, um Dinge mehrfach oder unendlich zu wiederholen).
Da es hierbei keinerlei "natürliche Vorgaben" gibt, kann man die Befehle frei definieren. Nur: Tun muß man es natürlich, und zwar vor dem Bau, nicht hinterher. Also: Die Programmiersprache entsteht ganz bestimmt vor dem eigentlichen real existierenden Rechner.
Ganz sicher? Du täuscht Dich mit Sicherheit.
Jeder Autmomat, der für sich Messwerte ermittelt, stellt schon ein System dar, das zwar beschränkte aufgaben übernehmen kann, diese jedoch "selbständig" ausführt.
Definiere "Automat".
Ein "Automat, der für sich Messwerte ermittelt", wäre beispielsweise ein Pt100. Damit kriegst du in Abhängigkeit von der Umgebungstemperatur einen Widerstandswert. Den ermittelt "der Automat" vollkommen selbständig. Aber du willst mir jetzt nicht einreden, dass ein Stück Platindraht programmierbar wäre, oder?
Dass hierbei entscheidungen fallen, das System bzw. der automat anhand randkriterien eine Entscheidung fällen muss ist ohnehin klar.
Wie gesagt: Definiere Automat.
Das dahinter Abfragen stecken und letzendlich Zeiger auf weitere / andere Funktionen dürfte einleuchten.
Definiere Abfragen. Definiere Zeiger. Definiere Funktionen.
Mathematik ist eine mögliche Form der Programmiersprache. Weil sie, wenn auch ungewohnt, Bedingungen und Sprünge kennt.
Für das Beispiel des "Taschenrechners" würde es dann stimmen.
Und dass Mathematik garantiert vor der ersten Rechenmaschine da war, ist wohl unbestritten.
Stimmt.
Also wäre damit der Beweis erbracht: Zuerst gab es die Sprache, dann den Interpreter.
Dann überzeuge dich selbst von den Fähigkeiten des Z1.
Denk mal über das Wasserkraft Beispiel nach und Du wirst festellen, dass Deine bisher gebrachte Definition einer Programiersprache auf obigen Anwendungsfall wunderbar passt.
Nein. Dein Beispiel ist erstens zu wenig ausgearbeitet und diffus, zweitens in der Realität wesentlich komplexer, als du hier anführst - oder absolut unkomplex (nimm eine alte Mühle am Bach - ist auch ein Wasserkraftwerk, aber sicher nicht programmiert). Kurz: Einfach ungeeignet, irgendetwas zu zeigen.
- Sven Rautenberg
--
"Habe den Mut, dich deines eigenen Verstandes zu bedienen!" (Immanuel Kant)