aviable hat geschrieben:pillmuncher hat geschrieben:Mein Lieblings-Prolog-Programm:
Hier mal ein paar Beispiele, die zeigen, warum das die falsche Einstellung sein könnte:
Was hat das denn nu mit python zu tun ?
Prolog ist auch eine Programmiersprache. Wie ada.
pillmuncher: Villeicht tu ich dir ja auch unrecht und du wolltest mir helfen.
Dann schreibe ich es nochmal etwas expliziter: Wenn man Kenntnisse in Programmiersprachen hat, die letztlich alle dasselbe Rechenmodell repräsentieren, wird man mit deiner Methode - einfache Programme in der neuen Programmiersprache anschauen - nicht weit kommen, wenn diese neue Programmiersprache ein anderes Rechenmodell repräsentiert. Python ist zwar im Gundsatz imperativ, genauso wie Assembler, C und Basic, aber eben auch objektorientiert und funktional. Aus der Perspektive des imperativen Paradigmas wird man alles in Python als einfach ansehen, was dem nahekommt, was man schon kennt, dh. Programmabläufen wie diesem:
Code: Alles auswählen
xs = [1, 2, 3, 4, 5]
ys = []
for i in range(len(xs)):
y = xs[i] * 3
ys.append(y)
print(ys)
(Variante 0)
In Python würde man sowas aber nicht programmieren, sondern sowas:
Code: Alles auswählen
xs = [1, 2, 3, 4, 5]
ys = [x * 3 for x in xs]
print(ys)
(Variante 1)
Man verwendet Variablen nicht als "Datentöpfchen" wo man Sachen für später ablegt, sondern man betrachtet sie als Namen von Werten zu gewissen Zeitpunkten. Oft werden Variablen nur einmal mit einem Wert initialisiert, den sie dann für ihre gesamte Lebenszeit behalten. Da Python hat viel mehr Verwandtschaft mit Lisp als mit C oder Basic. Genau wie in Lisp sind Funktionen in Python auch nur Werte, die herumgereicht werden können. Ich hätte das Programm auch so schreiben können:
Code: Alles auswählen
def mul3(n):
return n * 3
xs = [1, 2, 3, 4,5]
ys = list(map(mul3, xs)
(Variante 2)
Oder so:
Code: Alles auswählen
from functools import partial
from operator import mul
mul3 = partial(mul, 3)
xs = [1, 2, 3, 4,5]
ys = list(map(mul3, xs)
(Variante 3)
Als erfahrener Pythonista würde man zwar beides in diesem Fall nicht machen, weil die Variante 1 viel einfacher ist, aber es gibt Anwendungsfälle, wo man mit Varianten 2 und 3 vergleichbaren Code verwenden würde. Nämlich dann, wenn sie für ein bestimmtes Problem die richtige Abstraktion darstellen. Wenn man allerdings nur Code kennenlernt, den man selbst als einfach ansieht (also solchem, der dem nahekommt, was man schon kennt), dann wird man manche Dinge wesentlich komplizierter lösen, als es sein müsste (oder gar nicht, weil zu komplex), weil einem die vereinfachenden Abstraktionen unbekannt bleiben.
Ein gutes Tutorial liefert mehr, als bloß zu zeigen, wie die Namen der basalen Operationen und Datenstrukturen sind, sondern zeigt auch, welche Abstraktionen in eine Sprache eingebaut sind und wie und unter welchen Bedingungen man sie verwenden sollte.
Das Prolog-Beipiel sollte übrigens genau das illustrieren. Einfach durch die Anwendung des Wissens, das man über Assembler/C/Basic/Python/... hat, wird man nie verstehen, wie dieses Programm funktioniert. Als ich Prolog gelernt habe, habe ich dieses Programm - ich erinnere mich genau, weil darauf eines meiner größten Erleuchtungserlebnisse folgte - zwei Stunden angestarrt. Es stand in einem der besten Computerbücher überhaupt,
The Art of Prolog, von Sterling und Shapiro. Es besitzt dieselbe geistige Reinigungskraft wie
The Structure and Interpretation of Computer Programs von Abelson und Sussman. Vielleicht irritiert mich dein Ansatz auch deswegen so sehr, weil ich Bücher liebe und nicht verstehen kann, warum jemand nicht lesen mag. Wenn sich der Autor doch bereits die Mühe gemacht hat, alles wichtige hinzuschreiben, und wenn das Buch gut ist, sogar auf lehrreiche und interessante Weise.
In specifications, Murphy's Law supersedes Ohm's.