Wenn du dir nicht sicher bist, in welchem der anderen Foren du die Frage stellen sollst, dann bist du hier im Forum für allgemeine Fragen sicher richtig.
cofi hat geschrieben:Zum Lernen einer Sprache gehoert eben nicht nur das Lernen der Syntax, sondern auch das der Idiome und das Anwenden letzterer.
Durchaus richtig - nur kann wenigstens ein Teil der Menschheit nicht alles auf einmal und sofort ganz am Anfang schon lernen. Und dann macht es einen Unterschied in bezug auf die Einordnung als "einfach", wie ein Stück Software formuliert ist, vor allen wenn es um die Antwort auf eine Frage geht.
Komischerweise finden sich im englischsprachigen Pythonforum im Bereich für die Anfänger auch fast keine einzeiligen Ausdrücke. Ich kann natürlich nicht beurteilen, ob die Leute, die dort die Fragen anderer beantworten, vielleicht einfach keine guten Programmierer sind. Aber obwohl meine Muttersprache Deutsch ist, sind die dortigen Erklärungen für mich oft erhellender als die mehr oder weniger kommentarlos als Antwort verfassten Beiträge in diesem Forum - was ich nicht selten als ziemlich frustrierend empfinde, es wär halt doch schön, wenn ich auch in meiner eigenen Sprache mal einfache Fragen zu Python stellen könnte und auf schlicht hilfreiche Antworten hoffen. Aber einen Ort dafür habe ich bislang nicht auftreiben können .
Den Code danach zu schreiben, dass jeder Anfänger ihn sofort versteht halte ich nicht für besonders sinnvoll. Die Fragesteller sind eben nicht immer totale Anfänger und da ist eine unnötig lange Lösung einfach sinnlos. Man kann doch nachschauen oder hier nachfragen wenn etwas nicht verständlich ist. Dann bekommt man auch eine Lösung mit mehreren Schritten, und lernt vielleicht noch mehr als eigentlich geplant.
Jeder, der mehr machen will, als Programmtext solange zusammen zu klöppeln, bis das ganze zufällig funktioniert, muss eher früher als später die zu Grunde liegenden (mathematischen) Konzepte verstehen, wie z.B. Abstraktion, Applikation oder Rekursion. Eine funktionale Sichtweise macht es hier viel einfacher als eine imperative.
Hinzu kommt, dass wir gelernt haben, dass Abstraktionen bei der Kommunikation helfen, in dem sie Abkürzungen für immer wiederkehrende Sachverhalte erfinden. Vielleicht ist es nicht jedem klar, aber ein Microprozessor kann gar nicht wirklich multiplizieren. Schreiben wir "3*4" hin, läuft ein recht komplexes Programm (heutzutage in Microcode, einer Ebene noch unterhalb des Maschinencodes) ab, welches eine komplizierte Folge von Additionen und anderen Bit-Operationen durchführt. Wir müssen das (glücklicherweise) nicht alles hinschreiben. Das war nicht immer so. Der Z80-Prozessor oder der 6502-Prozessor, die in vielen gerade mal 20 Jahre alten Home-Computern verbaut wurden (wie dem Apple II oder dem C64 (da war es ein 6510 aber egal)) konnten nicht multiplizieren. Dort musste man das immer und immer wieder hinschreiben. Meist gab es eine generische Multiplikationsroutine, aber die war viel zu langsam, wenn man etwa nur mit 10 multiplizieren wollte. Da war es besser, das Äquivalent von `a1 = a + a; a1 = a1 + a1; a1 = a1 + a; a = a1 + a1` zu programmieren.
Was ich mit diesem langen Ausflug in die Frühgeschichte der Computer sagen will, ist dies: Gewisse Abstraktionen wie die Multiplikation (und das Computer auch gar nicht wirklich addieren können, sondern nur Bitmuster verknüpfen, will ich jetzt gar nicht ausweiten) sind inzwischen selbstverständlich.
Gerade die funktionale Programmiersprache hat weitere Abstraktionen als Teil einer Programmier-Sprache entwickelt, die immer wieder kehren und auf diese Weise eine kürzere aber vor allen Dingen präzisere Ausdrucksform ermöglichen. So kennen wir z.B. `map` oder `filter` auch in Python. Beides kann man wiederum in einer List-Comprehension zusammenfassen. Die Sprache Scala kennt Sequence-Comprehension, die noch eine dritte `flatMap` genannte Funktion kennen, um noch allgemeiner zu sein. Bräuchte man in Python auch, wenn man LCs sauber auf OO-Konzepte abbilden wollte.
Apropos OO: Natürlich sind auch hier Konzepte entstanden, die inzwischen relativ normal sind. Und schon vor fast 30 Jahren hat man bei Smalltalk erkannt, dass innere Iteratoren (wie sie Ruby nutzt) mächtiger und gleichzeitig verständlicher sind als äußere Iteratoren (das sind die einzigen, die Java kennt). LCs zählen zu den inneren Iteratoren.
Und Generatoren gibt es als Streams auch häufig als Konzept in funktionalen Sprachen und in der Variante - die bei Python erst später hinzudefiniert wurde - als Coroutinen tauchten diese schon in Simula-67 auf (wenn nicht noch früher).
Bevor ich komplett den Faden verliere: Ich bin davon überzeugt, dass der funktionale Stil der klarere, der ausdrucksstärkere und damit letztlich auch der einfachere ist, das gerade LCs sehr gut lesbar sind und Generatorausdrücke als Optimierung davon als Konzept wichtig und sehr lesbar sind. Genau wie wir "+" und "-" für Zahlen als Operationen kennen, müssen wir die üblichen Operationen auf (möglicherweise unendlichen) Listen kennen.
Ich meine, Sprache in der Tradition von APL (z.B. "J" oder "K", die ich mir schon länger mal anschauen wollte, arbeiten immer auf Listen oder Feldern und nicht nur auf skalaren Werten.
Wenn ein Ausdruck map und List Comprehensions beinhaltet, kann der Anfänger, der dies nicht versteht, einfach in der Dokumentation nachschauen, was dies denn ist.
Wenn er es trotzdem nicht verstehen sollte, kann er ja immer noch konkrete Fragen dazu stellen, dann werden die auch sicher beantwortet.
Also lernt der Anfänger somit viel mehr als mit einer anderen Lösung, die nur die "anfängerfreundliche Elemente" von Python benutzt.
Das alles setzt noch Eigeninitiative vorraus, aber wenn man programmieren will, braucht man das auch.
Früher wär ich auch nie auf die Idee gekommen, LCs, GEs, map, lambda, etc zu benutzen, doch ich hab im Forum gesehen, wie praktisch diese sein können. Ich habe erstmal nichts davon verstanden, aber als ich ein wenig dazu nachgelesen habe und damit rumgespielt habe, habe ich gemerkt, wie nützlich das Zeug ist und wie viel besser man damit klarkommt, als alles in umständliche for-Schleifen zu schreiben.
.