Übung — AFB III (Verallgemeinern und Reflektieren)

Musterlösung: Die Aussage ist in dieser Allgemeinheit falsch. Richtig ist, dass ein Python-Programm im Modell etwa 25-mal so lange braucht wie dasselbe Programm in C. Jonas beurteilt die Sprache aber nur nach einem einzigen Kriterium, der Laufzeit.

Weitere Kriterien sind die Entwicklungszeit (ein Python-Programm ist oft viel schneller geschrieben und getestet), die Bibliotheken und die Community (für Datenanalyse und KI gibt es in Python fertige Bausteine) und das Vorwissen des Teams. Für eine Auswertung, die einmal pro Woche läuft, spielen 10 statt 0,4 Sekunden keine Rolle — hier ist Python die bessere Wahl.

C ist dagegen sinnvoll, wenn Speicher und Rechenzeit knapp sind, etwa bei einem Mikrocontroller, oder wenn ein Programm sehr oft und sehr schnell laufen muss. Fazit: Es gibt keine „beste“ Sprache, sondern nur eine, die zu Plattform, Anforderungen und Team passt.

Musterlösung: Ein C-Compiler übersetzt den Quelltext vor dem Start vollständig in Maschinencode. Dieser Maschinencode passt nur zu einem Prozessortyp und einem Betriebssystem. Die Firma muss den Quelltext deshalb für Windows und für Linux getrennt kompilieren und zwei verschiedene Programmdateien ausliefern.

Der Java-Compiler javac übersetzt den Quelltext dagegen in Bytecode — Maschinencode für eine gedachte Maschine. Diesen Bytecode führt die Java Virtual Machine (JVM) aus, die es für Windows und Linux gibt; ein JIT-Compiler übersetzt dabei häufig benutzte Teile während des Laufs in echten Maschinencode. Die Firma liefert deshalb nur eine Bytecode-Datei aus, auf den Computern muss aber eine JVM installiert sein.

Vergleich: C ist dafür meist etwas schneller und braucht keine Laufzeitumgebung; Java spart den Aufwand, für jede Plattform neu zu übersetzen. C# arbeitet mit CIL und .NET nach demselben Prinzip wie Java.

Musterlösung: Die Behauptung ist falsch. Gegenbeispiel: "10" + 5 führt in Python zu einem TypeError, weil Python einen Text und eine Zahl nicht mit + verknüpft. Python ist dynamisch typisiert: Man schreibt keine Typen hin, aber jeder Wert hat einen Typ, und der wird während des Laufs geprüft.

Im Programm steht der Fehler in Zeile 3. Der Interpreter prüft diese Zeile aber erst, wenn er sie erreicht — und das passiert nur, wenn jemand „Sonntag“ eingibt. An allen anderen Tagen läuft das Programm fehlerfrei durch den else-Zweig. Der Absturz kommt erst am ersten Sonntag.

Java ist statisch typisiert: Der Compiler prüft vor dem Start alle Zeilen, auch die in selten genutzten Zweigen. Ein Ausdruck, der einen Typfehler enthält — etwa die Zuweisung eines Textes an eine int-Variable —, wird schon beim Kompilieren gemeldet; das Programm startet gar nicht erst. (Achtung: "10" + 5 selbst ist in Java kein Fehler, sondern ergibt den Text „105“.)

-- (1)
SELECT titel, seiten FROM buecher
WHERE genre = 'Fantasy' AND seiten > 400
ORDER BY seiten DESC;

-- (2)
SELECT COUNT(*) FROM buecher
WHERE jahr < 1980 OR genre = 'Krimi';

-- (3)
SELECT AVG(seiten) FROM buecher
WHERE autor = 'Ende';

Musterlösung: In (1) müssen beide Bedingungen gelten, deshalb AND; „das dickste zuerst“ bedeutet absteigend, also DESC. In (2) reicht eine der beiden Bedingungen, deshalb OR. Texte wie 'Fantasy' stehen in einfachen Anführungszeichen. (Falls die Tabelle den vollen Namen speichert, lautet die Bedingung in (3) entsprechend autor = 'Michael Ende'.)

SQL ist deklarativ: Abfrage (1) beschreibt nur, was im Ergebnis stehen soll — welche Spalten, welche Zeilen, welche Reihenfolge. Wie die Datenbank die Zeilen durchsucht und sortiert, legt sie selbst fest. In Python müsstest du dafür selbst eine Schleife über alle Bücher schreiben, jede Zeile prüfen, passende in eine Liste übernehmen und diese Liste sortieren — das wäre imperativ.

Musterlösung: HTML und CSS beschreiben Aufbau und Aussehen des Bestellformulars; der Browser stellt sie dar. JavaScript läuft im Browser (clientseitig) und kann sofort, ohne neue Anfrage an den Server, eine Warnung anzeigen, wenn kein Gericht gewählt ist. Beim Abschicken gehen die Formulardaten an den Server. Dort liest ein PHP-Skript sie über $_POST aus, prüft sie, speichert die Bestellung und erzeugt die HTML-Antwortseite (serverseitig). Zum Speichern und Abfragen der Bestellungen schickt PHP SQL-Befehle an die Datenbank, etwa SELECT COUNT(*) FROM bestellungen WHERE tag = 'Montag' für die Küche.

Die Guthabenprüfung nur mit JavaScript ist abzulehnen. Der JavaScript-Code wird an den Browser geschickt; der Nutzer kann ihn lesen, abschalten oder verändern und so trotzdem bestellen. Prüfungen, auf die man sich verlassen muss, gehören auf den Server, dessen PHP-Code der Nutzer nie zu sehen bekommt. Die JavaScript-Prüfung ist nur als bequeme zusätzliche Warnung sinnvoll.

Musterlösung: In C verwaltet der Programmierer den Speicher selbst. Vergisst er, dass ein Speicherbereich schon freigegeben wurde, fällt das erst beim Lauf auf — genau das waren die Abstürze.

Go ist kompiliert, hat wenige Sprachelemente und einen Garbage Collector, der nicht mehr benutzten Speicher automatisch freigibt. Das verhindert die bisherigen Fehler. Der Garbage Collector arbeitet aber während des Laufs und kann kurze, nicht genau planbare Pausen verursachen.

Rust ist ungefähr so schnell wie C und kommt ohne Garbage Collector aus. Stattdessen hat jeder Wert genau einen Besitzer (Ownership); der Borrow Checker prüft schon beim Kompilieren, dass kein Wert nach dem Verschieben oder Freigeben noch benutzt wird. Ein Programm mit dem alten Fehler würde also gar nicht erst übersetzt.

Für eine Ampel, die zuverlässig und ohne Aussetzer laufen muss, spricht deshalb mehr für Rust. Dagegen spricht der höhere Lernaufwand, weil die Regeln des Borrow Checkers neu sind. Insgesamt überwiegen hier Sicherheit und Geschwindigkeit: Rust ist die bessere Wahl.

Musterlösung: Beide Varianten geben 2 aus („Schule“ und „Informatik“). Variante A ist imperativ: Sie beschreibt Schritt für Schritt, wie gezählt wird. Der Zustand ist die Variable anzahl, die bei jedem passenden Wort um 1 erhöht wird; zusätzlich ändert sich w in jedem Durchlauf.

Variante B ist funktional: filter wendet die Funktion len(w) > 4 auf jedes Wort an und behält die passenden. Die Funktion hat keine Seiteneffekte, und es gibt keine Variable, die hochgezählt wird. Man beschreibt eher, was man haben will.

Variante B ist leichter zu prüfen: Sie ist kürzer, und typische Fehler wie ein vergessener Startwert anzahl = 0 oder ein Zähler an der falschen Stelle können nicht auftreten. Vorteil von Variante A: Jeder Schritt ist sichtbar, sie ist für Einsteiger leichter nachzuvollziehen und lässt sich leicht erweitern, etwa um eine Ausgabe jedes langen Wortes. Dass beide Stile in Python funktionieren, zeigt: Python ist eine Multiparadigmen-Sprache.

Musterlösung: Fehler 1: Update() wird einmal pro Frame aufgerufen, also viele Male pro Sekunde. Weil punkte = 0; in Update() steht, wird der Punktestand in jedem Frame wieder auf 0 gesetzt — eingesammelte Punkte gehen sofort verloren. Das Zurücksetzen gehört in Start(), die nur einmal beim Start des Objekts läuft.

Fehler 2: transform.Translate(0.1f, 0, 0) bewegt die Figur um 0,1 Einheiten pro Frame. Bei 30 fps sind das 3 Einheiten pro Sekunde, bei 144 fps 14,4 Einheiten pro Sekunde — auf dem schnellen PC ist die Figur fast fünfmal so schnell. Multipliziert man mit Time.deltaTime (Zeit seit dem letzten Frame in Sekunden), wird daraus ein Weg pro Sekunde, unabhängig von der Bildrate.

public class Spieler : MonoBehaviour
{
    int punkte;
    float tempo = 3f;   // Einheiten pro Sekunde

    void Start()
    {
        punkte = 0;
    }

    void Update()
    {
        if (Input.GetKey(KeyCode.RightArrow))
        {
            transform.Translate(tempo * Time.deltaTime, 0, 0);
        }
    }
}

Musterlösung: Teilweise hat der Mitschüler recht: In Assembler entspricht jeder Befehl genau einem Maschinenbefehl. Wer den Prozessor sehr genau kennt, kann damit besonders kleine und schnelle Programme schreiben.

Assembler hat aber große Nachteile. Schon eine einfache Rechnung wie a + b · c braucht mehrere Befehle wie MOV, MUL und ADD; Programme werden lang, schwer lesbar und fehleranfällig. Außerdem ist Assembler prozessorabhängig: Für einen anderen Prozessortyp muss man das Programm neu schreiben. Genau deshalb entstanden Hochsprachen: FORTRAN (1957), damit Wissenschaftler Formeln fast so schreiben können wie auf Papier, und COBOL (1959) für Geschäftsdaten. Ein Übersetzer erzeugt aus demselben Quelltext Maschinencode für verschiedene Prozessoren.

Heutige Compiler optimieren so gut, dass Hochsprachen wie C oder Rust meist genauso schnell sind. Assembler ist heute nur noch für kleine, sehr zeitkritische oder hardwarenahe Teile sinnvoll, zum Beispiel für den Startcode eines Mikrocontrollers. Die Aussage ist deshalb abzulehnen.

Musterlösung: Python gibt 7.5 aus. JavaScript (console.log((a + b) / 2)) und PHP (echo ($a + $b) / 2;) liefern ebenfalls 7.5: In beiden Sprachen liefert / ein Ergebnis mit Nachkommastellen, wenn die Division nicht aufgeht. In Java (int a = 7, b = 8;) und Go (a := 7, b := 8) sind a und b ganze Zahlen vom Typ int. Dort ist (a + b) / 2 eine Ganzzahldivision, die Ausgabe ist 7.

Korrekturen: In Java (a + b) / 2.0, in Go float64(a+b) / 2 — Go verlangt die Umwandlung ausdrücklich.

Vorgehensweise beim Übertragen: (1) Eine Vergleichstabelle der Grundbefehle anlegen (Variable, Ausgabe, Division …). (2) Die Besonderheiten in der offiziellen Dokumentation nachlesen, z. B. go.dev/tour oder learn.microsoft.com. (3) Das übertragene Programm mit Testfällen prüfen, deren Ergebnis man kennt — hier mit einer ungeraden Summe wie 7 und 8, denn bei 6 und 8 fiele der Fehler nicht auf. (4) Fehlermeldungen genau lesen: Zeile und Art des Fehlers. Das gilt auch für Code von einem KI-Assistenten: Nur verwenden, was man versteht und getestet hat.