Das deutsche Python-Forum

wie kommst du denn zu dem Schluss hier würde keinen Anfängern geholfen?!?

mkesper hat geschrieben: Montag 14. Dezember 2009, 16:44 Bitte an die angegebene Zielgruppe denken. Von beruflichen Softwareentwicklern war nicht die Rede. Es geht darum, Schülern und Studenten grundlegende Konzepte des Programmierens beizubringen.

Dafür ist aber Python denkbar ungeignet!

RIN67630 hat geschrieben: Sonntag 13. Mai 2018, 03:35
Dafür ist aber Python denkbar ungeignet!

Bitte nicht fast zehn Jahre alte Posts ausbuddeln.

Dafür ist aber Python denkbar ungeignet!

Experten auf diesem Gebiet haben eine andere Meinung dazu.
Auch die Praxis zeigt, dass sich Python sehr wohl für den Einstieg eignet.
Es wird ja an diversen Universitäten, auch an Deutschen, eingesetzt.

Wenn Python für den Einstieg ungeeignet wäre, würde man die Sprache in Bildungseinrichtungen nicht verwenden.

@RIN67630: Welche grundlegenden Konzepte des Programmierens kann man denn am Beispiel Pythons nicht unterrichten bzw. lernen?

Wenn man seine Meinung begründet, dann macht man übrigens mehr den Eindruck, dass man eine ernsthafte Diskussion führen möchte und nicht nur trollen will.

narpfel hat geschrieben: Sonntag 13. Mai 2018, 16:05 @RIN67630: Welche grundlegenden Konzepte des Programmierens kann man denn am Beispiel Pythons nicht unterrichten bzw. lernen?
Wenn man seine Meinung begründet, dann macht man übrigens mehr den Eindruck, dass man eine ernsthafte Diskussion führen möchte und nicht nur trollen will.

Es fängt schon beim sauber deklarieren von Variablen an. Dann ist die Posix-kompatibilität nicht von vorne gegeben.
Ja, man bekommt schnell Ergebnisse, aber auch schlechten Gewohneiten, die einem später im Wege stehen werden.
Selbst der Datentyp einer Variable ist nicht stabil.
Sobald dass man an Schnittstellen kommt, die klar definierte Inhalten verlangen, ist der Spuk vorbei.
Die Rückwärtskompatibilität mit Python 2 ist nicht gewährleistet.
Nebenbei: das Konstrukt select..case fehlt
usw...

Selbst der Datentyp einer Variable ist nicht stabil.

Das ist das Konzept von dynamischen Sprachen.

Ja, man bekommt schnell Ergebnisse, aber auch schlechten Gewohneiten, die einem später im Wege stehen werden.

Bekommt man auch mit C hin, also die schlechten Gewohnheiten und was die schlechten Gewohnheiten uns bis jetzt gebracht haben, kann man z.B. auf exploit-db.com nachlesen.

Sobald dass man an Schnittstellen kommt, die klar definierte Inhalten verlangen, ist der Spuk vorbei.

Geht auch mit Python. Ich weiß gar nicht was du willst. Ich könnte wenn ich wollte jeden Datentyp checken.
Mache ich das? Nein, weil ich Ducktyping verstanden habe.

Die Rückwärtskompatibilität mit Python 2 ist nicht gewährleistet.

Der Support wird 2020 eingestellt und das ist gut so. Die Inkompatibilitäten kommen dadurch zustande, dass man
die Sünden aus der Vergangenheit beseitigt hat.

Nebenbei: das Konstrukt select..case fehlt

Dieses Konstrukt wird in Python auch nicht benötigt und falls du denkst du bräuchtest das in Python, dann kennst du die Sprache nicht.


Meine Vermutung ist, dass du nur trollen willst.
Jemand der die Sprache gut kennt, findet andere Punkte die wirklich zu kritisieren sind, von denen du aber wahrscheinlich noch nie etwas gehört hast.

RIN67630 hat geschrieben: Montag 14. Mai 2018, 12:08
Es fängt schon beim sauber deklarieren von Variablen an. Dann ist die Posix-kompatibilität nicht von vorne gegeben.
Ja, man bekommt schnell Ergebnisse, aber auch schlechten Gewohneiten, die einem später im Wege stehen werden.
Selbst der Datentyp einer Variable ist nicht stabil.
Sobald dass man an Schnittstellen kommt, die klar definierte Inhalten verlangen, ist der Spuk vorbei.
Die Rückwärtskompatibilität mit Python 2 ist nicht gewährleistet.
Nebenbei: das Konstrukt select..case fehlt
usw...

Ach du liebe Guete. Ahnungslos und meinungstark - das sind ja immer die Besten... was hat denn POSIX-Kompatibilitaet (eine Eigenschaft von BETRIEBSSYSTEMEN) mit einer Programmiersprache zu tun? Und welches grundlegende Konzept stellt den Abwaertskompatibilitaet bitte dar? Wenn ich in C++17 programmiere, geht das auch nicht mehr durch einen Compiler von vor 5 Jahren. Ist laut deiner Logik also auch nicht geeignet zum beibringen von Konzepten des Programmierens. Da wuerde ich mal wissen wollen, welche Sprache du denn dafuer geeignet haelst...

Konzepte der Programmierung sind Datenstrukturen, Algorithmen auf diesen, und gewisse Paradigmen wie OO, logische, meta und funktionale Programmierung. Nicht alle davon lassen sich mit jeder Sprache gleich gut behandeln. Allerdings erstaunlich viele davon in Python, und das besser als zB mit den C-Sprachen.

Alles was du auffuehrst sind bestenfalls Geschmackssachen, die ja durchaus valide sind sich fuer oder gegen eine Sprache zu entscheiden. Aber deine Abqualifikation ist nicht schluessig begruendet. Sagt aber viel ueber dich aus...

@RIN67630: Deine Kritik ist weder korrekt noch neu. Es gibt öfter Leute, die sich in dieser Weise äußern – übrigens zu allem Möglichen, nicht nur Python. Warum sollte man Dich überzeugen, eine Sprache zu nutzen, die Dir missfällt? Warum solltest Du selbst eine Sprache nutzen, die Du kritisierst? Musst Du sie im Studium nutzen? Kein Problem: Du kannst etwas anderes studieren. Musst Du sie auf der Arbeit nutzen? Auch kein Problem: Du kannst den Job wechseln. Du bist frei.

Idealerweise nutzt man ohnehin ausschliesslich Lambda Calculus zum lernen. Alles andere ist entweder Mutable (Turing Maschine) und damit für einen Menschen schwer nachzuvollziehen oder größtenteils nur Syntax Zucker. Lambda Calculus erlaubt einem sich nur aufs wesentliche zu konzentrieren. Diese ganzen Abstraktionen sind ohnehin nur temporärer Hype.

__deets__ hat geschrieben: Montag 14. Mai 2018, 12:39 Und welches grundlegende Konzept stellt den Abwaertskompatibilitaet bitte dar? Wenn ich in C++17 programmiere, geht das auch nicht mehr durch einen Compiler von vor 5 Jahren.

Ohne den Flamewar fortsetzen zu wollen: Ich will nur deine Fragen beantworten.
Abwärtskompatibilität geht genau anders herum: Ein Programm, der vor 5 Jahren in C++11 geschrieben wurde, lässt sich akkurat mit C++17 compilieren.

Und POSIX ist nicht nur eine Eigenschaft von Betriebsysteme, sondern eine Ansammlung von Grundkonzepte, die die Portabiltät von Programmierlösungen garantiert.

RIN67630 hat geschrieben: Montag 14. Mai 2018, 15:37 Ein Programm, der vor 5 Jahren in C++11 geschrieben wurde, lässt sich akkurat mit C++17 compilieren.

Sofern du keine Bibliotheken benutzt oder genau die selben wie vor 5 Jahren noch hast. Aber wenn sich nichts auf deinem System geändert hat, woher kommt dann der neue Kompiler?
Die Probleme fangen in der Regel auch erst nach 10 Jahren an.

@RIN67630: Da Python weitgehend Systemunabhängig ist, wie willst Du das mit POSIX-Kompatibilität vereinbaren? POSIX ist auch zu low-level, als dass das irgendwer direkt benutzen will (wobei man mit Python dort wo sinnvoll möglich, auch direkt POSIX-Funktionalität verwenden kann).

Behauptungen rauszuhauen, ohne eine Referenz anzugeben ist halt ... zumal nicht relevant und auch noch falsch.

kbr hat geschrieben: Montag 14. Mai 2018, 13:12 Warum solltest Du selbst eine Sprache nutzen, die Du kritisierst?

Auch diese Frage möchte ich noch beantworten.
Ich muss nichts mehr. Ich bin in Rente. Ich will aber ein Middleware schreiben, von dem eine Seite in Python programmiert ist.
Dass Python die Daten ohne Deklaration nutzt und gar im Programmablauf verändert, macht es unglaublich schwer den Ablauf zu verstehen, da man nicht vom Code aus wissen kann, welche Struktur die Variable gerade vorweist.

RIN67630 hat geschrieben: Montag 14. Mai 2018, 15:37 Und POSIX ist nicht nur eine Eigenschaft von Betriebsysteme, sondern eine Ansammlung von Grundkonzepte, die die Portabiltät von Programmierlösungen garantiert.

Natuerlich geht es dabei um die Portabilitaet von Software auf verschiedene Systeme. Hat aber nichts mit einer Programmiersprache zu tun (jenseits des C FFI). Python laeuft auf diesen System gerade WEIL es gegen POSIX APIs gebaut ist, und offeriert diese explizit oder implizit. Und falls welche fehlen, kann man die sich zur Not mit ctypes dazubasteln, dazu haette ich aber gerne ein Beispiel. Und es bleibt dabei, das diese Aussage im Kontext von Programmierkonzepten die mittels Python vermittelbar sein sollen (oder nicht, laut dir) Unfug ist. Abstraktionen wie Dateien, Sockets, Threads sind verfuegbar, und portabel. Und koennen damit auch gelehrt werden. Das heisst nicht, das ALLES in Python sinnvoll darstellbar ist - eine eigene malloc Implementierung mangels einer Notwendigkeit dank gemanagtem Speicher wuerde ich in Python jetzt nicht schreiben. Aber habe ich auch in meinem gesamten Informatik-Diplom nicht gemacht.

RIN67630 hat geschrieben: Montag 14. Mai 2018, 15:37 Abwärtskompatibilität geht genau anders herum: Ein Programm, der vor 5 Jahren in C++11 geschrieben wurde, lässt sich akkurat mit C++17 compilieren.

Bitte erzaehl das den Leuten, die diese Liste verantworten:

https://isocpp.org/files/papers/p0636r0.html#removed

Oder diesen Stackoverflow post:

https://stackoverflow.com/questions/239 ... tten-in-c1

Oder Anhang C im C++11-Standard:

http://www.open-std.org/jtc1/sc22/wg21/ ... /n4296.pdf

Und selbst *wenn* es eine Sprache schafft, ewig waehrende Abwaertskompatibilitaet zu leisten und Python dies eben nicht kann/will, beruehrt das nicht die Eignung fuer die Ausbildung in Programmierkonzepten. Ich habe teilweise an Sprachen gelernt, die es nur im Kontext einer einzigen Universitaet gibt. Die ist zu nichts ausser sich selbst und in der gerade releasten Version kompatibel. Und in C++ gibt es wiederum bestimmte Moeglichkeiten gar nicht, oder nur auf so aetzende Weise, dass das auch nicht wirklich empfehlbar ist.

Es ist ja merklich, dass du hautpsaechlich von der dynamischen Typisierung in Python genervt bist. Ist dein gutes Recht. Benutz es halt nicht. Genauso wie ich von der mangelnden Generizitaet von getyptem Code in zB Java oder C genervt bin. Nur wuerde ich keiner dieser Sprachen absprechen, zum programmieren lernen geeignet zu sein. Und ganz ehrlich: die schlechten Angewohnheiten, die man sich in C aneignen kann, und die es dann schwierig machen, mit jemandem, der nur in Pointern von Pointern denken kann, modernen C++-Code abzuverlangen, sind durchaus relevant fuer die Praxis.

RIN67630 hat geschrieben: Sonntag 13. Mai 2018, 03:35 Dafür ist aber Python denkbar ungeignet!

Ich finde es interessant, dass du das so siehst, denn Python ist, soweit ich weiß, ja ursprünglich als Lehrsprache gedacht gewesen, bzw.aus einer solche Sprache (ABC) hervorgegangen. Das muss jetzt zugegebenermaßen nicht heißen, dass dieses Ziel erfüllt wurde -- viele Menschen scheinen das aber schon so zu sehen. Was schon stimmt, ist, dass Python einige Dinge anders macht, als "traditionellere" Sprachen; und wenn man über viele Jahre hinweg eine bestimmte Art zu Programmieren praktiziert hat, fällt es vielleicht schwer, sich auf Python einzulassen, oder anzuerkennen, dass es anders auch geht (oder vielleicht sogar besser). Mich würde zum Beispiel (ernst gemeinte Frage) interessieren, ob du Pascal für eine bessere Lehrsprache als Python hältst; das könnte aufschlussreich sein.

RIN67630 hat geschrieben: Montag 14. Mai 2018, 16:06 Dass Python die Daten ohne Deklaration nutzt und gar im Programmablauf verändert, macht es unglaublich schwer den Ablauf zu verstehen, da man nicht vom Code aus wissen kann, welche Struktur die Variable gerade vorweist.

Damit haben viele Probleme, die neu zu einer dynamischen Programmiersprache hinkommen; die vielen Vorteile erschließen sich zumeist langsam – und für manche sogar gar nicht. Anhand Deiner Beschreibung wage ich zu behaupten, dass das Problem nicht bei Python liegt, sondern sich vielmehr im Designentwurf des von Dir zu erweiternden Programms befindet.

RIN67630 hat geschrieben: Montag 14. Mai 2018, 12:08 Selbst der Datentyp einer Variable ist nicht stabil.
Sobald dass man an Schnittstellen kommt, die klar definierte Inhalten verlangen, ist der Spuk vorbei.

Ja, irgendwann kracht es wenn ein falscher Typ vorliegt. Das hast du selbst bei der Standardbibliothek von Python, dass da *nicht* alles Duck-Typing-gerecht programmiert ist und stattdessen ein bestimmter Datentyp verlangt wird. Das ist unsauber, weil inkonsequent, stellt jedoch kein riesiges Problem dar.

Falls dir Typchecks sehr wichtig sind, dann könntest du dir mal das typing-Modul anschauen. Einige Anwendungsbeispiele und wie das ganze dann in der Praxis mit einem Type-Checker aussehen kann, findest du hier:
https://medium.com/@ageitgey/learn-how- ... c86d72677b

Ich würde das bei Python aber nur empfehlen, wenn mit fremden APIs kommuniziert werden muss und diese statische Typen verlangen. Man hat dann den Vorteil, dass es noch auf Python-Ebene kracht, falls kein korrekter Typ vorliegt. Und das würde ich dann auch als gesondertes Modul auslagern. Allgemein sollte man nicht dazu übergehen, alle seine Python-Programme so zu schreiben, denn dann arbeitet man gegen ein fundamentales Konzept der Sprache an.

RIN67630 hat geschrieben: Montag 14. Mai 2018, 12:08 Selbst der Datentyp einer Variable ist nicht stabil.
Sobald dass man an Schnittstellen kommt, die klar definierte Inhalten verlangen, ist der Spuk vorbei.

Die Aussage ist ja falsch. Jede Variable hat einen stabilen Datentyp (Python ist stark typisiert). Es kann einem also nicht wie bei PHP oder Javascript passieren, dass man plötzlich eine Zahl hat, obwohl man einen String erwartet. Was Du meinst, ist, dass nicht der Compiler sofort meckert, wenn irgendeine Vorgabe, die ein Programmierer für nötig befunden hatte, nicht eingehalten wurde. Wenn man aber nur nach Compilermeldungen programmiert, hat man zwar ein formal korrektes Programm, das aber trotzdem voller Bugs ist. Das richtige vorgehen ist so oder so, Funktionen zu schreiben, die per (Unit-)Test auf Korrektheit geprüft sind und daraus ein komplexeres Programm zusammenzusetzen. Dann ist es auch egal, ob oder wie typisiert wird, denn die gefährlichen Fehler sind nicht Typfehler sondern logische Fehler, die kein Compiler erkennen kann. Daher sind die ganzen Typangaben, die jetzt immer häufiger in Pythonprogrammen auftauchen, nur unnützer Balast, der das Lesen und Schreiben verkompliziert, ohne in realen Szenarien irgendeinen Nutzen zu haben.

Sirius3 hat geschrieben: Dienstag 15. Mai 2018, 07:22Dann ist es auch egal, ob oder wie typisiert wird, denn die gefährlichen Fehler sind nicht Typfehler sondern logische Fehler, die kein Compiler erkennen kann. Daher sind die ganzen Typangaben, die jetzt immer häufiger in Pythonprogrammen auftauchen, nur unnützer Balast, der das Lesen und Schreiben verkompliziert, ohne in realen Szenarien irgendeinen Nutzen zu haben.

Die Typangaben die man in Python jetzt haben kann oder die es in C, Java o.ä. Sprachen gibt sind größtenteils unnütz. Grundsätzlich erlauben dir aber Typsysteme eine ganze Reihe von Fehlern auszuschliessen, was dir erlaubt dich wirklich aufs wesentliche zu konzentrieren. Außerdem erlauben dir Typsysteme Dinge zu tun die sonst gar nicht möglich wären, z.b. erlaubt dir Rust durch Substructural Typing Programme zu schreiben die schnell, sparsam, fehlerfrei und sicher mit Memory umgehen, etwas dass du sobald Concurrency hinzukommt mit einem GC nicht hinbekommst.