Oder der Delphi-Fan ("Lehrer") denkt sich, der Code funktioniert schon so wie er da steht und weiß von dem gecache nichts.
Ich formuliere es mal etwas dreist:
So doof, wie Du das Lehrpersonal hinstellst, ist es nun wirklich nicht. Habe mich im Laufe meines Lebens öfter mal damit rumschlagen müssen.
Es geht immer um das abstrakte Lernen und nicht um die konkrete Umsetzung.
Für 'ne Klausur könnte der Prof. / Lehrer auch 'ne eigene Phantasiesprache wählen. Wesentlich ist nur, dass abstrakte Gedanken und Formalitäten klar abgebildet werden.
Wenn das oft wie Pascal/Delphi aussieht ist das ein Nebeneffekt, aber für die Lösung der Aufgabe nicht wesentlich.
Klar ist es hilfreich, wenn man das Programmieren mit 'ner Entwicklungsumgebung lernt, aber es geht auch ohne. Und in Klausuren muss man die Aufgaben auch ohne Entwicklungsumgebung lösen können, da hat man nur Papier und Bleistift/Kugelschreiber/Füller.
@p80286
a) wird von Delphi genommen
Pascal-Script von RemObjekt, dass man gut in Delphiprogramme einbinden kann, nutzt Variante b). Hab's eben extra ausprobiert.
@a.def:
Die Aufgabenstellungen sind alle so, dass man da nachdenken muss, um zu verstehen, was da passiert. Es geht nicht darum, dass man das irgendwie mit Delphi kompilieren oder gar sinnvoll nutzen kann.
Und einige der Aufgaben enthalten gravierende Fehler. Und Aufgabe ist es, diese gravierenden Fehler zu erkennen und zu benennen.
Hier
Delphi-Quellcode:
For ik:= 1 to i+3 do
begin
writeln("abc"); i:=i+1;
end;
heißt die Antwort also sinngemäß.
Da i im Laufe der Schleife permanent erhöht wird, wird das Ende der Schleife nie erreicht.