AW: Was ihr schon immer wissen wolltet... 2 (1. Beitrag beachten)
Fatal!ty Str!ke schrieb:
Von echter Programmierung hab ich aber keine Ahnung. Müsste man da nicht auch die Fehler sehen. Oder das Programm stoppt einfach, wenn was Falsch ist? So Ähnlich wie das gegen die Wand laufen der Legofigur?
Das wäre wohl weniger angenehm.
Stell dir vor, dein Betriebssystem würde sich immer gleich beenden, sobald eine kleine Schwierigkeit auftritt.
Für solche Fällen gibt es Fehlerbehandlungsroutinen.
Fatal!ty Str!ke schrieb:
Also jede Funktion wird doch per hand geschrieben und Programmiert. Wenn ein Fehler drinn ist, müsste die Funktion doch nicht funktionieren. Da müsste man das ja sofort erkennen.
Wenn es nur so einfach wäre. ^^
Also, man unterscheidet wohl grob zwischen
syntaktischen und
semantischen Fehlern. Syntaktische (z.B. falsch geschriebene Befehle) werden i.A. vom Übersetzer erkannt und das Programm kann erst gar nicht erstellt werden, klar, er kennt diesen Befehl ja auch nicht.
Semantische Fehler fallen oft nur durch ausgiebiges Testen oder im praktischen Einsatz auf. Du solltest einmal wissen, was ein
Algorithmus ist -> eine allgemeine Vorgehensweise zur Lösung eines bestimmten Problems (z.B. Zahlen sortieren, Daten suchen oder eben einen Weg durch ein Labyrinth finden). Dieser Algorithmus soll natürlich nicht nur für einige spezielle Fälle funktionieren, sondern für alle. Ein Problem so zu abstrahieren ist allerdings nicht immer ganz einfach.
So kann es nun durch vielerlei Ursachen zu einem Fehler kommen. Einige typische Beispiele:
Es tritt ein spezieller Fall ein, den man als Programmierer nicht bedacht hat. Ganz triviales Beispiel: Man lässt den Benutzer 2 Zahlen eingeben und will den Quotienten (Zahl 1 / Zahl 2) berechnen, welchen man wieder ausgibt. Das funktioniert auch für unendlich viele Eingaben, nur eben für den speziellen Fall, dass die 2. Zahl 0 ist, nicht. Alle möglichen Spezialfälle müssen im Vorhinein erkannt und berücksichtigt werden, was bei komplexeren Aufgaben nicht immer so einfach ist.
Oder man schreibt einen fehlerhaften Algorithmus, der eigentlich ein falsches Ergebnis liefern sollte, was man dann auch erkennen würde, nur bleibt der Fehler in den meisten Fällen doch ohne Konsequenzen und fällt damit nicht sofort auf bzw. lässt sich nur schwer reproduzieren. Beispiel: Ein Programm liest etwas ein und schreibt es in einen Speicherbereich, der egtl. für etwas anderes vorgesehen ist. Kurz darauf liest es das Programm wieder aus. Inzwischen könnten die Daten aber von anderen Daten, für die der Platz eigentlich reserviert wurde, überschrieben worden sein und das Programm arbeitet plötzlich mit falschen Daten. Wird bei modernen Systemen/Sprachen zum Glück oft auch schon verhindert.
Ein weiteres sehr schönes Beispiel eines nicht gleich offensichtlichen Fehlers ist
der Bug, der zum Hängen der Zunes geführt hat.
Fatal!ty Str!ke schrieb:
Ich weis, dass alles sehr aufwändig ist. Aber wenn man ein paar Zeilen geschrieben hat kann man das doch sofort testen. Man Programmiert doch nicht blind ein Programm und test es erst, wenn man fertig ist (oder doch?)
Nein macht man nicht. Aber ein Programmteil besteht eben nicht nur aus einigen wenigen Zeilen, das Problem ist, dass oft sehr große Teile zusammenhängen, Auswirkungen aufeinander haben und korrekt zusammenspielen müssen. Das zu testen ist schon sehr schwierig.
Fatal!ty Str!ke schrieb:
Ich hoffe ihr wisst, auf was ich hinaus will.
Nein, nicht wirklich. ^^
Aber es sei nur eines gesagt, manchmal muss man sehr hardwarenah programmieren, vor allem, wenn es um Leistung geht.
Fatal!ty Str!ke schrieb:
Mir fällt da z.b. ein das man einen PC so entwicklen könnte, das es nicht nur Nullen und Einsen bzw. An und Aus gibt, sondern auch irgendwie Zwischenstufen oder ganze Wörter. Dann bräuchte man deutlich weniger Code und Rechenleistung würde es auch extrem sparen.!
Ich weiß echt nicht, wie du dir das ganze vorstellst, aber das im Hintergrund alles nur als Binärzustände dargestellt wird, bekommt man ja selbst als Programmierer meist nicht wirklich mit, man wird von den tatsächlichen technischen Implementierungen abgeschirmt.
Fatal!ty Str!ke schrieb:
Man braucht ja immer mehr Leute und immer mehr Zeit und es gibt immer mehr Fehler.
Das hat ja kein Ende.
Das stimmt zumindest gewissermaßen. Es wird tatsächlich alles umfangreicher und aufwändiger. Allerdings wird das einigermaßen durch schichtenweises Programmieren ausgeglichen. Also man kann mit wenig Code immer mehr erreichen, weil sich die darunterliegende Schicht um die Details kümmert.
Ein ganz einfaches Beispiels einer solchen Schicht ist das Betriebssystem selbst. Es wäre unmöglich, wenn sich ein jedes Programm darum kümmern müsste, wie jedes unterschiedliche Gerät angesprochen wird, wie es mit anderen Programmen kommuniziert und sich Ressourcen teilt usw. Stattdessen greifen alle Programme auf die selbe Weise auf die Hardware zu und das Betriebssystem als darunterliegende Schicht steuert die Hardware dann speziell an. Es teilt den Programmen die Ressourcen zu usw.
Dasselbe gilt auch für moderne Anwendungen. Hat man früher z.B. Webanwendungen noch auf alle Browser abstimmen und sich mit deren Eigenheiten herumschlagen müssen, gibt es heute z.B. moderne Frameworks, die sich darum kümmern. Man schreibt seine Anwendung mit diesem Framework, verwendet dessen Befehle usw. Und dieses darunterliegende Framework übersetzt das ganze wieder für die unterschiedlichen Browser.
Jede Schicht erfüllt also nur eine bestimmte Aufgabe und setzt wieder auf eine andere auf, so dass sie sich möglichst nur auf ihre eigentliche Funktion konzentrieren muss.
D.h. die Anwendungen werden zwar umfangreicher und komplexer, gleichzeitig erleichtern uns modernere Tools wiederum die Arbeit, womit sich das ganze wieder ausgleicht.
Aber das tuen sie nicht. Jeder PC verhält sich irgendwie anders. Nach Lust und Laune eben.
